Some time ago, when looking for articles about the pros and cons of microservices architecture, I couldn’t find what I was looking for. In the DNA of Divante, we have it hard-coded that “if you can’t find something you need, you should build it”. This is normally the case for technology but I started writing and researching a few articles on the kind of content I would like to read myself… and then the project took on a life of its own. 

As an open-source company, we wanted the knowledge we found to be shared with the world. The Microservices Book has therefore become a true, open-source collaboration project that is constantly growing and improving. It’s open to all, published on GitLab, and has contributions from external thought leaders like Antoni Orfin, Mike Grabowski, Michał Kurzeja, and Mariusz Gil, as well as myself and our own Bartosz Picho.

You can even join that group. If you want to add a chapter or improve the content in any way, you can add it just like a pull request with code. 

For now, here is a sample of the content from the book: Enterprise GraphQL and microservices.

Visit https://microservicesbook.org/ and view the full 'Microservices Architecture for eCommerce' book. You can also gain free access to the PDF download and find links to become a contributor.

Enterprise GraphQL and microservices

GraphQL can be a perfect way to integrate different data sources, mixing PIM and CMS data into a single, strongly-typed schema. Then, having just the Backend For Frontends (BFF) pattern implemented out of the box. Just taking these two examples shows why this standard is replacing the older REST APIs, especially when it comes to implementing headless eCommerce applications. Development experience and the performance are one thing but the other question is: how can we manage GraphQL APIs at scale?

To provide the Enterprise-grade level of service levels (SLA) it won’t be enough to just write some Node.js/TypeScripted GraphQL resolvers. It may be a good starting point but the maintenance and fine-tuning could be tough. 

I’ve put some notes based on the research I recently conducted for one of our clients. I’d like to showcase some enterprise-level features that should be considered when promoting GraphQL API to production. I’ve listed the viable commercial and open-source options where appropriate. 

Schema Management

Creating complex GraphQL schemas is not that easy. Code level schema management can quickly lead to conflicts, especially when different units are adding up their contributions. One of the powerful tools for handling this issue is GraphQL Editor. Online collaboration and visual schema editing are just a couple of the features that scale well over the enterprise.

It’s a viable alternative to Apollo Graph Manager (a commercial product from Apollo team), and has features a including Schema Explorer and History Versioning (limited).


Schema Versioning

Versioning is very important when designing the Schema. You must figure it out before you start the implementation. It’s very often convention over configuration. The Microservices concept strongly follows the idea of service-level deployability. You should be able to develop and upgrade the services, by different teams at different paces, while keeping the service contracts. In GraphQL, many services (resolvers) can be merged into a single schema (Schema Stitching/Federation or tools like storefront-api are made for this purpose).

GraphQL itself doesn’t force one way of handling the versioning. You can, instead, find various best practices in published case studies. One of the best options for API versioning I have found is the Shopify API Versioning concept. They’ve created a really powerful GraphQL Design Tutorial which is well worth reading as it’s still a pretty unstandardized field at the moment.

Continuous Delivery (CI/CD)

Deployability is another topic to discuss. It’s directly related to Schema Versioning and the versioning of your GraphQL resolvers. Apollo GraphQL Manager lets the developers apply hot-updates. They can push out the new services and do upgrades without even shutting the whole service down.

By using the visual schema editor, or just code for managing the schema, we usually end up with the couple of `*.graphqls` files that are sourced into apollo-graphql-server instance. 

This is a good news because it makes the whole process of schema management suitable for CI/CD pipelines (like Travis, Jenkins, etc). I didn’t find any out-of-the-box open-source, hot-reload solution for graphql schemas but I can imagine implementing it via something like a `nodemon` setup.

The interesting option is the `graphql-factory` which lets you update the schema programmatically on the fly. However, it doesn’t look like a production-grade solution. It’s more like an inspiration than a product.

One way or another, what you really need to consider is the change tracking and service contracts. GraphQL Doctor can be a solution for this issue. It’s a tool, which is integrated with Github Tasks, and works perfectly well by discovering all the breaking changes before they get deployed.

GraphQL Security Scanning

GraphQL Doctor helps with automatic schema validation and change tracking. The open question—and it’s a quite important one—is how can we be sure that our GraphQL implementation doesn’t contain security flaws and vulnerabilities? 

GraphQL implementations, as with all the data sources, are endangered by information leaks and popular attack vectors. In the end, it is just a web application. The problem is with security scanning, as there are not so many pen-test applications suitable for GraphQL.

Actually, I found just one open-source security testing tool for GraphQL, which is InQL Scanner. If you’ve ever struggled to find vulnerabilities in your GraphQL code, this tool should be able to help. InQL Scanner, initially developed by Doyensec Research Island for their own internal use, is now free to use and available on GitHub. It enables you to quickly extract and inspect metadata information. You can then more easily identify security issues which, due to the descriptive nature of GraphQL, would be otherwise hard to detect.

Performance metrics

I can’t imagine having the system up and running without a monitoring infrastructure. Usually, most of our clients choose Graylog or/and New Relic for application monitoring

Whereas Graylog is focused on application logging, New Relic is centered around the performance and numerical metrics of your applications and servers: network response times, CPU load, HTTP response times, and network graphs, as well as application stack and traces with debugging information.

New Relic is great for Web Applications; however, for GraphQL you might want to track some additional parameters like:

  • Performance of Resolvers – to get better visibility into how to make individual resolvers better
  • Performance of individual attributes – to get better visibility into metrics around assigning attributes in types

Actually there are not so many open source apps for digging deeper with the analytics; possibly the one one is query level tracing for Apollo which is open-source. By using New Relic, we can set special custom events/metrics in the resolvers code or use the stack-trace tracking. 

Make eCommerce ready for changes with microservices architecture  data-src=

Piotr Karwatka

CTO at Divante eCommerce Technology Company. Open-source enthusiast and life-long builder. Co-founder of Vue Storefront and Open Loyalty. Now gathering engaged communities around new technologies. | LinkedIn | Twitter

Share your comment