MindGym is a company with a 20-year behavior change experience with some of the world's largest brands, like Deliveroo, eBay, Uber, Cadburys, Unilever. We do about 40 million pounds a year in revenue. We've got about 300 employees across London, New York, and Singapore, and we work with a large network of external coaches. Traditionally, our business runs on coach-led sessions of 20 up to about 1500 people.
Recently we've been building a new digital platform and had to make lots of interesting architectural decisions. The main problem we were trying to solve was serving well-structured content from our CMS.
We wanted to be able to look back in time at the actions our user took (temporal query). At the same time, we don't really want to write lots of rigid REST API and maintain the source code that comes with that.
The core of our platform makes use of event sourcing and CQRS (Command Query Responsibility Segregation). This gives us a separation of data flows in and out of the system. Every time a user interacts with the UI, it generates an event into our event API. Every time they click a button, scroll up the page, this is written to an event log. We also use some of these events to mutate states into a user interface and database.
For example, if someone clicked on a button at the end of a page, this mutates to say a user has finished an exercise and progressed on their learning journey with us.
CQRS is a little bit complex to work with: you need to deal with concerns such as event schemas, and versioning, and eventual consistency. However, there are positive impacts as well: read and write capacity can be scaled independently, because the inbound is very separate path to the outbound, and this allows for temporal queries.
We looked at about 40 different CMSs before landing on Strapi.
First, we shortlisted five of them and then did proof of concepts with only three of them. Some of the key features that brought us into Strapi were the headless architecture, GraphQL API, Active Directory single-sign-on for our content offers, internationalization, webhooks for new content, and the fact that it's open-source and uses a very similar stack to the engineers that we've got in-house.
The killer features really are around being able to define custom content types and define dynamic zones for our content offers. We can put good guard rails around content but still allow some freedom in certain areas inside of the content model.
It also allows us to build a one-to-one relationship between the UI component library and the content schema.
We've got two key data sources in this instance: our CQRS read store and the content in Strapi. We want to be able to access both from a UI and we need this to be secure. There are a few different options for how we can tackle this.
We can run some APIs for read store and access read store and Strapi separately. We could put the GraphQL server on the read store and access it from above separately, but it'd be nice if there was a tool that allows federated access.
We decided to go with a server as a nice open-source tool that can give this consistent access. We looked at the Apollo server on the backend, Hasura, and PostGraphile.
Hasura gave a really nice out-of-the-box experience with no real coding required. There's automatic schema inference from PostgreSQL, automatic inference of relationships from primary and foreign key constraints in past scripts as well, and that remote schema concept allowed us to bridge our preexisting Strapi GraphQL endpoint.
One thing that is worth mentioning is we found the configuration a little bit painful as it was all API calls rather than declarative.
We're not yet at the point where we can quantify the benefits of the approach that we've taken because we're quite a new team.
We didn't have a lot of data from before we started working on this, but anecdotally the combination of Strapi and Hasura has accelerated everything.
It stopped us needing from having to write a whole bunch of clients from backend code that I would have done on previous projects.
With Strapi Enterprise Edition, we've been able to ship new products to market in times I haven't experienced elsewhere.