Design systems are hot and trendy right now because they are cost effective. By collecting documented UI artefacts (components, styles, themes, layouts…), they ease the collaboration between designers and developers, and they allow the reuse of the same design on several Web applications.
One of the issues challenging their adoption is their availability as universal corporate assets, agnostic about technical stacks. We solved this by packaging them as WebAssembly microservices, available on the edge, on the cloud and directly in browsers.Â
However, defining an API data format (high-level, declarative, serializable, safe, idempotent, stateless....) for those rendering services was not an easy task.
We are Drupal lovers. So, after evaluating other protocols (Protobuf, Graphql, RSC Wire…), we got a fresh look at the Render API and we fell in love again. This 15 year old API is a bit quirky and dusty, but also inspiring, standing the test of time, with clever ways of managing nesting, aggregation, alteration (preprocessing), data bubbling, caching…
So, our new API works like a charm, while being strongly and proudly inspired by 15 years of Drupal wisdom. We will show you what we kept, and also what we changed to make data structure flatter, 30% more compact, more consistent and predictable. With some ideas which could find their way to Drupal Core.
