4 ms·

>Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff Why’s that?

debaserab2 9y ago
If your react/vue codebase is isolated to client end, how is your server going to render react/vue code?
- kbutler 9y ago
  For server-side rendering see next.js for react and nuxt.js for vue.
  - nihonde 9y ago
    And fastboot for Ember.
  - jensvdh 9y ago
    Hypernova is pretty awesome for React as well!
- Can_Not 9y ago
  You have a simple nodejs server that renders using react nextjs, vue nuxtjs, angular universal, or ember fastboot while using rails for your APIs.
  - weego 9y ago
    So now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.
    - wcarron 9y ago
      Thus creating cleaner, more focused, more testable, likely faster, and more maintainable code bases. Which also adhere to the Single-Responsibility Principle. We as developers already offload certain tasks to separate servers. Do you use your app server to terminate TLS connections? You could; but why would you when Nginx can do a much better job of it? You could store you application data like usernames and password in a JSON file if you really wanted to. But why would you when you can run an SQL server and use a real database? Pick the best tool for each job. JS frameworks handle the view layer better than Rails does.
      - debaserab2 9y ago
        More testable? Because they are discrete codebases, possibly. It sure sounds like getting a dev environment setup that mirrors the production env just got a lot harder. Given there is an entire new codebase there is now an overall larger coverage area to test. Faster? I don't see how putting an entire app server layer in between your HTTP requests is going to make anything faster. More maintainable? You now have an entire codebase duplicating the request your client is making. It actually breaks SRP more than it helps, because you'll need to constantly keep it in sync with your rendering/client codebase in order to perform server rendering. The individual codebases may be more maintainable but your application as a whole now has fragmented responsibilities. I can't imagine when the trade-off of introducing an entire new layer of infrastructure into your app in addition to your normal app servers would be worth it just for the purpose of server side rendering outside of some specific niche scenario. That sounds like overengineering to the extreme.
        Can_Not 9y ago
        > You now have an entire codebase duplicating the request your client is making This is factually wrong. You have a small component that mounts your front-end like a pure function. No loss in maintainability, no "duplicate" anything.
        debaserab2 9y ago
        Not at all. There are two HTTP requests: one from your client to your rendering server and one from your rendering server to your app. That's two different places that logic must be deployed to and tested against. It's irrelevant that it's the same render code.
    - Can_Not 9y ago
      The Nuxtjs (and the others) SSR peices are not "an entire extra app you write and maintain", it's a small component, mostly already written by the nuxt team, that does one thing. It allows you to write a leaner, better focused backend.

debaserab2 9y ago

If your react/vue codebase is isolated to client end, how is your server going to render react/vue code?

kbutler 9y ago
For server-side rendering see next.js for react and nuxt.js for vue.
- nihonde 9y ago
  And fastboot for Ember.
- jensvdh 9y ago
  Hypernova is pretty awesome for React as well!
Can_Not 9y ago
You have a simple nodejs server that renders using react nextjs, vue nuxtjs, angular universal, or ember fastboot while using rails for your APIs.
- weego 9y ago
  So now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.
  - wcarron 9y ago
    Thus creating cleaner, more focused, more testable, likely faster, and more maintainable code bases. Which also adhere to the Single-Responsibility Principle. We as developers already offload certain tasks to separate servers. Do you use your app server to terminate TLS connections? You could; but why would you when Nginx can do a much better job of it? You could store you application data like usernames and password in a JSON file if you really wanted to. But why would you when you can run an SQL server and use a real database? Pick the best tool for each job. JS frameworks handle the view layer better than Rails does.
    - debaserab2 9y ago
      More testable? Because they are discrete codebases, possibly. It sure sounds like getting a dev environment setup that mirrors the production env just got a lot harder. Given there is an entire new codebase there is now an overall larger coverage area to test. Faster? I don't see how putting an entire app server layer in between your HTTP requests is going to make anything faster. More maintainable? You now have an entire codebase duplicating the request your client is making. It actually breaks SRP more than it helps, because you'll need to constantly keep it in sync with your rendering/client codebase in order to perform server rendering. The individual codebases may be more maintainable but your application as a whole now has fragmented responsibilities. I can't imagine when the trade-off of introducing an entire new layer of infrastructure into your app in addition to your normal app servers would be worth it just for the purpose of server side rendering outside of some specific niche scenario. That sounds like overengineering to the extreme.
      - Can_Not 9y ago
        > You now have an entire codebase duplicating the request your client is making This is factually wrong. You have a small component that mounts your front-end like a pure function. No loss in maintainability, no "duplicate" anything.
        debaserab2 9y ago
        Not at all. There are two HTTP requests: one from your client to your rendering server and one from your rendering server to your app. That's two different places that logic must be deployed to and tested against. It's irrelevant that it's the same render code.
  - Can_Not 9y ago
    The Nuxtjs (and the others) SSR peices are not "an entire extra app you write and maintain", it's a small component, mostly already written by the nuxt team, that does one thing. It allows you to write a leaner, better focused backend.