We have developed a Next.js app. The home page takes several seconds (7s) before initial load, thereafter requesting any additional artifacts. We call the menu and a headless api for the body. The API is fronted with Cloudflare and is part of getServerSideProps. We do use proxy middleware to call the apis.
How can we identify long running threads on SSR? Any performance optimization tips we can use?
Related
I am fairly experienced with Node, Express, and React but new to Next.
I am using Next's middleware to re-write API requests to my backend server (using NextResponse.rewrite).
I am not using Next's API functionality.
I am planning to deploy the app to Vercel.
Some of my APIs need more than 60 seconds to respond. From Vercel's Limits Doc, I see that the middleware function timeout is 30 seconds. Does it apply to rewritten requests (proxied to the backend) as well? If yes, is there a way to extend this? Without it, a Vercel deployment is out of the question and I will have to self-host Next which involves a lot more infra management.
I am hosting Strapi the headless CMS on Google App Engine and my issue is that this backend goes to sleep after some inactivity, and due to this it requires waking up when it is interacted with, resulting in a good few seconds passing by before any API calls are retrieved.
I can see on Google App Engine the logs show that the app is starting, then the network stuff happens and so on until nginx is started and then a welcome back message is stated before the API call can be seen.
Does anyone know how I can keep this running continuously without having it sleep…perhaps pinging is an option but I was hoping for a setting/config that would allow this.
Thank you
Here is a Guide for creating a strapi project on App Engine.
As mentioned in the Documentation :
Warmup requests are used by the App Engine scheduler, which controls
the auto scaling of instances based on user-supplied configuration.
With warmup requests enabled, App Engine issues GET requests to
/_ah/warm up. You can implement handlers for this request to perform
application-specific tasks, such as pre-caching application data.
The scheduler starts up instances when it determines that more
instances are needed. Warmup requests may appear in logs even if they
are disabled because the scheduler uses them to start instances.
For example, if you are using Express.js, your handler might look
like:
const express = require('express');
const app = express();
app.get('/_ah/warmup', (req, res) => {
// Handle your warmup logic. Initiate db connection, etc.
});
// Rest of your application handlers.
app.get('/', handler);
app.listen(8080);
You can also refer the forum for more information related to strapi automatic scaling on App Engine.
For more information, you can refer to the Documentation_1 and Documentation_2 to know how instances are managed and requests have been handled on App engine.
I'm trying to write some tests with cypress and fixtures on my SSR next.js app that connects to RESTful API using Axios. But I'm having trouble intercepting the RESTful APIs using cy.intercept() because cypress can not track the requests that are sent in SSR and cy.intercept() only works on requests that cypress can track. Is there any way that can help me change the responses coming from RESTful API? any packages also would help.
cy.intercept relies on the in-browser API to capture requests. The requests you do in your SSR hooks in Next.js (such as getServerSideProps) do not happen in the browser so, respectively, cy.intercept doesn't know anything about them.
I'm biased when it comes to API mocking solutions, but I still encourage you to look into MSW once again. See the official Next.js example, which supports both browser-side and server-side request interception using the same request handlers. The README also goes into detail about the key steps necessary for both interceptions to work.
This kind of interception embeds MSW into the Next.js app. This means that you won't be able to have runtime request handlers without either restarting the runtime or exposing the worker/server instance to the testing context. This may not be an issue for you per se, so you may disregard this mention until you know it's relevant to your testing setup.
Next.js is about server side rendering. Therefore have the render server (rendering the HTML) along with the API server seems to be a natural choice— it probably makes the rendering time much lower than having a separate API server (service)
That’s what I am thinking of theoretically.
But I would like to know if next.js applications are typically deployed in this way (a node server host both the api service and the next.js app).
Or does it make sense to have one service host the next.js app and another service host the rest api endpoints. e.g
Next.js is hosted on lambda edge
Api service hosted on api-gateway (+ lambda + dynamodb)
Lambda#Edge functions can only operate for a maximum of 5 seconds for viewer request functions and 30 seconds for origin request functions, so it's probably not practical to have the entire Next.js app on Lambda#Edge.
You could have individual portions of the app's logic on Lambda#Edge, but you also need to think about total package size because there are restrictions there as well.
I have a SSR react app that uses apollo. My app server lives under one domain using express while the graphql server is under another domain. I'm having issues trying to understand how the authentication should work.
Currently on my app server I create a cookie session via firebase's documentation. All is fine with that, but I have a couple questions.
I'm currently using firebase's admin SDK to authenticate the request both on the app server and graphql server. I'm doing this because the initial SSR page gets rendered on the server, while all subsequent requests go directly do the graphql server. The redundancy of the authentication doesn't seem to be the right way to do this. Can someone verify?
If this isnt' the right way to do things, should I set up a simple proxy for all graphql requests from my. Essentially making all graphql request going from the client to my app server, which then goes to the graphql server under the hood?
Any other recommendations how to properly set this up? I'm at a complete loss here