Every developer should know this rule:
“Never write twice the same code”
Knowing that, one question falls: How to handle complex webapps development with both front & server rendering?
A brief web app history
No problems then, but not a very friendly environment for webapps, constant page reloading, poor UI interactivity and reactivity, heavy bandwidth usage etc.
Goodbye server side rendering and hello single page applications! No more page reloading, more reactive and complex interface… But all that goodness came with one painful cost: Initial page is just blank.
Here came NodeJS
Practice over theory
Look simple and obvious, but an issue quickly rise, the DOM.
That’s why a new kind of view framework appear: ReactJS-like frameworks.
These frameworks abstract the DOM, so every piece of the app can be renderer to string.
Another gap is still there (at least for a NodeJS driven app). The language is the same, but there are still differences between the NodeJs dependencies management, driven by npm and require([modulename]) and front end, driven by bower and import statements.
Here come some nice tools to our rescue: Babel, Webpack and Browserify. These tools mimic the NodeJs dependencies management for the browser. They pack all your app into a single file, browser compliant application.
The ideal architecture
There is some all-in-one frameworks for building Isomorphic applications, like Meteor, but I will present a more tunable and handcrafted architecture.
For example I set up a little git project implementing these features :
- Server-side rendering
- Standard rendering server (for performances comparison)
- Standalone rest server (API)
The ideal is to have a standalone NodeJs server, the entry point of the app. It would be handling first user request, rendering template (Written with a framework like ReactJs) and serving rendered pages and packed app files (with the help of Webpack) to the client. No data here, just views!
We would develop an API only server, with whatever language you want. This server will handle all application logic and data. As the server is only handling json or XML and no html it can be more performant than classic full stack framework (no heavy rendering libraries like twig or Razor, lighter dataflow).
Upload / Content / Images etc …
Uploads (images, files) would be stored on a specific server, like amazon service or similar.
Yes, isomorphism is not an easy thing to setup, but it is worth it, it brings to the user a huge enhancement in reliability and performance, and to the developer an easy way to maintain app.
Moreover isomorphic architecture presents some very good side effects: a complete separation of concern. You have independent tiles doing only one task at a time. So very maintainable, easily expandable (imagine you want to add a mobile app tile, you already have a working Api and uploads management).
Sources and resources: