How does NextJS with API routes differ technically from running an Node.js server with Express.js?
For example - If I want to develop a full-stack web application with MongoDB, can I use only Next.js with API routes for that purpose? Is connecting and modifying the database safe from the API routes, or is it a security risk?
In other words, are the Next.js API routes exposed into the client browser where the end user would be able to modify the code?
Nextjs API routes are ran serverside. Per the docs,
They are server-side only bundles and won't increase your client-side bundle size
So the end user is unable to modify the code. Just make sure they are in the /pages/api folder. Read the docs for more info: https://nextjs.org/docs/api-routes/introduction
Related
In NEXT project, API Routes let you create an API endpoint inside a Next.js app. You can do so by creating a function inside the pages/api directory that has the following format:
// req = HTTP incoming message, res = HTTP server response
export default function handler(req, res) {
// ...
}
Then what is different between express backend and next api.
If I use next api, can I build all backend and frontend?
And how can I get access to database on next api?
Is that possible?
If I use database configuration on next api, then how will it be rendered in SSG?
I can only speak of what I know about the question. In my current project, we use an Express server with Next.js.
Reasons to Use Express With Next
Express has lots of middlewares available and the ecosystem around it is solid. In my case, we already have multiple Express apps in production. Adding the Express layer helps us keep the behaviors of different servers as similar as possible.
Reasons to Use Next API Route Directly
Next API routes are straightforward if you don't have many custom middlewares. Next.js already come with common middlewares to handle many common tasks. I think the decision comes down to where you are going to deploy your application. If you want to use Vercel with serverless functions, you can't use a custom server. You can find more information about serverless here
Can You Build Backend & Frontend with Next and its API Routes
Yes, you can absolutely do it. But you have to decide whether this is a more suitable solution.
Can You Access Database in API Routes
Yes
What About SSG
As far as I know, API routes are part of a server bundle. Next.js will not statically generate page/api/**/*. All your SSG pages should work as expected.
I hope I provided some useful information here.
I am looking for some Next.js Architecture advise please 🙏
I am in the middle of migrating a very large express NodeJS app which has a custom SSR setup over to a Next.js setup.
For the current NodeJS site I have:
A bunch of routes (which hook up controllers / apis, do fancy redirections etc)
Have a ton of middlewares
Ton of logic in a bunch of express controllers (these controllers do things like API calls, transforming data, validation and the SSR of some React components to form the application)
Most of the time the NodeJS server calls other Microservice APIs (on the same VPC) to fetch data within these controllers (eg: search api, auth api, location api etc - which are all seperate REST api servers) Note: when it fetches from these APIs its done so on an internal api address only
The React Website itself calls the same NodeJS server to fetch data via client side JS when there is a route change eg: The frontend URL would be: www.mywebsite.com.au
And any api call done from the frontend is done with route: www.mywebsite.com.au/api/*
Based on all the docs i have read so far, I figure the best setup is:
To keep my existing express setup for routes / middlewares (for which I have a ton of) this includes the /api/* ones
Migrate controller fetching logic to the publically accessible express apis /api/* (which I kind of already have but need to clean up)
For the existing express controller routes, route these to Next.js instead and use nextApp.render to specific next pages
Use getInitialProps in the Next.js pages to fetch data from those apis I mentioned in 2.
Also add the old prop transform logic that was in the express controllers to getInitialProps
This is so that the server and client share the same logic of whats in getInitialProps - and this will make the architecture clean and give me the ability to have smooth transition to use Link.
The thing im struggling with it is step 4.
It means now on SSR of a page request it needs to call out to the public api (www.mywebsite.com.au/api/*) on getInitialProps to fetch its data.
To me seems like a performance overhead to do this as it requires a network hop to public domain mywebsite.com.au to fetch data it could have got locally on that same request (by calling localhost:3000/api/* for instance)
Any advise on how to avoid the network hop outside for server render?
Can I detect if its a server render and then use an internal URL (eg: use localhost:3000/api/* on the request to the same web server) or is that not best practices when using Next.js?
The server needs to call out to itself to fetch its data, alot of the overhead involved with fetching data is around the delay (I.E Between the client and nearest datacenter) this will be less of a concern when its (datacenter -> datacenter).
If performance is still an issue, your next best bet will be to do SSR caching, of which there are many different methods alot you can find in a quick google search however it will depend on your hosting/setup.
I treat listing-page.jsx and handler for api/listing route to be the same. You may need to write 2 small functions to extract the parameters passed into the request and pass it down to your service module function like ListingService.getSingleListisng(id)
I'm running integration tests on several AWS Lambda's and I need a way to route API calls to a dummy express server on my local machine. Normally I would just change the url's of the API calls, but the urls are generated in projects that are not apart of this and imported via npm, so hardcoding in a new url isn't practical.
My goal is to have these modules use the URL generated but have that routed to a dummy Express server that I'am running where I will have prepackaged responses so I can test the functionality of these lambdas. For example there is a request for an authorization token from an outside service. Instead of requesting from the actual service it would be routed to my local express server which would just provide a static authorization token. There is then another point where that token is verified and I would again hope that this would get routed to the same server (though in reality it's a different service) and it would verify the token.
Ultimately I will have this dummy Express server, a DynamoDB, and SQS, running on docker containers locally to essentially imitate this software running live.
I've seen that docker can route traffic, but I'm not sure if what I'm attempting to do will be possible. I've googled around but most of the stuff I have found seems a bit more simple then what I'm attempting.
I've implemented the shell of a microservices-based REST API application. I have simply followed the guides on Pivotal Springs' own documentation using Eureka and Ribbon for load balancing. Everything works. I have a discovery server with a handful of independent services which can register with the discovery server.
Now, my problem is that I might prefer not to write my client-side app in Java - maybe Angular or node.js, etc. However, the load balancing and connecting to the discovery server is all done in Java in the examples I've followed.
Is it possible to use JavaScript to do the same things that the Eureka client does with the Spring Boot microservices so that I don't need to be constrained in my choices of browser client technology? Does anybody have any advice for how this should be approached? I had difficulty finding any articles that cover this, to be honest.
Yes. Definitely you can choose technology of your choice for developing front end application. From your front end application, you make calls to API endpoint that you expose via your spring boot application.
You might want to expose your services via single API gateway that will help you route requests to designated micro services using your discovery server.
Actually you should not be doing load balancing/service discover etc. in the front-end. So the question about whether it is possible in JavaScript or with which libraries is irrelevant.
Typically you'll have an API gateway or a (load balancing) proxy which works with your service registry and routes requests accordingly. In the current project we use Consul for service registry and Nginx + consul-template as proxy. We plan to migrate to some API gateway.
With this setup your front-end will connect to just one central endpoint which would do load balancing/routing to individual service instances behind the scenes. Thus your front-end will not need to implement anything like Eureka/Ribbon etc.
I am a beginner with react and redux. I have searched a lot but all I get is server-side rendering, but I don't want that (correct me if I'm wrong). What I want is this:
My react-redux app calls an API to get some JSON response. The problem is that there is no user authentication (and won't be). Therefore I want to have a Token for my API calls. I need my react-redux app to obtain a token on the server-side from my locally hosted PHP (Laravel) app through an API or HTTP request. Then set that token for my client-side of the react-redux app.
I simply don't know where to start and how to have this server.js in my react-redux app.
Here is a good starter tutorial explaining how to hookup use Node and React together.
https://scotch.io/tutorials/react-on-the-server-for-beginners-build-a-universal-react-and-node-app