5 ms·

Agnostic of stack, SPAs provide a clear separation of concerns. The api layer is responsible for transforming data between the client and controlling access. Th

Agnostic of stack, SPAs provide a clear separation of concerns. The api layer is responsible for transforming data between the client and controlling access. The client is responsible for presenting the data structures provided by the api to the user, and turning user inputs into data structures that the api can consume.

enraged_camel 8y ago
Don’t forget interactivity and real-time feedback for user actions. SSR simply can’t provide that without lots of javascript thrown inside each template, and we all know what that leads to...
- lytedev 8y ago
  Also check out the newly released Phoenix LiveView!
- peteforde 8y ago
  I urge/beg you to check out the Turbolinks 5 + StimulusJS libraries, which are by the same (Rails team) people, which is no coincidence. https://youtu.be/SWEts0rlezA?t=203 https://youtu.be/SWEts0rlezA?t=203
  - frou_dh 8y ago
    There's a great podcast interview about the what/why of Stimulus: https://changelog.com/podcast/286 https://changelog.com/podcast/286
Boxxed 8y ago
I feel like this line of thinking is very analogous to the whole microservice craze -- you shouldn't need to introduce a network boundary to write well architected software. There's no reason you can't have a clear separation of concerns in a server side rendered application.
- hombre_fatal 8y ago
  What does that actually mean, though? And "there's no reason you can't, if you wanted" is a far cry from "sure, the work is already done." For example, something as simple as having a server-side rendered forum built with your favorite back-end language and now you want to build a client for it (web, iOS, Android). That basically means massive duplication as you create a json interface boundary. Yeah, you were already passing a { user, topic, posts } object to the template, so you can just serialize it your json api, right? But you can't because when you wrote that code, you knew the data never left the process. You didn't need to scrub the user.password_digest. Adding an api on top of an existing system is a lot of work no matter how much you hand wave about "well architected software." But forget over the air network boundary. How about just wanting to implement the view layer of your Rails app with Go one day? How exactly would a "well architected" Rails app help you out? The truth is that one reason that SSRs are simpler is because they are monoliths which spares you from certain classes of concerns. That's the trade-off you have to pay for if you want to cleave the monolith one day.
  - Boxxed 8y ago
    It sounds like you're assuming the SSR is not well architected and then using that assumption to prove your point. It's pretty easy to have an API layer interal to your application -- have your view templates consume that API. No reason you have to have your view templates across the network, written in another language.
    - hombre_fatal 8y ago
      No, what I would say instead is that 90%+ of SSR apps aren't architected like that, so I would accuse you of the same thing: that you're using "well architected" to describe what's actually an exotic configuration that nobody refers to when they talk about SSR, basically creating microservices on localhost that hit your own network stack which is a premature abstraction for most cases that I thought you just got done lambasting in your OP.
      - 8y ago
gambler 8y ago
To put it generously, this is theory that rarely makes it to the real world. In reality, all SPAs I've seen had chunks of business logic re-implemented on the client side, and had web services that only made sense within the context of specific user interactions. Moreover, no one stops you from separating concerns on the server side.

enraged_camel 8y ago

Don’t forget interactivity and real-time feedback for user actions. SSR simply can’t provide that without lots of javascript thrown inside each template, and we all know what that leads to...

lytedev 8y ago
Also check out the newly released Phoenix LiveView!
peteforde 8y ago
I urge/beg you to check out the Turbolinks 5 + StimulusJS libraries, which are by the same (Rails team) people, which is no coincidence. https://youtu.be/SWEts0rlezA?t=203 https://youtu.be/SWEts0rlezA?t=203
- frou_dh 8y ago
  There's a great podcast interview about the what/why of Stimulus: https://changelog.com/podcast/286 https://changelog.com/podcast/286

Boxxed 8y ago

I feel like this line of thinking is very analogous to the whole microservice craze -- you shouldn't need to introduce a network boundary to write well architected software. There's no reason you can't have a clear separation of concerns in a server side rendered application.

hombre_fatal 8y ago
What does that actually mean, though? And "there's no reason you can't, if you wanted" is a far cry from "sure, the work is already done." For example, something as simple as having a server-side rendered forum built with your favorite back-end language and now you want to build a client for it (web, iOS, Android). That basically means massive duplication as you create a json interface boundary. Yeah, you were already passing a { user, topic, posts } object to the template, so you can just serialize it your json api, right? But you can't because when you wrote that code, you knew the data never left the process. You didn't need to scrub the user.password_digest. Adding an api on top of an existing system is a lot of work no matter how much you hand wave about "well architected software." But forget over the air network boundary. How about just wanting to implement the view layer of your Rails app with Go one day? How exactly would a "well architected" Rails app help you out? The truth is that one reason that SSRs are simpler is because they are monoliths which spares you from certain classes of concerns. That's the trade-off you have to pay for if you want to cleave the monolith one day.
- Boxxed 8y ago
  It sounds like you're assuming the SSR is not well architected and then using that assumption to prove your point. It's pretty easy to have an API layer interal to your application -- have your view templates consume that API. No reason you have to have your view templates across the network, written in another language.
  - hombre_fatal 8y ago
    No, what I would say instead is that 90%+ of SSR apps aren't architected like that, so I would accuse you of the same thing: that you're using "well architected" to describe what's actually an exotic configuration that nobody refers to when they talk about SSR, basically creating microservices on localhost that hit your own network stack which is a premature abstraction for most cases that I thought you just got done lambasting in your OP.
    - 8y ago

gambler 8y ago

To put it generously, this is theory that rarely makes it to the real world. In reality, all SPAs I've seen had chunks of business logic re-implemented on the client side, and had web services that only made sense within the context of specific user interactions. Moreover, no one stops you from separating concerns on the server side.