Migrating our clients legacy REST API and MySql database into a GraphQL API
For our most recent client, we had quite the challenging task of migrating their legacy REST API and MySql database into a GraphQL API. Our client was a startup which was growing rapidly and had evolved over the years, so the majority of their database schema and REST endpoints were obsolete. Given the conditions, we needed to build their back-end from the ground up.
Initially, we thought of going the micro-services route by splitting up their database and business logic into individually maintained services. However, after reading DHH's post about the majestic monolith, we decided to forego the micro-services architecture. There would be too many difficulties regarding how to handle network failure as well as CI/CD for each of those services.
What we liked most about the micro-services architecture is its modularity and the opportunity to work with multiple databases, so even though our codebase is going to be a monolith, it did not have to be tightly coupled. Each service can be its own GraphQL schema connected to its own database and all can be stitched together by a gateway (the server which exposes our api).
Given the following schema:
We can query its binding like so:
Most of the examples out in the wild for graphql bindings use remote schemas that require network calls. In this case, we are using locally defined schemas. I will make another post on how to accomplish this, but if you can't wait, you can take a look at the code here:https://gitlab.com/novvum/open-source/graphql-services-monorepo-starternovvum / open-source / graphql-services-monorepo-starter
As a bonus, we can use graphql-cli to automatically generate the binding and typescript types from our schema definition. For our databases, we used prisma since it already comes with bindings. This architecture also gives us some great possibilities when it comes to integrating third party services and unifying our API.
