4 ms·
Thinking out "loud": 1) How does transparent server-side rendering of Ember change the role of what was the server-side app before? Are you now managing a sepa
by cookrn 12y ago
Thinking out "loud":
1) How does transparent server-side rendering of Ember change the role of what was the server-side app before? Are you now managing a separate server environment for your Node Ember application?
2) Does this affect the ability to distribute your frontend over a CDN? Is this common practice for current Ember applications?
- wycats 12y ago> How does transparent server-side rendering of Ember change the role of what was the server-side app before? Are you now managing a separate server environment for your Node Ember application? Our goal is not to make Ember an "isomorphic" server-side framework. You would still have your regular backend responsible for generating JSON (whether that's Node, Rails, Django, .Net, etc.), and run an Ember app alongside it in the same data center to generate your HTML. In terms of server architecture, you've already separated HTML generation from JSON endpoints (for Ember, but possibly also for other clients like iOS, Android or API endpoints), and this continues that separation. The benefit is that the HTML generation that lives on the client in order to make subsequent navigations fast can also live on the server to make initial boot fast.
- chrischen 12y agoWouldn't this add processing latency? You'd have to have your original backend, it'd send to Node+Ember, then finally it responds to the client.
- wycats 12y ago> Does this affect the ability to distribute your frontend over a CDN? Is this common practice for current Ember applications? It is a common practice and it doesn't affect distribution over a CDN; it makes the CDN story stronger imo. You would still distribute the JavaScript payload and other assets necessary to boot and hydrate your app over a CDN, but you get initial content while you're waiting for those assets to download.