SSR rendering support?

[galbuqp]

Hi, how can I make nextjs run in SSR (with a nodejs server) with nextron? There's any way? I mean make nextron not serve nextjs static files, but nextjs in its SSR mode.

[alexis-piquet]

No you can't. The only way to do that the usage of "ipcRenderer" for the view and "ipcMain" for the server side.

[Willem-Jaap]

To add a bit to this answer, you can have dynamic content, and probably want to. You just have to treat the renderer part of your application as a client-side javascript framework.

For functionality like serverside rendering Next needs a server. A static export of your Next application does not have this server, which means you can't use SSR.

You can use IPC in your frontend code to request data from your main process. In your main process you can get the data from a database or do a request to an external API.

Your entire application does not have to be without dynamic content, but next needs to be able to make a static export.

[nelsontss]

Is it possible to start a Next server in Production mode as you do in Dev mode? That way we could have SSR and API routes inside the next app.

[Willem-Jaap]

Nextron does not use the next.js server in production, rather it serves the files generated using next export https://nextjs.org/docs/advanced-features/static-html-export

[nelsontss]

I see that, but could it be used? Is there any specific downside to using a server in production?

[Willem-Jaap]

I think it defeats the purpose as the "server" is still on your client device.

You would download your app on the device you want to use it on, it would have to install node and install the next dependencies on the device to run the Next.js server.

You are doing all this on the clients device, because all the code running is inside the native electron binary. Why would you want to "server-side" render your desktop application?

[nelsontss]

It would be nice to use Next patterns to create API routes and use them in components, use NextAuth, and etc in electron. Besides, it would be possible to make a "web app" per client without spending money on an actual server, as each user has his own server. You will be less vulnerable to performance and scalability issues because there is only one client per server not thousands or millions. It would be also possible to pass browser restrictions like CORS in the API layer because it's running on a server.

[Willem-Jaap]

Nextron / Electron uses two processes by default: The main process This is referred to by some people as the "server", which is debatable as the definition of a server is:

a computer or computer program which manages access to a centralized resource or service in a network.

The main process does not do this, it runs inside the electron application alongside the renderer process. The renderer process is where your UI lives, the user interacts with your application using window rendered by this process.

The main process has acces to system level API's (opening / reading files etc.) whilst the renderer process does not. https://www.electronjs.org/docs/latest/tutorial/process-model

You can communicate between these processes using IPC. https://www.electronjs.org/docs/latest/tutorial/ipc

Using these processes you can create a workable "client" / "server" solution.

In my opinion the money you'd have to spend on an actual server is negligible compared to the amount of work you would have to do to create a system like you described. Also you don't have redundancy when the data is only on your clients device, if their device breaks, everything is gone.

Hope this clears things up!

[nelsontss]

Thanks for the feedback 🙏

If I implement my API routes and/or server logic in the main process and use IPC to use those routes/logic I can be decreasing the performance of my electron app because I can be blocking the main process responsible for operating the electron app as a whole right?

If I spawn a third process as a server, could it be a Next or not, I would be able to do the same without the risk of decreasing the main process performance and the whole electron app performance as consequence.

The perks of having a Next server, instead of a simple server with some API, are that the communication patterns between client and server are well established and you have nice libraries for accelerating things like NextAuth, TRpc, etc.

As to the data only on the client's device, that's not necessarily true you could have a DB in the cloud, and your API would be getting the data from that DB. Your application could not have data, in the most extreme case, and live only with API requests to other systems.

[kirill-konshin]

I wrote an article how SSR with React Server Components can be achieved https://medium.com/@kirill.konshin/the-ultimate-electron-app-with-next-js-and-react-server-components-a5c0cabda72b

[Willem-Jaap]

I wrote an article how SSR with React Server Components can be achieved https://medium.com/@kirill.konshin/the-ultimate-electron-app-with-next-js-and-react-server-components-a5c0cabda72b

This looks very cool, really interesting approach

[galbuqp]

I wrote an article how SSR with React Server Components can be achieved https://medium.com/@kirill.konshin/the-ultimate-electron-app-with-next-js-and-react-server-components-a5c0cabda72b

seems awesome mate! I will try this

[kirill-konshin]

@galbuqp @Willem-Jaap thanks guys, let me know how it goes if you try it out.