I've been mulling over this weird idea that we should all be using an Edge (Web) Framework that manages the layouts + static site content, then pulls in either JSON or pre-rendered HTML templates from the more dynamic db-driven backends (which can then be in any language, and mapped to any path, and can be a majestic monolith or many microservices, whichever).
It would free things up so much - the backend team can focus on JSON/HTML templates, the designers can work directly with the website without necessarily going through dev (for better or worse ;), marketing can add all their little trackers, easy to outsource parts, and you could build up an entire cross-language ecosystem of plugins that manage anything from user accounts, billing, wikis, blogs, knowledge base, admin CRUD systems, ... yet it's all on the same site from the end user's perspective.
I think there are multiple enterprises that have (also re-)invented this architecture, but I haven't seen any serious open source offering that focuses on this type of use.
Maybe I'm missing something but what is the role of the edge web framework?
If the actual backend renders HTML and JSON and we have a CDN for static assets I'm not sure what's missing.
Sure bringing stuff onto the edge is great but if the edge needs to always forward requests upstream there is limited gain here.
Edge can win if data (as in realtime app data not just static stuff) is replicated there at least or possibly even better can allow writes using CRDTs so the edge is also a distributed DB node.
for moving data to the edge
sqlite zig postgresql https://turso.tech/blog/zig-helped-us-move-data-to-the-edge-...
Conway’s law comes to mind: the architecture of a system reflects the structure of the organization that created it.
Sounds like the Backends For Frontends pattern. Sam Newman has a nice write-up on this.
Marketing scripts often are invasive, wanting to run before all other scripts or overriding event/clickhandlers.
For me it kind of feels you need some runtime and DSL to enable all requirements in web. And Google Tag Manager isn't it.
I'm not saying we should go back to XML and XSLT but some separation of concerns would help: data, display, events, animation.
This sounds almost like a "backend for frontend" pattern.
A backend + NextJS is somewhat what you are suggesting. Backend serves json/graphQL. Frontend server is responsible for rendering, caching, templates etc. Prerendered HTML in backend will overlap the roles, so not sure if that is used.
I also mulled over this weird idea a while back!
https://github.com/bensmithett/coexist
Isn't this basically astro?