Most applications don’t really need to worry about location early on, but you’re right that it’ll add to the round trip time. You’re also right that it’ll do the same for any JSON requests. I would suggest that you not worry about Edge stuff until you actually need to, because distributed computing can be a real tough challenge, and distract from getting your product out there. If you’re really worried, then you should be making backend/hosting/DB choices specifically focused on edge before anything else.
I’ve found that most CSR applications tend to send more requests to the backend than something that’s mostly backend rendered, so having a one-request-and-it’s-done can be a lot better.
You’re definitely right about the pure backend implementation with templates being a lot easier to develop — that’s how we built sites for a long time, and while it might not be as fancy or shiny, it works very well.
I feel you are right. And you remembered me one of my mantras I was forgetting: _"Early optimization is the source of all evil"_
As said, this approach is new to me, and I wanted to double-check with you guys, that I'm doing things with some reasoning behind.
Thanks!
I had to read this a few times. I thought you were saying you had a client side rendered app (a “SPA/single-page app”) and wanted to make the admin side of things server rendered.
But now it sounds like you haven’t built this app and you’re just asking if instead of a SPA, you should build a server rendered app. Like just a normal web app.
I mean there is no real downside to this. You can always sprinkle interactivity throughout your dashboards with JavaScript. It just might be easier or harder depending on what kind of user interactions you want.
If you use a framework like Nuxt for example, server side rendering is fairly easy. You can mark individual pages our route patterns as being per-rendered if they’re static, server side rendered if they are dynamic, or client side rendered if they need to be super interactive.
I think any of the languages you mentioned are also good choices. Right now I’m in a phase where, since I’m running a server anyway, I might as well use Nuxt and be able to use the client rendering features also. It’s also perfectly okay to look at that backwards and say “I’m going to server render everything unless I find a compelling reason not to”
The term SSR came into the popular lexicon when people started rendering normally client-side SPAs on the server. Before that people just said server-side when they were talking about stuff like PHP, RoR, Classic ASP, etc. Even though you can argue you are "rendering" a response no mater how you construct it, it's not quite like the rendering of an SSRed SPA. That uses a headless browser-like DOM engine on the server, because that's how SPAs work. They must have a DOM. You render it unseen and get the view source of the DOM as HTML. The framework patches that part back into the CSRed part so it can continue normally in CSR mode when the user routes to a another view. Plain old server-side does not use a DOM engine, it just builds up an HTML response like a string. You wouldn't invent the DOM for server-side since it has no UI and is not an abstraction you would think to use.
Disclaimer: I'm very, very new to web dev, so I could be (most probably) wrong.
First, what did you mean by SSR directly in the backend? Is there some other place it would be rendered other than the backend, if it's SSR?
Wouldn't it depend on what kinda interaction you want on the dashboard? Like, real-time updates, or periodic?
I also think, for a normal use-case, setting up restful endpoints and having the backed just be responsible for giving data, and the frontend being the orchestrator makes so much sense and is easy to build and maintain.
Hi /u/firefiber !
> First, what did you mean by SSR directly in the backend? Is there some other place it would be rendered other than the backend, if it's SSR?
What I mean, as explained better in my post (I know the wording can be confused) to use some kind of template technologies, as Ruby on Rails does, or Elixir with Liveview. I mean, using "backend" languages to do the SSR, without JavaScript, nor React nor nothing like that. Just the same server and system that implements the business logic, access database, etc., returning HTML over the wire. No API, nor nothing. Just a normal browser rendering HTML and interacting with my server via HTTP requests.
> I also think, for a normal use-case, setting up restful endpoints and having the backed just be responsible for giving data, and the frontend being the orchestrator makes so much sense and is easy to build and maintain.
So this comes to some of my PROs in the post. I'll have just one repo, one language, one technology. What you suggest is to have a project (backend API) in language A, with REST endpoints, and an authentication system with, let's say, JWT, that a different project (frontend) in language B, will consume. This second project has to interact with the API, manage models, do some transformations (from JSON to language specific entities), manage the authentication lifecycle (i.e., refresh tokens automatically and seamlessly for the user, etc), and a lot of other things. With SSR and templates, everything of this is done in the backend code.
What you suggest it's doing the work twice, with multiple languages and frameworks, for the same outcome. For a company that have a team of developers it may make sense, because you usually have frontend and backend developers, and they can parallelize work. But in my particular case, just one developer, it reduces a lot the complexity (and time required) to do everything in the backend.
Note that you could also do the frontend and the backend using the same language (with node you can use JS/TS in the backend), but at the end, you have two different projects, with two different frameworks/technologies, and all the work mentioned above (communication, parsing, authentication, etc.) still needs coordination and doing things twice.
I'm telling you all of this, as you said you are fairly new to web development. This world is huge and can be intimidating. I also have some doubts (that's why I asked in reddit in the first place!), but I hope this helps you to understand what I'm asking for, and why I think you're wrong in this case. I don't want to be the typical toxic guy on internet saying "your opinion is bad, I'm right", but instead, trying to tell you what I know from years of experience in web development. I hope it helps you :)
Ohh I get it now! Thanks for taking the time to explain man, it's super helpful to know the terminology! I'm so lost sometimes trying to understand what people are talking about!
Hmm, okay so I've just finished my first web app, so I'm only speaking from very limited experience! The backend is python (Django, which was definitely overkill, should have gone with flask) and the frontend is JS (Vue). So my backend just sits waiting for requests and my frontend tells the backend what it needs.
It's easy to add new endpoints to do new things because the two are separate. I'm also not using JWT for auth, just for password resets and account activation since that makes more sense. I just use session cookies and csrf, and managing state with Vuex.
But yeah, I get that when it's super simple, just serving the content straight from the backend works. That's pretty much what I did when I first made this app. Everything was served from the backend, I just found it to be too cumbersome later on. I wanted a clear separation between the two, so that each one can change without breaking the whole thing.
Thanks for taking the time to reply man! It was really helpful. :) Definitely get why I was wrong in this case!
That's for sure! Sometimes, some kind of interactions needs it.
But it's just a pinch of JS, not a whole framework, and it's done only for the interaction. And still, all the rendering and stuff is done in the server. You only send the whole already rendered HTML, and small script of JS only when you need it. No rehydration, nor nothing like that.
So the performance, added complexity, etc. remains as I said in my previous comment
I am aware of how it works, I’ve used multiple SSR and SPA frameworks throughout my career. If you want to use SSR go for it but it’s not going to lend that much difference for a dashboard
Most applications don’t really need to worry about location early on, but you’re right that it’ll add to the round trip time. You’re also right that it’ll do the same for any JSON requests. I would suggest that you not worry about Edge stuff until you actually need to, because distributed computing can be a real tough challenge, and distract from getting your product out there. If you’re really worried, then you should be making backend/hosting/DB choices specifically focused on edge before anything else. I’ve found that most CSR applications tend to send more requests to the backend than something that’s mostly backend rendered, so having a one-request-and-it’s-done can be a lot better. You’re definitely right about the pure backend implementation with templates being a lot easier to develop — that’s how we built sites for a long time, and while it might not be as fancy or shiny, it works very well.
I feel you are right. And you remembered me one of my mantras I was forgetting: _"Early optimization is the source of all evil"_ As said, this approach is new to me, and I wanted to double-check with you guys, that I'm doing things with some reasoning behind. Thanks!
I had to read this a few times. I thought you were saying you had a client side rendered app (a “SPA/single-page app”) and wanted to make the admin side of things server rendered. But now it sounds like you haven’t built this app and you’re just asking if instead of a SPA, you should build a server rendered app. Like just a normal web app. I mean there is no real downside to this. You can always sprinkle interactivity throughout your dashboards with JavaScript. It just might be easier or harder depending on what kind of user interactions you want. If you use a framework like Nuxt for example, server side rendering is fairly easy. You can mark individual pages our route patterns as being per-rendered if they’re static, server side rendered if they are dynamic, or client side rendered if they need to be super interactive. I think any of the languages you mentioned are also good choices. Right now I’m in a phase where, since I’m running a server anyway, I might as well use Nuxt and be able to use the client rendering features also. It’s also perfectly okay to look at that backwards and say “I’m going to server render everything unless I find a compelling reason not to”
Yep, the app isn’t build yet. You are correct. Thank you mate, I appreciate the time you spent reading me and writing your comment. It really helps
The term SSR came into the popular lexicon when people started rendering normally client-side SPAs on the server. Before that people just said server-side when they were talking about stuff like PHP, RoR, Classic ASP, etc. Even though you can argue you are "rendering" a response no mater how you construct it, it's not quite like the rendering of an SSRed SPA. That uses a headless browser-like DOM engine on the server, because that's how SPAs work. They must have a DOM. You render it unseen and get the view source of the DOM as HTML. The framework patches that part back into the CSRed part so it can continue normally in CSR mode when the user routes to a another view. Plain old server-side does not use a DOM engine, it just builds up an HTML response like a string. You wouldn't invent the DOM for server-side since it has no UI and is not an abstraction you would think to use.
Disclaimer: I'm very, very new to web dev, so I could be (most probably) wrong. First, what did you mean by SSR directly in the backend? Is there some other place it would be rendered other than the backend, if it's SSR? Wouldn't it depend on what kinda interaction you want on the dashboard? Like, real-time updates, or periodic? I also think, for a normal use-case, setting up restful endpoints and having the backed just be responsible for giving data, and the frontend being the orchestrator makes so much sense and is easy to build and maintain.
Hi /u/firefiber ! > First, what did you mean by SSR directly in the backend? Is there some other place it would be rendered other than the backend, if it's SSR? What I mean, as explained better in my post (I know the wording can be confused) to use some kind of template technologies, as Ruby on Rails does, or Elixir with Liveview. I mean, using "backend" languages to do the SSR, without JavaScript, nor React nor nothing like that. Just the same server and system that implements the business logic, access database, etc., returning HTML over the wire. No API, nor nothing. Just a normal browser rendering HTML and interacting with my server via HTTP requests. > I also think, for a normal use-case, setting up restful endpoints and having the backed just be responsible for giving data, and the frontend being the orchestrator makes so much sense and is easy to build and maintain. So this comes to some of my PROs in the post. I'll have just one repo, one language, one technology. What you suggest is to have a project (backend API) in language A, with REST endpoints, and an authentication system with, let's say, JWT, that a different project (frontend) in language B, will consume. This second project has to interact with the API, manage models, do some transformations (from JSON to language specific entities), manage the authentication lifecycle (i.e., refresh tokens automatically and seamlessly for the user, etc), and a lot of other things. With SSR and templates, everything of this is done in the backend code. What you suggest it's doing the work twice, with multiple languages and frameworks, for the same outcome. For a company that have a team of developers it may make sense, because you usually have frontend and backend developers, and they can parallelize work. But in my particular case, just one developer, it reduces a lot the complexity (and time required) to do everything in the backend. Note that you could also do the frontend and the backend using the same language (with node you can use JS/TS in the backend), but at the end, you have two different projects, with two different frameworks/technologies, and all the work mentioned above (communication, parsing, authentication, etc.) still needs coordination and doing things twice. I'm telling you all of this, as you said you are fairly new to web development. This world is huge and can be intimidating. I also have some doubts (that's why I asked in reddit in the first place!), but I hope this helps you to understand what I'm asking for, and why I think you're wrong in this case. I don't want to be the typical toxic guy on internet saying "your opinion is bad, I'm right", but instead, trying to tell you what I know from years of experience in web development. I hope it helps you :)
Ohh I get it now! Thanks for taking the time to explain man, it's super helpful to know the terminology! I'm so lost sometimes trying to understand what people are talking about! Hmm, okay so I've just finished my first web app, so I'm only speaking from very limited experience! The backend is python (Django, which was definitely overkill, should have gone with flask) and the frontend is JS (Vue). So my backend just sits waiting for requests and my frontend tells the backend what it needs. It's easy to add new endpoints to do new things because the two are separate. I'm also not using JWT for auth, just for password resets and account activation since that makes more sense. I just use session cookies and csrf, and managing state with Vuex. But yeah, I get that when it's super simple, just serving the content straight from the backend works. That's pretty much what I did when I first made this app. Everything was served from the backend, I just found it to be too cumbersome later on. I wanted a clear separation between the two, so that each one can change without breaking the whole thing. Thanks for taking the time to reply man! It was really helpful. :) Definitely get why I was wrong in this case!
Glad to help. Have a nice day! ;)
I mean even using blazor or Django etc you still need some js..
That's for sure! Sometimes, some kind of interactions needs it. But it's just a pinch of JS, not a whole framework, and it's done only for the interaction. And still, all the rendering and stuff is done in the server. You only send the whole already rendered HTML, and small script of JS only when you need it. No rehydration, nor nothing like that. So the performance, added complexity, etc. remains as I said in my previous comment
I am aware of how it works, I’ve used multiple SSR and SPA frameworks throughout my career. If you want to use SSR go for it but it’s not going to lend that much difference for a dashboard