I am trying to create a general web service using Nextjs.
In my research, I often see cases where Express is used as the backend for Nextjs.
However, Nextjs has an api function.
In what cases do we need to use Express for the backend?
Well, you don't really need Express as the backend server. You should be able to use any framework from any programming language. I guess the reason that you often see it used is because it is the best documented.
Regarding api routes, you will always have to use some kind of backend server as it does not work with next export (aka creating a static folder containing html, css and JavaScript).
Related
I want to use React for a project I am working on, but I also want to use an API.
How can I do it?
I have tried to Google this and ask different people, but I have not got a response yet, so I thought I would ask here. I want to use express and maybe not use create-react-app (as it takes up a lot of storage).
Working on a custom server doesen't preclude the use of an API.
If you want fetch the API from the express server and inject it directly on react frontend you need to enable server side rendering (useful post) and pass the data collected as a props from the server (check this example).
Rather then you can build your react project (using even create-react-app) and build an express server who return the index.html on call.
Personally I prefer the first one solution.
I'm migrating my Node Express JS App to Azure functions. I've more than 250 Routes in my application.
I went through this microsoft link to shift from Node Express JS to Azure functions (solution repo). What I understood is that I'll have to create azure functions for all the routes. i.e. each route will be a function in itself. I've more than 250 routes in my application so, I'll end up creating 250 function.js in their own folder, Is there a less painful way to make this migration.
I thought of doing code level routing based, i.e. grouping all API's by a common purpose and create functions for that top-level purpose and then internally route the request using URI passed to the function. Is there a better way to go about it?
Eventually it might make more sense to create separate functions for benefits like better built-in logging and allow to leverage input/output bindings but would depend on your scenario.
But it is possible to reuse the express app code as is too, and there are two ways you could approach this
A handler function to catch all routes and forward it to express. You could use the azure-function-express npm module which implements this for expressjs. Note that I haven't used this module myself but looks promising
Leverage the Custom Handlers feature. This allows you to run any web server (the expressjs app in your case) and forward requests to the web server. Similarly to 1, you could choose to have just one catch all function since you have a lot of routes to cover.
Note that this feature is currently in preview.
I'm new to Apollo and JS on the server, but not new to React, GraphQL, etc. I'm trying to wrap my head around a clean way of having the server serve both the API, using Apollo, but also the client, which would be built with ReactJS and also Apollo.
I read the article on server-side rendering for Apollo. I might be interested in that in the future, but right now, I'm only interested in having a single project, deployed from a single server, instead of two.
Is it possible to do this cleanly? Is there a canonical way of doing it? can it use create-react-app or is that out of the question?
If you're not doing server-side rendering and just want to serve a Single Page Application (SPA) like what's built with CRA, you can do so using pretty much any HTTP framework or even without one. CRA just builds some static content for you, which you can serve using, for example, Express (see docs here). However, it's typically better to utilize Nginx or Apache for serving this content (at least in production). If you want to utilize Express or another HTTP framework to serve the files, you can utilize the appropriate integration for Apollo Server. If you're using Nginx, then you can stick with the standalone library, assuming you don't want to expose any additional routes on your HTTP server.
In development, you don't want to have to constantly manually rebuild your React application when you make changes, so CRA actually runs a server for you that serves the app and enables hot reloading. Because this is a separate server from your API server, you'll typically want to enable proxying your requests to the API.
It's possible, the setup for apollo is the same as any server, for example, you can use express to serve static files and implement apollo with some minor changes see the docs for apollo server express and implement the one that you are familiar with
I am about to start developing my web application in Firebase. Problem is, currently I have 100s of questions running through my head, and nothing I can find online specifically answers such.
Now from what I understand you can ONLY host assets on Firebase hosting (HTML, CSS, JS), and if you have a backend (such as Node) you will have to use a separate hosting service (like Heroku).
Firebase hosting implies that everything can be done from the browser, but I am not sure how I would get around using a backend.
For instance, if the user enters the url http://___.com/login I would route that in Express to login.html. Also if a user types in /index or /home or even nothing, it would take them to index.html. How would I go about doing this without a backend?
Another big question I have is templating. On Node there are many templating engines, is there such a thing though when just using the frontend?
Would there be a way to get around those two issues above without using a backend? I can see some benefits when using a backend such as server side rendering, and using third-party services such as Sendgrid. But what else would I get out of using a backend such as Node?
I guess I am just a bit confused on how a web application could be done without a backend (that you can access and control). I do not see how templating, routing, and many other things can be controlled by just the browser, and hosted within Firebase.
I plan on using Node (unless all of this is possible without a backend), and I am intending on using React and Redux as well. Can Firebase, Node, React and Redux all be used together?
I know there are a ton of questions above, but I just can not wrap my head around it all. I put all of my main question in bold, thank you!
Firebase Hosting allows you to do single-page app style routing, you'd just add this to your firebase.json:
{
"hosting": {
"rewrites": [{"source": "**", "destination": "/index.html"}]
}
}
As for templating, you'd want to look into frameworks such as React, Angular, Ember, Polymer, etc. to do dynamic content generation client-side instead of relying on server-side templates.
Firebase offers tools that can help you with the most common things you'll need when building an app (auth, database, file uploads, hosting). For these, you won't need a server at all. If and when your app needs additional custom back-end work, you can always deploy separate services that can be called by the client or even just listen to the database and trigger events directly.
And yes, you can definitely use React, Redux, and Firebase together. Hope that helps!
I understand that Express resides on the server and Angular resides on the client but, as far as I know, Angular can do everything that Express can do which is
routing
interacting with the database
It kind of seems like maybe Express is needed in order for an AngularJS app to be served by Node.js but I'm not sure.
So what are the benefits to adding Express to an AngularJS app?
There are things which should be done server side (i.e. Express, not Angular), most notably user input validation - Angular, as it's client side, can be tampered.
Also, if you'll ever want to offer access type other than web app (i.e. mobile app), you'll probably need an API anyway - Express can do this, Angular don't.
Finally, database access - usually Angular app will need to connect to some kind of backend to perform CRUD operations. You'll either go with hosted DB like Firebase, or you'll end up using your own database. Latter scenario is more popular and you'll need Express (or similar) for that.
Express and AngularJS do not mutually exclude one another, they serve different purpose - in fact it's perfectly fine to use both - express for all your serverside logic, and Angular for client side logic.
Express can be used to host the APIs for AngularJS's service/factory to consume. You can consider AngularJS as MVC and the API on Express as SOA.
There is lot of stuff that one wants to control from server. And that is the place where the server side frameworks come into picture.
An web app is not just some html pages linked together. There are lot of other things that needs to be implemented
Model validation.
Keeping model consistent. Remember multiple users can access the same model at any give time and even change it.
Controlling resource access.
Triggering workflows.
Business Logic.
and other such thing require a server framework. So as mentioned earlier the client side frameworks like AngularJS complement server side frameworks.