APIs, also known as interfaces between systems, separation of front ends and back ends, data consumers of any kind… are really nothing new in e-commerce. In e-commerce, there have been creative solutions for colourful system landscapes for years. Nevertheless, in 2019 a buzzword like “headless” will be back on the podium. Where until recently “headless” was mentioned in the same breath as REST, another player is now entering the stage of the wider public – and quite rightly so. His name: GraphQL.
What is GraphQL?
Simply said, GraphQL is nothing more than a query language, which was published by Facebook in 2015 and is used today by other well-known players like GitHub, Pinterest or Twitter. GraphQL is used to access interfaces and to specify data types for consumer systems.
Is GraphQL better than REST?
Many comparisons between GraphQL and REST can be found on the net. You can read infinitely long discussions in community forums about which concept is the better choice. In general, an objective comparison is difficult because GraphQL (as already mentioned) is a query language and REST is just an architectural concept for network-based software published as a result of a study in 2000. My intention is not to generate SEO traffic with another GraphQL/REST comparison, but to explain why GraphQL is an interesting choice for OXID.
Why GraphQL with OXID?
There are different implementations of REST interfaces in the OXID ecosystem. This ranges from open source to customized developments exclusively in projects. OXID itself does not yet have an official REST interface, which is mainly due to the fact that the requirements of the different projects for the specification of interfaces are often very far apart. This is the reality in everyday project life, which is why promises of “high-performance standard interfaces” in the e-commerce circus often leave a bitter taste in your mouth. Problems encountered when offering “standardized” REST interfaces are above all:
-
Performance and flexibility problems by:
- overfetching: You receive (possibly a lot of) data, which you don’t necessarily need at all. Let’s take for example an interface for user, which would provide all information of a user like name, date of birth, address, phone number, e-mail address, etc. as an answer. This is an overabundance of information if, for example, you only want to display the nicknames of users for your APP. This makes the handling of the response object more difficult and can also unnecessarily affect the performance of more complicated and larger response objects.
- underfetching: Often interface responses don’t contain all the information you need for a particular use case. Let’s take for example a call for a forum, where a list of posts and followers of a certain user should be displayed. Here it is very likely – instead of one – that three different interfaces have to be requested, namely those for user, follower and posts. More requests = bad for performance. To make matters worse, the three independent answer objects could have to be merged into a single object, which is exhausting and error-prone.
- Versioning of the interface: API first is an approach to counteract this problem – the perfect definition of the interface, which remains constant for as long as possible. In theory this sounds great, the reality often looks different. Besides undreamt-of innovations and features in a lively business, quite banal things such as refactoring of the data layer have to be expected, and bam, the interface must be versioned. A big problem with frequent versioning is finding errors between the independent systems, which can sometimes become a real PITA. Unfortunately, REST does not provide a uniform versioning concept, which is why versioning usually occurs in the header or in the URI itself.
GraphQL was developed – as advertised on the official website https://graphql.org – with just those intentions, which address exactly the above mentioned problems:
-
Performance and flexibility problems by:
- Minimization of requests: GraphQL “bundles” different requests into a single request by resolving dependencies between the data.
- Deliver only what is needed: With GraphQL you don’t ask a fixed interface endpoint for a rigid result object, instead you define in the query what the desired result should look like.
- “Evolving APIs without version”: Due to the flexibility of the query options described in the previous point, you can easily add for example new features to a GraphQL interface without breaking a connected front end.
You can’t say in general that “GraphQL is better than REST”, because that depends clearly on the application scenarios and requirements. But one can say with certainty that GraphQL is an absolute added value for problems in daily and fast-moving e-commerce business!
We have already had very good experiences with the use of GraphQL in projects, which is why we decided to integrate GraphQL into the core of the OXID eShop. For the realization of this project we have chosen an Open Innovation approach.
Open Innovation at OXID!
Since GraphQL is largely new territory for many developers – and for us, too – we have decided to work with a variety of groups in our ecosystem to develop it, to draw on experience, and to work together to drive innovation. We have formed a task force with representatives from the community, enterprise and solution partners, customers, OXID Professional Services and OXID Core Development. This task force has discussed experiences and learnings of used REST interfaces, as well as priorities and milestones in the connection of GraphQL to OXID.
As a manufacturer of standard software, we have the philosophy that innovation is most likely not created at the basis (i.e. within the masses), but at the top. Innovative features are created by the domain experts in the projects, in agile use cases, in A/B tests in small scenarios in live operation, where you have more scope for risks. High innovation risk in standard software, on the other hand, means turning all customers into test balloons for technology experiments and shifting the risk to the customer. Therefore, our responsibility is less to produce finished “innovative” features than to create degrees of freedom and a basis on which innovation can emerge. When this innovation reaches a certain maturity (functionality, stability, acceptance), it can find its way into the standard software. This is exactly how we proceeded here.
OXID itself has already implemented and documented the connection to GraphQL and released it as part of the task force. There are best practice examples of how special routes (cf. interfaces: schemas, types, mutations) should be implemented. On this basis, the remaining members of the task force can implement the routes relevant to them, which are shared and optimized within the task force. The aim here is to identify the most relevant routes, make them product-ready and then transfer them step by step to the core, until at the end “full-scale” routes are available for the OXID eShop.
