Today I had the pleasure to attend code.talks Hamburg, a not-so-corporate conference for developers taking place for the 3rd time in a large cinema in the center of my original hometown. The event attracts more than 1.500 people to join the talks and consume loads of popcorn and Nachos and thus is one of the biggest developer conferences in Europe. Together with thePHP.cc's Arne Blankerts I gave a talk called "Two Stack CMS", explaining the concept of the same title coined by Martin Fowler.
In its core it is about inverting the direction of who triggers the content rendering: Traditionally, a request from a visitor's browser will ask the CMS, shop, or any other system, to render HTML. This markup is either returned from a page cache, or, if no cached version exists at that point, is generated by the CMS. On the second hit, the generated page can be delivered from the cache directly, until it expires. But it's exactly this last part which makes the scenario complex: when is content stale and needs to be refreshed?
The Two Stack approach replaces a cache by a durable content aggregation storage. Instead of generating the ready-to-deliver markup on request, the content creation stack pushes it into the storage whenever it changes. In Neos terms this means that, whenever an editor presses the "publish" button, all content which has been modified is pushed into the content storage. Separate from the content creation stack, a second stack is responsible for delivering content to the browser – the content delivery stack. This second layer has very few responsibilities and is highly scalable. Its task is to fetch either a ready-made page from the content storage or combine smaller artefacts into one page (for example a layout, a list of products and their respective prices) and return the result to the visitor.
Of course there's more to it than only this principle, but if you didn't think of it before, inverting the direction of this process can be an eye-opener. Pretty much like with Dependency Injection – rather simple in its implementation, but powerful when truly embraced.
I enjoyed the following discussions and conversations with attendees of the talk and really wondered why I didn't make it to the last year's editions of code.talks :-)
You find the slides for our talk at Slideshare.
Dmitri Pisarev | 02.10.2015
I accidently found myself implementing a similar approach, only on a smaller scale. I was doing a react/redux app, that needs some content to be editable by admins, so I began looking for Nodejs admin generators, but didn't find anything that would compare to TYPO3CR/Neos in flexibility. So I quickly took Neos, set it up in Raw Content Mode + created a Json TS object and quickly sketched out an API. Took me just a few hours, and I'm pretty happy how Neos was able to fit this role.
Next step would be to make all of this stuff to still be editable inline, in react components, but that would be hard to do, as react doesn't appreciate when somebody else edits DOM instead of him. So this got me thinking how Neos can fit as a content API for SPAs, and there a lot of things to discover in this area.
dasdasd | 11.05.2016
dasdasdas
dasdasd | 11.05.2016
dasdasdas
ff | 14.03.2017
ffgerg g hrte
ff | 14.03.2017
ffgerg g hrte
ff | 14.03.2017
ffgerg g hrte
ff | 14.03.2017
ffgerg g hrte
ff | 14.03.2017
ffgerg g hrte
ff | 14.03.2017
ffgerg g hrte
ff | 14.03.2017
ffgerg g hrte
Robert Fisch | 05.09.2019
Das ist super
Robert Fisch | 05.09.2019
Das ist super