From atoms to molecules in a microservices world…

We all heard about atomic design. You know, this thing where you design Organisms composed of Organs composed of Molecules composed of Atoms, or something like this.

Well, let’s imagine you have an open platform running thousands of microservices of regular size, providing all kinds of functionality, created by a community of companies and individuals.

What if we introduce two new features to this platform: the ability for independent services to publish and receive standard messages and the ability to compose services together in new entities using GraphQL federation.

Very soon, would appear more complex features composed of others microservices.

Some would say: “Aren’t those mini-monoliths”?

But surely they would be wrong.

No, those are still microservices, extending the functionality of others. The platform would guarantee coherence by providing strict control over how each microservice may change, and try to block/control breaking changes to the GraphQL schemas.

So what next?

I would say that complete verticals may arise in various versions, like a suite of CRM for each industry or 20 different versions PIMs.

Why?

The cost of adding extra functionality on top of the existing is low. We can see it in all distributions: Linux ones, but also Drupal’s ones, or those of ORO Platform, Saleforce, and many others. And those “organisms” would obviously need front-end UIs, that could also exist in different flavors, composed themselves of micro-frontends (from bit.dev for example).

And, the good thing is that, if each microservice has a cost, the cost of those distributions for verticals would be free-market fixed by the composition of the added value of each layer of microservices. One could then try to optimize the cost of verticals by changing involved microservices or removing some that do not provide enough value for money. And I bet the value for money of those organisms would be way better than ANY proposed by classical SAAS editors.

This is our dream.

This is what we’re building at code.store and we’re pretty excited!