So this is an idea for a decoupled architecture with two exemplary scenarios. The idea here is to create boundaries around parts of the system that can work in a coherent way and can be more isolated from the rest. Another approach is to use something like an onion layer around lower-level components like the content repository and (at a later point) connect that with a content integration framework for external content source while the exposed API can be kept at a higher level.
The 4 main pieces I see so far are the Content Store, Rendering Engine, Content Delivery (speak routing, caching and delivery of web content) and of course the client in form of the JS UI. The client should be completely decoupled from any server rendering, so no augmentation takes places but everything is done via APIs.
This architecture is neither finished nor complete, but should show what the main idea behind my thoughts is.
Thanks a lot for coming up with this! I think that already looks very promising (especially after talking to you to understand some more details behind it)…
It would be great to get a bit more concrete with this in order to approach the boundaries of the individual parts (I think that’s one of the main challenges of a distributed architecture). This would also expose the parts that are “cross-cutting” like authorization and how we could tackle that.
For me personally it helps a lot to think in “microservices” even if we might end up with all components talk to eachother “directly” via PHP APIs. More concretely I think one could start with a possible & theoretical REST API for the different components (even if they might not provide one in the end). That way we’re forced to think distributed and decoupling will come more naturally…
