i have created and build (react-script build) a simple react application. I want to deploy it to my ubuntu server via a Docker image and i am looking for advise. Is it better to use expressjs and pm2 to serve the react app or would it be more useful to serve it via nginx? What are the advantages and disadvantages?
Thanks a lot for your advises
When you're going to deploy a React application, you've typically used a tool like Webpack to compile it down to a set of static files. Once you've done that, deploying it via nginx will be smaller and faster than an Express server, and since you don't have the entire Node interpreter involved, there are fewer parts involved to potentially have security issues.
In fact, even if the rest of your application is in containers, it can be beneficial to host the front-end somewhere external (if you're otherwise deploying to AWS, for example, put the built front-end into an S3 bucket). This can simplify the deployment mechanics a little bit, and with Webpack's file hashing, you can keep older versions of the code for browsers that haven't reloaded the page recently. You still probably need the nginx proxy (to serve a /index.html page, to proxy the back-end services) but you don't necessarily need to redeploy it when the front-end code changes.
The only real advantage to an Express-based deployment setup is being able to live-reload your code in production. That would come with a high risk of human error, though: make an accidental typo and save the file, and end users see an error page. I'd avoid this path.
Related
My website will perform CRUD operations and will work with MongoDB and Firebase storage+auth.
What are the reasons / advantages to developing a separate Express server instead of integrating everything in my next.js app?
As far as I have seen, it can all be done in my next.js app, but I still see many projects working with a separate server.
Depends on what your app does and how you are hosting it.
Running Next.Js on a standard server will be of little difference whether you are using nextjs's /api or expressjs.
However if you are hosting on serverless (e.g. Vercel), I would recommend using a separate express server if you have alot of CRUD operations because the warming up of serverless is really bad user experience.
Build and Deployment
Next/JS - If you want to edit something on the backend, and push the changes, it will require you to build the entire JS app, and depending on how big is your app, it can take alot of time (especially if alot of static generated pages).
Express - If you running express separately, you can build and deploy front end and backend separately. It's time saving, and you can also better organise your codes frontend/backend.
Choice of deployment
I have a choice to take advantage of Vercel to host my frontend, with static generated pages and some server side generated pages (automatic scaling, caching, CDN etc), and host my backend with a separate cluster of servers.
PS: I moved from single Next.JS app to NextJs+Express
I can think of a few things why they would have a different server from the one NextJS provides:
Familiarity with Express, Koa, etc. All next-connect helps with this
There is an already existing API in PHP, Express, Flask, etc.
It is literally based on what you would want to do, the extra interactions with MongoDB & Firebase would be same on both the technologies, unless you want to isolate respective things separately, I don't see any harm in doing everything together on next.
Given that the idea of using next.js, as per my understanding would be to utilise server side rendering.
I've been using Next.js with Typescript for quite a while now and I, as of now, have found one reason not to include express.js in my project. And the reason is Vercel.
Since I use Vercel for continuous deployment of my projects, and Vercel Not supporting any custom server as of there Docs here, I refrain from using Express or any other custom servers.
I didn't face any problem performing CRUD operations with MongoDB, can't say about firebase.
On Next.js Docs, I found these points to be considered:
A custom server can not be deployed on Vercel, the platform Next.js was made for.
A custom server will remove important performance optimizations, like serverless functions and Automatic Static Optimization.
But at the end of the day it very personal opinion weather to use a custom server or not. It might depend on a very specific use case you might be looking for.
Personally, I try to keep it to just NextJS, but if I have to manage real-time data with Socket.io, I get a separate server because other than WebSockets, serverless functions can do everything else.
i have got a problem, which i am trying to find a solution for weeks now.
I think it´s an understanding error on my side, but i couldn't figure it out.
What i am trying to do:
Develop, not deploy, a react app on an Apache2 server.
I know that react is an frontend library, so it should be possible to do.
I also know that nodeJs is kinda required to "npm" all the packages and to create the "Simple" react app..
What i want also to do:
Use the MATERIAL-UI
Build a PHP Backend
Collaborate with my Team Members (they should also work on the react app)
Thanks in advance.
Hosting a ReactJS App is no different than hosting any other javascript code on any type of server - by having it as a static file on your web server and including it in the html returned from the server.
Depending on the way your React project is set up, you would:
use node to build a javascript bundle of your react app (possibly by running "npm run build" in any CLI),
include the resulting script file or files in the head element of your root or master template
Make the Apache web server return the needed page with the master template where the script tag is
Additional setup could include starting the PHP server and react development build at the same time, but that is highly specific on your setup and would require you to add some more information on used frameworks and setup.
It is not possible to deploy apps with Apache and React. The nodejs based- Webpack server is incompatible with Apache web server. You'll have to pick one server or another, you can not route index.html -> index.tsx and vice versa. Besides if you ever got both servers working in tandem with SSL, it's a technically security nightmare and has no production value. It's best to avoid java(script) all together as it's merit in real software development has greatly diminished. Mostly for gold diggers.
I created a React application using Create-React-App and npm.
I intended to simply build it with npm run build, and somehow host the produced build in a windows server.
This windows server doesn't have any internet connection (but I have admin right so I can install offline packages), then I tried :
Hosting the built folder wihth IIS which didn't work (I couldn't find
any good documentation on that)
Packing the "serve" npm package to install it in the server (serve having
a huge amount of dependencies, it's really difficult to get an
offline package)
None of this seems to work... Any suggestion ?
One way of doing it:
1.Install NodeJS on Win Server that has Internet connection.
2. Install Express on that server and get your React app to work with Express.
You might want to look for Express-React boilerplate to save time. I wrote such a boilerplate though it's written in TypeScript. There are others.
3. Copy NodeJS installer and Express installation to the server without Internet connection. Install Node. Then you can optionally use IIS as a proxy for better security.
Another (and more involved) way:
Instead of copying the Express installation, create a Docker container out of it. Then enable Hyper-V on the server without Internet connection and run the container there.
Yet another way (I don't recommend it):
Let IIS create NodeJS run-time environment while serving incoming request using iisnode as described here.
P.S.
Using Express won’t add SSR to your React app. An SPA needs some server-side logic from the server. That's what I meant when suggested get your React app to work with Express. The logic includes mapping and redirects.
IIS has very powerful and flexible configuration and both mapping and redirects could likely be done declaratively by typing the configuration settings including regex(es). I never tried but have feeling this is possible. However it might be a challenge to find instructions about that online. The other way to do the mapping and redirects is programmatically rather than declaratively. Instead of writing it in C# for example, you can do it in JS or TypeScript, utilize Express and add IIS as a proxy.
What mapping and redirects are needed?
Mapping: Map the path /static/js/*.js to the physical folder where the script bundles are. CRA puts the bundles into my-cra-app/build/static/js directory. Note 1: You might want to double check that in the index.html file generated by CRA the path to script bundles (found at the bottom of the file) is indeed /static/js/<bundle>.js. Note 2: Better security would be achieved if the mapping is not wildcarded, rather more restricted e.g. it checks for a pattern match that includes the bundle name(s).
Redirects: Needed to implement the fallback required by all SPAs. The fallback is automatically added by CRA to webpack-dev-server. When people do deployment then in cases when they move from webpack-dev-server to Express or other server, they frequently skip the fallback which is mentioned here as the 3rd pitfall of React-Express integration.
I am trying to understand React to possibly create an app for Production purposes.
I am used to creating an Node Express app, and with Express if we want https we require https and in the https.createserver() we provide a path to our pem file from our CA and our passphrase to access it.
Do we not have this option to use a CA Certificate file for React? Or since it is just a UI does it not need it?
Say I have an Express API, I created using https that I can get information from using postman with no problems, and I want my React App to access my API. Is the only thing I will need to get info from my api the proxy line in my react package.json file pointing to https://api.to.call.com? I thought it was bad practiced to post or get to https server from http.
Plus I just read that Create-React-App should not be used for production. Then what am I supposed to use for production? Is there a Create-React-Production-App? Or is this something else I need to add to my express server? I am very confused about the entire setup.
React is a front-end library. As such, it has nothing to do with SSL certificates, since in the end it's just javascript code that runs inside the client interface (i.e. a browser).
React is also agnostic when it comes to your back-end. It can be Node/Express, Rails, Python, PHP, your front-end really doesn't care, all it will see is an API that provides data (usually in the JSON form) upon request.
You do not have to serve your API and your front-end files from the same server - you can, but it's a matter of preference. And to access your API from your front-end, you can use one of several npm packages, Axios is a great one, there are others (Fetch, ...) ; all you have to do is hookup your API calls using the same URLs you used in Postman in the components that require them.
As for Create-React-App, it's a nice helper tool, but I would recommend learning a bit about the React ecosystem rather than rely blindly on it. The trickiest part is probably the Webpack configuration, but once you get the hang of it, everything becomes a lot easier. There are also newer tools like poi that can do a lot of the grunt work for you. With Webpack, you can have a dev configuration (hot reloading dev server, etc.) and a production configuration (that will output your production build JS, HTML, CSS, can optimize with chunking, etc.).
I'm not very familiar with Create-React-App (I prefer to use my own boilerplate projects), but if I'm not mistaken, there is a possibility for you to access full customization of your project, see here. Be warned however, it's a one-way operation.
I have an MVC project which really just serves an angular application. This will be a public application and I expect it to get a lot of traffic, so I'm trying to use a CDN to keep requests to my servers light.
I've found many articles on how to get angular itself from a CDN but what I'm looking for is for MY file (css, html, js, media) to get served from a CDN. So for example, if I have a directive, then the template would need to be served from a CDN, but I can't hard-code it because the template may not have been uploaded to the test or prod environments yet.
Update: The MVC application only serves the initial layout and home pages. Once my angular script loads MVC isn't really used anymore. The back-end is a separate Web API application.
You might be asking the wrong question, but you're on the right track for how to optimize for high traffic.
First, learn how to serve the angular application as static files. On a past project I worked on I had two projects in my visual studio solution, one was a Web API back-end, and the other was a web project that just served static content. You can configure Visual Studio to run both projects at the same time on different ports from localhost. This doesn't answer your question, but setting up dev like this will get you a step closer.
Next, once you know your project's front-end and back-end are decoupled from the server level, make sure you're not going to get an CORS issues from cross-domain requests. If you're going to be serving your back-end from a subdomain, CORS may be an issue. Look into that, you'll probably need to add some code to your MVC app to solve that problem.
Now that you've got all that figured out, find out how to use a CDN service. There are many offerings with specifics of how to deploy content and SSL certificates varying for each. Amazon Web Services, Microsoft Azure, and many others offer CDN services, but before you even look at that stuff, make sure you can actually serve your back-end from a different port on your dev machine and it still works.
I was trying to think of a good solution to this recently...
In local testing (grunt serve), i use the current non-minified .js/.css file, but when creating a build (grunt build), Id want to point those files to the CDN in my Angular project.
I'm thinking for your grunt(gulp/webpack/etc) build (which creates the minified local files for the build), you could make a task to prepend certain urls/files to your CDN via
https://github.com/callumlocke/grunt-cdnify or https://github.com/tactivos/grunt-cdn (but it would still use your non-minified files for grunt serve).
It would be cool if uploading to CDN and invalidating the files was a grunt/gulp/webpack plugin.
Then you could automate it as part of your prod builds.
Guessing your build system like Jenkins/etc would upload your app to wherever.
and then either with a grunt/gulp plugin like so could invalidate your files:
https://github.com/keycdn/grunt-keycdn if you use that CDN service.
I am guessing your build system like Jenkins could also do this work for you via its own CDN upload/invalidation plugins.
I know this answer is mentioning grunt specifically, but there should be similar plugins for gulp/webpack/etc as well.