3 ms·
The main advantage I see of traditional server side rendering (like in Rails/Django) is that you develop a single project, not two (SPA + API). Instead of api
by felipeccastro 4y ago
The main advantage I see of traditional server side rendering (like in Rails/Django) is that you develop a single project, not two (SPA + API).
Instead of api models and client models, you just have models.
Instead of api routes and client routes, you just have routes.
Instead of unit testing api and client, you test one project.
Instead of having the client making N requests to load all the data it needs from the server (and being careful not to return more data than you need for performance reasons), you return an html with all the data it needs in a single request, and nothing more.
In the case of client stacks using SSR (like Next/Nuxt):
Instead of running the SPA on the server so the server returns the html rendered, you just make the server return the html rendered.
The benefit to the developer is higher productivity. The benefit to the end user should follow from that.
- jeeep 4y agoThe tight coupling removes a lot of scalability possibilities though. I understand the higher productivity argument, but wouldn't it be time consuming on the long run to lock yourself in an environment where you would have to go back and build an API if you want to extend your web app to mobile for example?
- felipeccastro 4y agoIt depends on the needs of the mobile version. Often, a well designed responsive version of the same web app is enough. Even if it's a mobile native app, you might still be able to reuse some/most of the screens with the same html in a webview. Even if you really needed it to be an API, you can always make the server side return either html or json depending on some request header. There's also a chance that the mobile version will be different enough from the desktop that it warrants new, custom built endpoints anyway.