I am wondering what are your best practices for a Single Web Page app project using the MEAN stack (MongoDB, Express, Angular and Node.js).
Right now we have the following organization:
One Git repository for the Angular Client side code
One Git repo for the node.js & express server side code.
I saw browsing some blogs and checking node.js boilerplate that a common strucure is to have only one repository to handle Angular Code and Server code.
I'd like to know, from the community, if this approach is really better than having 2 difference repo in terms of versioning, easy to deploy etc...
From my personal point of view, I don't see that much difference...
I don't see much difference as well. It should actually be driven by the team. Your code organization could be beneficial if you had a separate front-end and back-end teams. I've seen an environment when UI guys only downloaded UI portion and hooked up to REST back-end deployed somewhere on DEV server.
Number 2 is release procedure. If your front-end and back-end are tightly coupled they will be released together for 99%. Then you don't need to handle 2 repos. However if your back-end will serve as REST service end-point for other clients, not only your UI and you plan to release front-end changes without touching the back-end (no downtime for external clients) you may want to use two separate repos.
Also think about your CI server. You may want to run front-end an back-end builds and tests separately. However for most CI servers it does not matter either it is one repo or two.
Related
I am a new self-taught developer.
I have created a simple full stack app (learning management system) using PERN stack. Now, I want to deploy it to learn the end-to-end process of creating a web app. I have a plan to make incremental improvements in the app and add more functionality to make it usable.
While researching for deployment, I came across various posts that doesn't recommend using create-react-app for production ready React apps. Further, this official article from React recommends using some toolchains for deployment (I think it is another name for Frameworks or set of tools):
https://reactjs.org/docs/create-a-new-react-app.html
Another alternative is to optimize the code using Webpack etc. before deploying it. I am neither familiar with any React Framework nor much aware of performance optimization for PERN apps.
If I have to use a framework, then my existing code may not work. I may have to do complete review of the same to make it suitable for the framework.
What is the best way to deploy my PERN app which I can scale in the future. (I have partially understood the concept of client side and server side rendering. As of now, users have to login to use app. But in the future it will be like the users can see the page (to take advantage of SEO) but need to login in order to interact with the site).
Do I need to learn a framework? (In that case I may have to develop all the code in that framework to maintain compatibility). If this is the case, then I will be glad to know which one?
Or, is there other way to deploy fully-functional PERN apps ready to use by potential customers.
Eagerly looking for some answers as I am completely confused at this point.
I have a react.js website with a backend in Node/express hosted on Azure, right now the project is monolithic, every time I do a change in the front or backend everything is redeployed in production. What I would like to achieve is to be able to deploy the frontend and the backend independently from one another whenever I push a change on github, but also if they are both affected deploy them together to avoid inconsistencies. Do you know some best practices or services to achieve this? Thanks
The git deployment method of Azure app services is simple. However, as long as we modify the file, all deployment commands will be executed and the entire deployment process will start. This cannot be changed.
Based on your description, I probably know that your project is a fusion of front and back ends, without separation of front and back ends. So I guess, you want to use the same app services for the front-end app and the back-end app.
So I suggest that you still separate the front and back ends of the project. This is the mainstream. It is also convenient for later maintenance and expansion. If you just want to use a webapp service, you can use a webapp based on the windows environment, and just use a virtual application. In this way, the update program can be completely separated without any impact.
Note that at present I found that the virtual application does not support the react project and has raised a support ticket to confirm. If have any progress, I will tell you.
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 developing my first node.js app deploying to GAE.
It'll be organized as an API service and a front-end web app developed with Next.js
I'm looking at this architecture, and, although I have the app separated in two repositories I could have one merged repo to create two different microservices:
https://medium.com/this-dot-labs/node-js-microservices-on-google-app-engine-b1193497fb4b
For me, it seems overwork creating a new repo to merge them and deploy (doesn't it break one of the basic ideas of microservices to make isolated deploys?)
I have to discourage this because we need SEO in some of the parts, and We should use Next.js (or similar):
https://cloud.google.com/storage/docs/hosting-static-website
Another idea I've been working on is... create different GAE projects for front and API to deploy independently. For me, it seems like the best option, but I would like to know your opinion as GAE experts.
Which one should I use?
Thanks!
GAE doesn't care how is the code to be deployed into the services mapped to one or more VCS repositories (or no repositories at all). That's entirely up to you.
With a single repository you may encounter difficulties deploying from CI/CD pipelines - for example unnecessary deployments to one service when only the other one is changed.
Many examples out there focus on applications rather than services, but those are nothing more than the default services of those applications. Personally I like keeping the code for different services in separate directories, see the image captured in Can a default service/module in a Google App Engine app be a sibling of a non-default one in terms of folder structure? (it's no longer present on the updated documentation page). This also allows for easy mapping to multiple, separate VCS repositories
As for multiple projects vs multiple services, this might be of help: Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
The static website link you mentioned isn't part of GAE, it's part of GCS - a different GCP product. It's fine to use by itself - for a static website, but it might be difficult/impossible to:
communicate between a service running on it and one running on GAE - if you need that
make the 2 services appear as one (for example serve under the same custom domain name)
I've been developing a client/server application (React/Express) as a single repository up until now. This made it straightforward to either run the server in development mode using the raw web app code/assets for debugging on both client and server, or production mode with a built web app.
Now it seems that there should be two repositories because the server API is actually being used by much more than my React app and it isn't acceptable to have the two so intertwined.
I'm not sure how to go about refactoring this. I know I basically want a directory on the server that will act as a deploy target for the production-ready React app. However, I don't know how organize everything so that I can easily start the server in development mode and have my raw web app code be continually watched and compiled.
The best I've come up with at this point is to just have two different directories in the server repository, one for production builds (the built code and assets are copied to here) and one for running the server in dev mode where my raw app code is continually copied from the client repository during development.
Is there a better way?
A typical workflow in git is to have a development server that uses continuous integration to upload commits as they are made, and then a production server that you manually deploy to with a commit that is deemed "release ready" from the development server.
Having two directories that basically act as a development and production server is an acceptable practice, IMO. You should run the server in production and dev mode at all times, ideally, meaning that you would run dev and prod on different ports.o
More of an opinion than a firm answer, but that's my 2 cents.