5 ms·
The downside there is that you're then forced to build your application as a completely separate service and static site. With this approach, you can stick sing
by jnmandal 9y ago
The downside there is that you're then forced to build your application as a completely separate service and static site. With this approach, you can stick single page app where the UI needs to be more stateful and then use traditional server-templating for other things. I'm doing this w/ phoenix now and its nice because my typeahead search is done as a JS component, but the corresponding index and show pages are still mostly the same as what was scaffolded.
Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff.
- scottmf 9y ago>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 agoIf your react/vue codebase is isolated to client end, how is your server going to render react/vue code?
- kbutler 9y agoFor server-side rendering see next.js for react and nuxt.js for vue.
- Can_Not 9y agoYou 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 agoSo now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.
- wcarron 9y agoThus 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 agoMore 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.
- mmontoya 9y ago> The downside there is that you're then forced to build your application as a completely separate service and static site. That is not true, you just call what you need from the JS framework and you can still use the old HAML in the other areas.