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.
Related
I have been using webpack to build a server side app using express. This code is harder to debug since I don't have the immediate comfort of a web browser and if I use something like VS Code to debug, it won't accept breakpoints inside request handlers when using source maps. Besides it takes no time to compile if I just stick to Node compatible JS and skip all transpiling and whatnot. Further, if I use treeshaking, I can reduce the size, but what is the point of that when it is running on the server (no client will ever download it).
My point is that I don't see why one would want to create a bundle of server side code if the server don't have any issues with memory or other limiting factors. It's easier to read, takes no time to compile and is easier to debug.
So a question. Is it ok to have the server app as an npm package and deploy that? Is that what is common or what do people do?
The project my team works on is a TypeScript monorepo that includes a web application and server-side daemon processes. We use webpack for producing build artefacts for all targets.
I've read some posts saying there's no point using webpack server-side because it was designed for web (obv), and I can understand that point of view.
However, even if our code was JavaScript and didn't require any transpiling, we'd still use webpack for the server-side. I want a single, minimal set of files and no node modules to deploy to the servers.
Size itself doesn't matter that much for server side (though every bit helps), but running 'yarn install' on servers is out of the question IMO.
I am creating my first app node express app with angular 7 on the frontend to be deployed in production. I have below question?
What folder structure is preferred, should I create separate
projects for node and angular or same project(server.js in the root
of angular project and server folder to create express server
files)? What is the preferred one and I have to checkin the project
in one folder of svn.
Should I use babel and create the node server code with es2015 or
continue with old approach?
Its all up to you, what I am doing is I have sepreate directory for Angular and Node projet
project
|
client - Your anguar project
server - Your Apis and server side coding (Only this folder require at productino level)
Then we can create a gulp file and task to gulp that Build my client
project and put that build folder inside the
server -> public
Now only server can be use to production where Build will be render as static.
And next to authentication and autherization process you can follow JWT based permission .
Generally I would say that separating your client and server code into separate projects is preferred so that you do not have to release both your client and server at the same time when you make a change to one or the other. The rest of my answer is based on the assumption that you would separate the two sides into different projects.
As far as structuring your server side Express-based application, check out this link for some guidance on how to handle your situation. See the answer to the first question about different approaches to how to structure your Express application for different deployment scenarios. Also, if you use the latest LTS version of node, you will not need to use a transpiler to convert your files to Javascript because the Node environment will handle that for you.
As far as structuring your client side Angular-based application, check out this link for a very detailed discussion about best practices for structuring your Angular application.
I would prefer following, in case in future you need to separate the API layer with client you can do it with ease,
project
|----client
| ---client-template //All UI code like .css/htmls and node process initiates from here
| ---client-angular // All the directives and controllers goes here
| ---client-service //Service layer, All the API call to server goes here
|----server
| ---server API's // separated by its own module if any
|--- you API modules and so on..
This will help you to have flexibility over client and server integration without any tight coupling. Also easy to maintain and debug.
Answer 1: you should make two separate folder/repository structure for frontend and backend.
let's suppose your application grows fast at that time you want to scale your backend and you want to host your Angular app as static web app using Amazon-S3 so at that time it will be very easy to manage this.
May you want to use CICD, in that case also it will be good if your separate folder so you can create separate CICD jobs for backend and frontend.
May be your company hired some developer which is either expert in frontend or in backend only. in that case your company don't want give them unnecessary code access. so separate repo will be an easy option for this case. (this may be Depends on your team and company's approach for development)
Answer 2: I recommend go for es6 or es6+ features.
latest node.js version is supporting some of the features of es6. for example
- spread operator
- destructing
- classes (you can use OOPs)
- arrow functions
- let, const
- async await and etc
you can use babel if any other feature which is not supported by node.js. there could be may reason for using babel, but i want to know which specific feature do you want to use with babel? so i can explain according to that.
I have used the following approach that bind the Angular Application and the Node server as a single unit.
Steps for creating the project structure is:
Create a new Angular project with the CLI.
Create a server.js file in the root directory of the project and configure it to render the contents of the dist/ folder on the / route.
You can refer the link for the server code: https://github.com/nikhilbaby/node-server
Running the server
I usually run the project with ng build && node server. This will make sure that the angular application is build first and after that node server is started.
I'm working on a web application that currently uses vuejs for part of its interface. The back-end is NOT in Node, so there is currently no package.json file or any tool from the typical npm stack in this repository.
We already have a bunch of non-npm dependencies that need to be installed in order to use the repository, so my coworkers aren't too open about the idea of adding another layer of complexity. I can't blame them for that, it's the reason why I use npm scripts and not even gulp in my other projects. I'm tired of spending hours learning and configuring build tools that never end up doing what I want anyway.
But since the vue-cli tool no longer includes the build command, I'm a bit stuck. Is there really no more CLI app to build vue files at all? And if so, what would be the smart way to use vue without webpack? Template strings are not maintainable at all, and <script type="text/x-template"> don't work when you want to use multiple components from multiple files in the same page.
I realize your question says 'without webpack' but you may be interested in backpack - a CLI app i came across for building Vue.js without requiring you to write any configuration code. It is basically webpack preconfigured as a minimalistic build system for Node.js. It provides two commands, dev for live reload enabled development and build for building you project.
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.
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.