Interesting approach. But if the goal is less complexity, then I think server-side rendering with a caching layer (cdn, varnish, ngnix) is a simpler option.
Although that seems simpler to describe (server side rendering with a caching layer), it introduces large amounts of complexity and unknowns. Such as:
When do you render what, and what is the state of each view at any given time?
What do you cache where and when? In Varnish? In the CDN? In the browser?
How do we invalidate the cache in all or any of those places?
How do you deploy an update so every asset is updated in every location that it might be cached? And can that updated happen atomically so that we don't get mixed resource deploys being served?
What infrastructure do we need to scale in order to handle load? Or is everything served from the CDN? If so, what logic gets which assets there and when?
How do we roll back to a previous deploy?
I speak from some bitter experience when I say that this is the tip of the iceberg, particularly on projects which need high availability and high performance.
One of the original intentions of Jamstack as an approach, and of the DPR proposal, is to avoid these sorts of unknowable conditions and make the state of the site far easier to reckon and the architecture to reason about. Persisting all things to the CDN for serving (whether entirely during a deploy or additionally after their first requests) in the way described in the DPR RFCshould allow developers to keep on avoiding these issues.
At least. That's the goal. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting approach. But if the goal is less complexity, then I think server-side rendering with a caching layer (cdn, varnish, ngnix) is a simpler option.
Although that seems simpler to describe (server side rendering with a caching layer), it introduces large amounts of complexity and unknowns. Such as:
I speak from some bitter experience when I say that this is the tip of the iceberg, particularly on projects which need high availability and high performance.
One of the original intentions of Jamstack as an approach, and of the DPR proposal, is to avoid these sorts of unknowable conditions and make the state of the site far easier to reckon and the architecture to reason about. Persisting all things to the CDN for serving (whether entirely during a deploy or additionally after their first requests) in the way described in the DPR RFC should allow developers to keep on avoiding these issues.
At least. That's the goal. :)