I am trying to make an application in django via docker and I want separate the backend (django) container from frontend (node, react) container using only one repository.
I want to run node commands from django container (for example: npm init and creating the package.json at main folder).
Is it a good pratice?
If yes, how can I do this?
Thanks in advance.
If you only need Nodejs for building, you should have one docker image just for building (and if you want, deploying) the static files, and then use a whole different docker setup for the actual production environment.
You can look at https://github.com/dkarchmer/django-aws-template (disclaimer, I am the developer) to see an example. Unfortunately, the project is not yet fully tested and documented, but shows how I propose to handle static files outside Django (it does emulate what I do for real in production - just not fully tested).
You will see a top level docker image I use only for building the webpack type project (using gulp), and actually releasing that directly to S3. The top level index.html file gets copied to the django templates directory, to be used as the base template by other django templates (you may not need this if your front-end will be 100% independent of Django). But IMO, I find it useful to mix. For example, I do all the authentication portion using regular django (django-allauth).
Your question is fairly open ended (not exactly a good way to ask in SO), but I hope the link above gives you some ideas on how to implemented what you need.
Related
I set up a GitLab self-hosted instance and its working fine, my problem right now is that I don't really understand how the frontend works. Mostly because I've been focusing on the backend and because I couldn't find documentation about it either. I wish to understand how I can comment out things I don't want to show for the user or in the overall design, change aspects and text, and overall have control of the frontend.
I'm running on Debian 9, the setup was made with Bitnami using Google VM. As far as I understand I have to manually change the files I want, but I really don't understand the structure of this type of frontend.
What language do I need to know here and where should I find the documentation, how to find the correct directory and files, etc.?
While GitLab doesn't officially support any type of "custom frontend", what you can do is:
Fork GitLab
Use the GitLab Development Kit to implement your changes
Run a Source Install of your fork
The frontend is mostly written in HAML (for the server-side bits) and Vue.js (for the client-side bits).
Note: Even an Omnibus install copies raw ruby and javascript files somewhere, and since they’re physically on the system, they can be manually manipulated and hotpatched, but that’s not really a sustainable way of introducing changes to the codebase.
I have two differents apps using a gruntfile.js and a package.json and when i launch locally my second app (providing only 1 functionnality, thats why i trying to merge it with the other), this works, but when i try to works the functionnality by merging the second app in the principal app, it says that modules are missing.
My principal app is the BPMN editor from: https://github.com/bpmn-io/bpmn-js
And the second app is the BPMN-diffing from: https://github.com/bpmn-io/bpmn-js-diffing
My BPMN_editor's Gruntfile is minifying BPMN_editor's .js files, then i tried to do the same for BPMN diffing's js files. but nothing is working, my node server wont run normally (while hes working without this BPMN diffing).
I dont understand how to use the bpmn diffing, should i make an npm install to install all dependencies of bpmn diffing, and then make an npm install of the bpmn editor to install dependencies ? or should i merge the Gruntfiles and the package.json files ?
Thanks a lot
Fantemis
If they are based upon two differrent configurations, I would prefer using a load balancer or a reverse proxy to load them on the server. Merging the projects takes a little more insights from you and a little effort. The effort always depends on the setup. I would give you a little tip, but I am not seeing a Gruntfile in your main principle repository.
A little insight into "Reverse Proxy vs. Load Balancer"
What is the difference between Reverse Proxy and Load Balancers
Alternative 1 (preferred):
You could however create a small node.js server, which is handling the serving of those two applications, like the following:
- bpmn_root
|- principal
|- diffing
Afterwards you just need to write a little script, that is building both things on the server you want it to be deployed, and then you just need to do node SCRIPT_NAME.js.
Further reading, and another post about this.
Alternative 2:
You can use Docker. I am not very aware of how to use Docker to power such thing, but it is "as simple as" creating an Nginx configuration, which is doing the reverse proxy stuff for you.
Alternative 3:
Using the load balancer, which is handling the reverse proxy automatically. This is also a little more complex and needs some more learning to do. You can find plenty of tutorials on this however on the internet.
I have 2 projects, as shown in the following images.
The Node, and Express project is in the root folder, and the Angular CLI project inside of angular-src folder.
I can run each project individually, back-end on port 3000 with node app.js and front-end on port 4200 with ng serve
What is the best way to integrate both projects, and the easiest in deployment?
Full Project Folder
Full Project Folder with angular src files shown
Most people keep their frontend (fe) and backend (be) in separate repos. This makes sense when you think that you can have multiple fe's for a single be.
However, its often easier just to keep them in the same repo. Then when you deploy you only need to clone one repo.
Also, it depends what route you do down. Will you installed Node.js etc on your server or will you go down the docker route?
People often like to use docker to containerise their fe and be. The benefit of this approach is that you only need one dependency installed on each server you deploy too, that is docker itself. Everything else exists in the docker world.
Also, docker makes it easy to docker pull from any server. If things go wrong, just kill your docker container and spin up a new one (assuming your data would not be lost in doing so, not a worry for the fe but a be concern).
Obviously, there is the docker learning curve but it's not too painful.
I'm building a NodeJS (Express) application off the Node Docker Image and need to generate files through the app. Whenever I run the application outside of Docker my code works and the file shows up as expected, but when docker-compose up-ing it the rest of the app works fine but no files are written. The scripts don't throw any errors either so my suspicion is that this is more to do with how Docker manages files within containers.
I've tried two different implementations of my solution too, one using the fs library and another generating files using ffmpeg, both with the same results.
I've tried console.log(__dirname) to confirm I'm looking in the right directory too but, alas, no luck there.
If it's of any help, I'm working of the Node image and the MySQL image, using Docker-Compose to link the two. I'm also using the PM2 process manager (recommended by a tutorial I was following) in case this can give any other useful info.
Should I be creating some kind of volume for Docker to write files to, or is it as simple as adding a specific library to my application?
Firstly I must confess I am a noob at node. I've been using ASP.NET then PHP then Django before. Regardless, I've found node a breath of fresh air. This problem is also not strictly a node problem, but I need a node specific answer.
I have an express server and angular frontend. The server side templates are in swig and currently only serve for error pages and the index page. Mostly the angular templates will make up most of the front matter.
What I'm struggling with, if only only in deciding how to do it, is getting an efficient work flow for the asset pipeline. Server side templates must be able to inject the vanilla of assets during dev and testing. The same for client side templates during testing. Basically, running with express' static middleware should be an option without any configuration (maybe with some helper in server side assets). Thus git clone -> grunt -> viola.
However, during staging and production, I would like the server side files to stay vanilla. The template helpers may parse a manifest file indicating the cache busted links (CDN path maybe too). How to make the link from logical asset bundle name to production ready asset is a mystery for me, while keeping development transparent.
The client side templates may be minified, concatenated, injected or whatever, as it will be saved to some dist folder for uploading. It is important that the whole dependency tree (images, fonts, css, js) must be "exported" to the dist folder.
To deploy would then be: pushing the server side code to the server and running. And pushing client dist folder to some asset host (CDN, nginx, another node, maybe even connect static)
What my question(s) then actually is(are):
Is this workflow possible with tools such as broccoli/gulp/grunt alone?
I've tried connect-assets but I don't want to conform to some predetermined folder path. Also the cli tool didn't produce the other static assets. Perhaps I don't understand the tool.
Am I following the correct approach?
I've added to a discussion on broccoli concerning the manifest file consumption:
https://github.com/mjackson/broccoli-rev/issues/1#issuecomment-49076249
Edit: I forgot to mention that I use bower, so assets should be pulled from arbitrary (URLs too maybe) locations.
I think angular-fullstack is what you want. Even if you don't use it, it does almost all of what you're looking for.
The only thing that it might be missing for you is deployment. It has built in support for Heroku and OpenShift deployment. You could use something like grunt-ssh or grunt-deploy for other deployment scenarios.