4 ms·

Important distinction, as it wouldn't work when JS is disabled in browsers. I don't see the point of going back to full server side, you have to scale more wit

Important distinction, as it wouldn't work when JS is disabled in browsers. I don't see the point of going back to full server side, you have to scale more with more users. The only benefit would be if it all worked without running JS in browsers, but it doesn't.

dqv 5y ago
> as it wouldn't work when JS is disabled in browsers. You can make it work when JS is disabled as well, you fall back to rendering regular HTML. It does require a little extra work, but it’s not insurmountable (e.g. using @conn instead of @socket). >you have to scale more with more users I might opt for additional optimizations once it gets bigger, but I’m not too worried about scaling Erlang processes.
beardedetim 5y ago
Yup, this is my thinking as well. If I go back to fully server side, it's because I can somehow instruct the browser to update without JS involved.
deleted 5y ago
[deleted]
BoumTAC 5y ago
Don't you have to scale your api too ?
- hunterb123 5y ago
  Yes, but now you have to scale both the data layer logic and view layer logic when doing server side rendering.
  - BoumTAC 5y ago
    So now it's two times the hassle, two times the money spent
    - porker 5y ago
      99% of the time no one runs into scaling issues and worrying about it is premature optimisation. I have to remind myself that all the time. And no, same hassle, same money spent. Thought about from the start server-side rendered pages are almost as cacheable as API responses will be. If you can't cache you're in for a world of expense at scale whichever way you go.
- beardedetim 5y ago
  I have (limited) experience scaling long-lived websocket connections and it _sucked_. It is _way_ easier to scale out little Node servers that are "stateless" than it is to ensure that Client A is connected to Socket A. I would much rather scale out my REST/Graph/RPC API instead of having to scale out a WS API.

dqv 5y ago

> as it wouldn't work when JS is disabled in browsers. You can make it work when JS is disabled as well, you fall back to rendering regular HTML. It does require a little extra work, but it’s not insurmountable (e.g. using @conn instead of @socket). >you have to scale more with more users I might opt for additional optimizations once it gets bigger, but I’m not too worried about scaling Erlang processes.

beardedetim 5y ago

Yup, this is my thinking as well. If I go back to fully server side, it's because I can somehow instruct the browser to update without JS involved.

deleted 5y ago

[deleted]

BoumTAC 5y ago

Don't you have to scale your api too ?

hunterb123 5y ago
Yes, but now you have to scale both the data layer logic and view layer logic when doing server side rendering.
- BoumTAC 5y ago
  So now it's two times the hassle, two times the money spent
  - porker 5y ago
    99% of the time no one runs into scaling issues and worrying about it is premature optimisation. I have to remind myself that all the time. And no, same hassle, same money spent. Thought about from the start server-side rendered pages are almost as cacheable as API responses will be. If you can't cache you're in for a world of expense at scale whichever way you go.
beardedetim 5y ago
I have (limited) experience scaling long-lived websocket connections and it _sucked_. It is _way_ easier to scale out little Node servers that are "stateless" than it is to ensure that Client A is connected to Socket A. I would much rather scale out my REST/Graph/RPC API instead of having to scale out a WS API.