Digital Learnings in Sitecore & Cloud

In a Content Hub implementation you might often need to produce multiple different size of an image that you can link to from external locations. One way to do think in Content Hub would be to create multiple renditions and create public links to them, however there might be cases where you want a bit more control over which assets you create these links to and when in the lifecycle of your content you do this. In this case another useful functionality of Content Hub is the ability to apply conversions directly on public links. Within the UI you see that there a number of options for controlling the public link output: However if you want to control this programatically you will need to interact with the underlying entity record. Looking at the entity record for a public link, you see that this information is captured in a Property called ConversionConfiguration . However the content of this property is a JSON string -- so how do you interact with it from code? "

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. (1) Presentation Logic