This post is an update on my progress with refactoring an applications existing API into a different API as a microservice. I have created a simple diagram to provide some context to the task.
The red indicates the old architecture with the white representing the new architecture I am creating. The applications client and the top level API already exist so it’s up to me to create the microservice and alter the client to use this new API.

The new API holds most of the backends for the various applications at MLC as services. Since these services are GraphQL based, services can use other services GraphQL queries/mutations to resolve data and perform tasks. This is super useful and provides one centralized API for most of the applications.
In this applications case, the service has it’s own database to hold data that is specific to the application and doesn’t fit in the business database that the API at the top interfaces with. I am dealing with a stock transfer application so the service database holds shipments of stock transfers while the business database holds stock levels for the various locations MLC can hold stock at. If someone was to ‘receive’ a stock transfer in the client then the shipment status in the local database changes to complete and the stock levels change in the business database to represent the movement of stock.
The process of creating the new architecture:
- Create GraphQL schema based of old schema in the .NET API with some changes/improvements in the new service.
- Create resolvers in the new service to pull data from the local database when queries/mutations are called.
- Set up the top level API to receive information from my new service.
- Modify client to use the new service instead of old .NET API.
I have completed the pull request for this task today and am waiting on suggestions from the other devs.