Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

API Gateway as a Node and Moving Beyond Backend and Front-end

DZone's Guide to

API Gateway as a Node and Moving Beyond Backend and Front-end

Read on to see if the role of the API gateway is evolving, and take a look at one viewpoint that sees a changing role for it.

· Integration Zone ·
Free Resource
CRM integration has become the cornerstone to meeting initiatives across organizations. Explore the top 6 value-driven Salesforce CRM integrations ebook.  

The more I study where the API management, gateway, and proxy layer is headed, the less I’m seeing a front-end or a backend, and I’m seeing just a node that can connect to existing databases, or what is traditionally considered a backend system, but also can just as easily be a proxy and be a gateway to any existing API. A lot has been talked about when it comes to API gateways deploying APIs from an existing database. There has also been considerable discussion around proxying existing internal APIs or web services so that we can deploy newer APIs. However, I don’t think there has been near as much discussion around proxying other 3rd party public APIs — which flips the backend and front-end discussion on its head for me.

After profiling the connector and plugin marketplaces for a handful of the leading API management providers, I am seeing a number of API deployment opportunities for Twilio, Twitter, SendGrid, etc., allowing API providers to publish API facades for commonly used public APIs and obfuscate away from the 3rd party provider and make the API your own. This allows providers to build a stack of APIs from existing backend systems, private APIs and services, as well as 3rd party public APIs. This shifts gateways and proxies from being API deployment and management gatekeepers for backend systems to being nodes of connectivity for any system, service, and API that you can get your hands on. It changes how we think about designing, deploying, and managing APIs at scale.

I feel like this conversation is why API deployment is such a hard thing to discuss. It can mean so many different things and be accomplished in so many ways. It can be driven by a database, by strictly using code, or just by taking an existing API and turning it into something new. I don’t think it is something that is well understood amongst developer circles, let alone in the business world. An API gateway can be integration just as much as it can be about deployment. It can be both, simultaneously. This further complexes what APIs are all about, but also makes the concept of the API gateway a more powerful concept, continuing to renew this relic of our web services past into something that will accommodate the future.

What I really like about this notion is that it ensures we will all be API providers as well as consumers. The one-sided nature of API providers in recent years has always frustrated me. It has allowed people to stay isolated within their organizations and not see the world from the API consumer perspective. While API gateways as a node won’t bring everyone out of their bubble, it will force some API providers to experience more pain than they have had historically. Understanding what it takes to not just provide APIs, but what it takes to do so in a more reliable, consistent and friendly way. If we all feel the pain and have to depend on each other, chances are, we will show a little more empathy.

Sync, automate, and notify lead to customer changes across marketing, CRM, and messaging apps in real-time with the Cloud Elements eventing framework. Learn more.

Topics:
integration ,api gateway ,node ,front end ,back end ,evolution

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}