GraphQL was created specifically to solve data problems much like the ones enterprise retailers are likely to face.
Software systems today are built as microservices that primarily ‘talk’ to one another via APIs (application programming interfaces). The API acts as a gateway between a backend data storage engine (normally a database) and a client-side application that needs to use and display the data. The Reaction Commerce platform is architected to be headless, which means our API is the only connection between the frontend client and backend server. As you can imagine, that makes our API architecture and performance critical to the success of our applications.
The technology we use for the Reaction API is GraphQL. That’s because GraphQL was created specifically to solve data problems much like the ones enterprise retailers are likely to face. It’s especially well suited to calling up data resources from multiple places and stitching them together for seamless delivery to a frontend client—exactly what a good commerce app needs to do.
GraphQL is a relatively new specification; it was created by Facebook, whose mobile apps have been powered by GraphQL since 2012, and an open source spec was released for public use in 2015. GraphQL now has its own foundation, hosted by the Linux Foundation, to ensure the future development and continuity of the spec.
For the kind of system we’ve created, a GraphQL API has three major benefits (over the more widely adopted REST standard).
For enterprise-scale retailers who can host millions of website visitors and transactions each day, those tiny demands can add up fast.
In commerce, system performance is everything. Slow-loading pages and poor response times are deadly for shopper conversions. A traditional API can make things worse by either under-fetching (not getting all required data in one query) or over-fetching (getting more data than the client application needs). Under-fetching puts a strain on system resources because the client needs to make extra roundtrips to the API to get the rest of the data it needs from different storage locations. Over-fetching, on the other hand, strains systems by making each query larger than it needs to be. The problem may not even be noticeable at smaller scales, but for enterprise-scale retailers who can host millions of website visitors and transactions each day, those tiny demands can add up fast.
GraphQL helps by 1) reducing the number of queries made to data storage and 2) making each query exactly as large as it needs to be. How? GraphQL queries are structured to allow apps to specify exactly what data they want and get just that data, rather than pulling everything that’s present in a certain database location. So a single query gets just what you need, and nothing more.
The result is a more performant system at scale. For our commerce clients, that means faster page loads and quicker conversions.
There are a lot of ways to describe the differences between data structures in REST and GraphQL. We like the way the smart folks at ApolloGraphQL say it: “In REST, the space of accessible data is described as a linear list of endpoints, and in GraphQL it’s a schema with relationships.” That statement has a lot of implications, but for our commerce customers it basically means GraphQL can create a uniform API across Reaction applications, regardless of the specific storage engines being used on the backend. It provides a lot more flexibility when it comes to the structure of the databases that our API will be making calls to. And it makes it much easier for us to “stitch” or unify multiple APIs to create a seamless experience. Ultimately, that means less work for IT teams, and it allows all our devs to work faster.
Here’s a real-world example: One of Reaction’s enterprise customers, a large international retailer, built a custom pricing engine that uses Apache Kafka as the underlying processing and storage layer. Thanks to GraphQL’s flexibility, the Reaction API is able to seamlessly stitch that pricing data alongside data coming from the more conventional MongoDB data store.
With GraphQL the data fields are specified by the client that’s making the data request, not by the storage engine where that data lives. So we can always add more objects and fields to our databases without breaking our client apps.
You can imagine how important this flexibility could be for commerce. Consider product data: When a retailer needs to add a different type of product variant to the database (‘size,’ ‘color,’ ‘style,’ etc.), for example, it’s much easier with GraphQL. The database can be expanded first, and then the client application updated whenever the retailer is ready to display the new variant. Older fields can also be removed later (once client applications no longer need them) without affecting client behavior or the end user’s shopping experience.
Another recent real-world example: A Reaction partner needed to include an extra bit of metadata on their image records so they could integrate a third party image management service. We were able to easily extend the database schema for this field and expose it to clients via GraphQL.
While we could have built Reaction using a different API standard such as REST, GraphQL is the best choice for our open, real-time commerce engine. The GraphQL API spec offers better performance, greater flexibility, and a much easier path to evolve and update the API, which is why it just makes sense.
If your legacy systems are slowing you down, now might be the perfect time to talk to our team. See if Reaction is the right solution to help drive growth and innovation for your commerce enterprise.
Get in Touch
This content was originally published here.