At Accent, we’re seeing a big trend in our clients wanting to allow other parties access to their systems and their data, which means we must provide a way for a trusted third party to access the systems we are building. Providing client access to your application may give significant benefits for you in terms of saving time or improving the accuracy of the information between your application and other parties.

Typically, an Application Programming Interface (“API”) must be implemented within your application to facilitate this. The API describes a consistent mechanism and set of rules which a client application must adhere to interact with your system. These will dictate the structure that a request should take, the parameters that should be included, and the form of the response that the API will give back.

The most typical architecture to use when creating APIs is “REST”, and it is known for its consistency and simplicity. It just uses HTTP web requests to transport data, which makes it much easier than past solutions. In addition, it sets out several rules & conventions to make things as easy as possible. One of the most significant issues commonly faced by developers is that the structure of data returned in a RESTful API response is fixed, defined by the team maintaining that API. This can become an issue because client applications may want to use different data sets. In addition, the API may not allow retrieval of the exact data that you wish to, so you either end up retrieving too much information or making multiple calls to the API to assimilate all the pieces you require, resulting in greater latency.

In response to some of these challenges, Facebook created “GraphQL”, a new architecture pattern for defining APIs which deals with some of the shortcomings of REST. It’s already seen a significant amount of uptake from the larger SaaS providers such as GitHub, Paypal and Sage, to name but a few. Its real advantage is that it places the selection of the data to return in the hands of the client application, and they can return as little or as much data as they wish in a single call.

With new benefits come added complexities, caching data becomes trickier, and if your API pulls data from several different sources or microservices, giving the client access to these under a single schema may create some logistical & performances concerns. So one must review and choose appropriately based on your system structure & user requirements.

I can undoubtedly see GraphQL fitting in well on some of Accent’s projects going forwards. Providing a new level of flexibility will translate into better applications allowing us to quickly respond to the ever-increasing demands of software systems.