From the failure of Service Oriented Architectures to the rise of GraphQL

Recommended audience: IT professionals

Every once in a while, a revolutionary technology comes along that drastically changes the way applications are built and architected. At first, only a few specialists will recognize the breakthrough: they will write articles and prototypes. Soon, it's a tsunami with all corporations rushing in.

Today I am presenting GraphQL, a middleware revolution, at last!

The major accomplishment of GraphQL, is that it inverts control of the server layer to the client. Typical SOA architectures leave the control of the data layer to the server via endpoints. The problem, especially at a large scale, is that the definition of the data entities lies in the hands of backend developers. We can fake some amount of control using query parameters, hide data model discrepancies behind a canonical model, ultimately the client is at the will of an inconsistent group of enthusiasts.

As the enterprise grows, capabilities are pushed into the middleware, which turns into more complex endpoints: the model starts to show its weaknesses as it becomes harder and harder to maintain. Over time changes require significant amounts of planning in order to ensure that they aren’t breaking the system. At an enterprise level, this is where the governance breaks apart: developers will start creating copies of endpoints to satisfy specific use cases and minimize testing efforts. 

GraphQL flips the entire server relationship model on its head. It gives the clients, who understand their domain and access patterns, the complete control over the data fetching. It does so while remaining flexible and performant, allowing us to represent our information needs in a centralized declarative way which, over time, simplifies changes and minimizes maintenance costs.

To best represent an inversion of control and the impact it could have on the middleware industry, one has to consider the impact of SQL and how it is used today to build applications. SQL, indeed, is the best ambassador of a successful inversion of control: It's one of the few technologies which survived the erosion of time.

No matter the technology, three tier applications typically make use of an access layer to query the data store. The concept is well understood in the development industry. The datastore will expose a schema; The application layer will do data access using SQL. In this model, the application has the control.

For a moment, let us consider the flip-side of this story. A world where the application needs are governed by a bunch of PLSQL developers all working in silos. Application developers are now forced into a role where they need to align the different accesses patterns. Since there are misalignments between PLSQL developers, the data structures don't align: a customer address in the billing schema, may not look exactly like another one say in the campaign management. Quickly the application layer needs to build a canonical model (a master model) to harmonize - further adding to the complexity. Senior resources are called in to put in place a governance process in order to better control change. I will stop there.

Now alter the role names and what you see is your Enterprise and the SOA complexities beneath: How inefficient! Indeed, SOA as we know it is broken from design. It all started in the 70s, date of the first RPC call and no matter the technology iteration (CORBA, EJB, SOAP, REST) none of the big primary color companies saw the core of the issue: Control! They were probably too busy selling consulting services than fixing the issue in the first place...

Beyond the purview of this article, GraphQL also solves numerous middleware issues:

• Strong typing
• Validations
• Subscriptions (which allow asynchronous client communications)
• Documentation
• Schema Introspection
• Round trip optimization

Those along with native support from the React world should tick the attention of any REST fanatic.

In conclusion, no matter the angle, inversion of control has turned out to be a successful data access pattern in the past. Should it be GraphQL or anything else in the future, I welcome any technology which attempts to solve the middleware mess and minimize operational expenses. Long life GraphQL!