Moving beyond REST vs. GraphQL to platform thinking
Some developers just can’t help comparing technologies: Vim vs. Emacs, .Net vs. Java, and now REST vs. GraphQL. Our recent article sparked quite a bit of this kind of talk, even though the article wasn’t about comparing REST vs. GraphQL. Instead, it was about how REST has been limited through misunderstanding.
I don’t know about you, but I’m tired of comparing REST and GraphQL. They each bring value to the right set of problems. We need to stop using ‘vs’ and start using ‘and’ in our conversations.
What I’m really excited about is that teams are shifting from APIs as an afterthought to API-first thinking. I’m now seeing the needs of teams go beyond APIs to a complete platform that includes eventing and message streaming. Let’s take a look at what is next and how platform thinking is transforming companies beyond APIs.
The rise of platform thinking
I recently gave a webinar titled “Lessons from Transforming the Enterprise to an API Platform”. In this talk, I noted that APIs, commonly used to drive web and mobile applications, are common within the business. You can observe this by simply browsing most API portfolios and noting the hundreds to thousands of endpoints that teams have produced in recent years. A few go beyond internal use to help to extend the conversation outside the walls of the organisation to existing and emerging partners and public developers.
Platforms, at their core, seek to create an ecosystem between orgs, customers, and partners. They are the connection between everything that the company does, both internally and externally.
To support the success of an API platform, three elements are necessary:
- APIs as the platform interface
- Event notification for reacting to change
- Message streaming to act as a backbone for data
Let’s take a look at each of these elements and how they can be combined to solve today’s needs.
1) APIs: The platform interface
APIs provide interfaces to data and behavior to deliver digital capabilities, typically over HTTP. e.g.:
- Search for customer profile with account that starts with ‘abc123’
- Create a new customer profile
- Attach an account to a customer profile
This is likely the most familiar to you, as this is the focus of many API programs. Your API portfolio likely spans multiple lines of business, addressing internal, customer, and partner needs.
How APIs are evolving the API Platform
APIs as Capabilities: To date, most APIs focus on integrating one or more systems together – they act as the glue that drives the day-to-day operations. APIs are more than an integration technology – they are digital assets that represent the core business.
Choice of Protocols: As I mentioned earlier, we have more options for exposing these API-based capabilities today. From REST, to GraphQL, gRPC, and others. These choices are allowing our API platforms to mature by including more than one protocol, based on the channel, types of use cases being solved, and whether the API needs to be optimized for specific network requirements.
API Ownership: API platforms seek greater ownership and stakeholder involvement in the design phase. They also seek to view APIs as digital assets that are managed through a lifecycle, owned, and supported.
For most solutions, offering a REST-based API is a great starting point, allowing any application or automation script to interact with your API over HTTP.
2) Event notifications: Reacting to change
One of the most powerful, and underutilized, elements of an API platform is event notification support. For each and every endpoint that creates or modifies data, there is at least one event that someone may be interested in receiving notification when it happens. Additionally, internal processes not currently exposed via APIs may also benefit from event notification.
As a downstream consumer, being notified when things change or critical business events occur is powerful. You no longer need to constantly poll an API over-and-over to see if any data has changed. Instead, you can be notified when a change occurs – without the API knowing about the subscriber ahead of time. This is called loose coupling, and it helps our systems to be used in new ways without the originator of the messages even knowing about current and future subscribers.
How event notifications are evolving the API Platform
Reacting to Business Events in Real-Time: No longer will solutions need to check for state changes in batch. Instead, our solutions can listen for and immediately react to business events.
Extending the Value of Solutions: Existing solutions and APIs are no longer considered siloes. Instead, new opportunities emerge to take advantage of internal events by surfacing them alongside the capabilities offered by their APIs. This allows for new solutions to be built on top of the platform through an event-driven interaction style.
Improving API Efficiency: Rather than needing to support constant polling to check for state changes, you can reduce the resources required to support an API by pushing state change events to those interested. This can reduce the overall cost of operating our APIs in production by removing the need for consumer-based polling.
3) Message streaming: The data backbone of the API Platform
While APIs deliver data and behavior, message streaming focuses on raw data. Message streaming provides continuous, ordered delivery of atomic messages that represent state change in data and business events.
Unlike traditional message brokers, which also provide publication and delivery of atomic messages, message streams offer access to message history. This allows consumers to revisit past messages in order of publication as new needs emerge or corrective action is required.
How message streams are evolving the API Platform
Message streams are a recent addition to the platform. They focus on some specific areas of maturity:
Unlocking Business Potential: Being able to act upon data in real-time is a key focus of a maturing API platform. By being able to scale how you use your own data, you will be able to analyze and act in a more agile way.
Implementing Data Governance: The discoverability and reliability of message streams is critical in unlocking business potential quickly and with confidence. Data governance will ensure that data lineage is understood, allowing teams to quickly find, analyze, and act.
Enhancing Software Architecture: Message streams may be used to drive private microservice communication, data analysis, and machine learning. Companies have only begun to explore this opportunity.
Those familiar with message brokers will realize that this is a familiar concept. The difference between a message broker and message streaming is that message streaming allows us to revisit past messages. This gives us the flexibility of designing resilient consumers that are able to withstand network outages or that operate outside of a 24/7 always-on mode. Instead, consumers may be directly notified of changes or simply sync-up with changes since the last known message.
Conclusion: Moving beyond APIs
Technology is changing at a rapid pace. Technology leaders are charged with continually evaluating these changes, identifying value to the organisation, and providing shared knowledge on how it all fits.
Just as companies have experienced the value in a cohesive and consistent API platform, they are beginning to see opportunities to share these new capabilities and approaches into the platform. Let’s agree to stop the arguments around REST vs. GraphQL and begin to look at how they complement one another.
Looking for an easy way to manage and maximise your REST APIs? We recently launched Tyk 2.7, the latest version of Tyk Open Source API Gateway and Management Platform. Find out more about 2.7’s 160% performance boost, custom key hashing algorithms and Dashboard user groups over on the Tyk Engineering Blog. The (API) force is strong with this one.