Digital Learnings in Sitecore & Cloud

Sitecore JavaScript Services (JSS) was launched, now a few years back, as Sitecore's solution for meeting the needs of doing headless content mangement on Sitecore using JavaScript, without losing the key capabilities (especially in line editing) which makes Sitecore great. It consisted of JavaScript SDKs that worked with the JSS layout service running on Sitecore. Now renamed the Sitecore JavaScript Rendering SDK , and supporting the JSS services or Experience Edge, this SDK is an important part of delivering JavaScript web apps leveraging Sitecore editing capabilties. That said, for a lot of front end developers JSS is a skillset that they might not know a lot about. Using it properly requires not only an understanding of how to install and work with the SDKs, but also understand Sitecore concepts such as placeholders. Furthermore not all web use cases, even those that leverage content, benefit from such advanced capabilities. Benefits and complexities I see the followin...

We are now well and truly in the age of the API, however I feel that there is still a lot of confusion about the best patterns to put in place in how to structure APIs,  There are a number of competing patterns with some overlap and plenty of trade-offs, particularly in the space of building digital systems where the MACH alliance  is gaining momentum.  Some of the patterns you might have heard of include Microservices, Backends-for-Frontends (BFF) and domain services. I personally prefer to think about structuring APIs in terms of the different types of logic the a system composes of and how this impacts the trade-off between pace of change/innovation compared to reuse and stability.  These two forces are in constant tension in enterprise level development, and is well captured in Gartner's  Pace Layered Architecture  concept. Layers of logic I like to categorise the logic implemented a system into four different layers, as shows in the diagram below. ...