GraphQL and the Web of APIs – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn GraphQL and the Web of APIs – InApps in today’s post !

Read more about GraphQL and the Web of APIs – InApps at Wikipedia



You can find content about GraphQL and the Web of APIs – InApps from the Wikipedia website

The API management industry is undergoing another transformation, with GraphQL increasingly seen as an emerging industry standard — not only for traditional Web 2.0 businesses, like Shopify, but also for new Web3 protocols like The Graph. While REST (Representational State Transfer) is still by far the leading format for offering APIs, some in the industry think that GraphQL is poised to rapidly increase in popularity over the coming years.

One startup intent on riding this wave, by helping developers adopt GraphQL, is StepZen. Its founder and CEO, Anant Jhingran, had a big role to play in APIs becoming a key part of the Web 2.0 ecosystem — he was formally CTO of Apigee, an API management company that was acquired by Google in 2016. To find out how APIs have evolved since his Apigee days (the glory days of REST) and why he’s all-in on GraphQL now, I spoke to Jhingran via Zoom.

Evolution of APIs in the 2010s

I began by asking how the API management industry has evolved since the early 2010s, when Apigee was managing REST APIs. Jhingran replied that from around 2010, APIs began to be used much more between third-party systems. “Maybe third-party within an enterprise,” he said, “[or] maybe third-party outside the enterprise and [in] the back-end service.” REST became the standard for those kinds of third-party interfaces. But, he added, companies like Apigee still had to do a lot of explaining to enterprises about what an API was and what it could achieve.

Read More:   How a Little Chaos Can Make Kubernetes Much More Reliable – InApps Technology 2022

By about 2015 though, APIs had become very popular — and the simplicity of REST was a big reason for that.

“All you need to do is to make a curl call, [and] you get a JSON response,” Jhingran explained, about using REST. “So it’s just: I make a call, I get a response. [They] can parse the response in whichever way they want. And so it was really a very, very simple contract between the backend service people and the frontend — and that’s why it became really popular.”

However, although consuming an API became increasingly easy for businesses, creating an API wasn’t necessarily simple in 2015.

“Just because it was simple for the frontend team […] or the app developer to consume, didn’t mean it was easy for somebody to actually build a particular API,” Jhingran said. “The backend teams at that time had to kind of work through: What are the security issues? What structure do they actually give to the other team? How do they provide documentation around it, etc.”

According to Jhingran, it took a decade and a half for backend teams in enterprises to “get comfortable with deploying secure, scalable consumable APIs.” But while they were finally reaching that level of comfort with REST in the mid-2010s, “the shape” of APIs (as Jhingran put it) began changing. Enter GraphQL.

The Changing Shape of APIs

After its release in September 2015 by Facebook, GraphQL was immediately attractive to frontend developers. It allowed developers to precisely define what data they wanted, in a way that was “much more intuitive” according to Jhingran. However, he said, backend developers were again playing catch-up.

“But the fundamental problems still remain,” he said, regarding the challenges for backend teams with GraphQL. “What are the skills? How do you actually secure it? How do you connect to the backend? How do you ensure that you’re not leaking some data that you’re not supposed to? How do you do it at web scale? With this new Jamstack [architecture]?”

Read More:   Microsoft OpenJDK Goes GA at Build – InApps 2022

Jhingran says he doesn’t want it to take another 15 years for backend developers to get comfortable with GraphQL. That’s why he started StepZen, which he says aims to “accelerate that inflection point” by giving backend developers a platform to build and deploy GraphQL APIs.

GraphQL

GraphQL in action on StepZen.

Inflection Point for GraphQL

The inflection point for GraphQL, however, is still a ways off. While there are some major companies using GraphQL, such as Shopify, REST is still the most-used API format in many other companies — including prominent API-based public companies Stripe and Twilio. I asked Jhingran whether he sees those types of companies pivoting to GraphQL over time?

He first noted that he doesn’t see GraphQL usurping REST.

“We typically find that the REST layer that enterprises have built, [they] have embedded business logic into it. And the GraphQL there, in general, will be a composition layer — as opposed to incorporating deep business logic. And therefore, both will actually co-exist.”

However, Jhingran does think that more and more companies will start using GraphQL for their external services, a trend that will happen in stages.

“Backend teams are becoming comfortable with GraphQL for the apps that are built by the team,” he said, meaning applications developed internally. Backend developers will take more time to get comfortable using GraphQL APIs from third-party companies, although Jhingran pointed to GitHub and Shopify’s GraphQL APIs as early examples.

Horses for Courses

Last May I spoke to John Musser, the founder of long-time API directory ProgrammableWeb and now director of data and analytics at Ford’s Autonomous Vehicles division. He pointed out that “what’s really happened in the last five years or so is a proliferation of other suitable non-REST APIs” — which includes GraphQL, but there are other options too, such as gRPC, WebSocket, and webhooks.

So I asked Jhingran what GraphQL isn’t suitable for?

Read More:   How Express Scripts Tackles Complex Automation on Cloud Foundry – InApps 2022

“GraphQL is not appropriate for what I would call long-running processes,” he replied. So for example, a heavily analytical workload would not be suitable for GraphQL. In that kind of workload, he explained, “the backend system is just kind of chugging along, and you’re waiting for the data to be returned. Whereas GraphQL is, in general, designed for about one second or two seconds or three seconds, to get some response from multiple subsystems.”

Web of APIs

Lastly, we discussed the future of APIs. Given the increased options now available for API developers, how will the industry continue to evolve in the next few years?

Jhingran thinks that just as the first 30 years or so of the web was about interconnecting web pages and applications, in the coming years “​​a web of API’s is going to get interconnected.” His inspiration is what Google did for web pages.

“Google search did a lot of complicated things in the backend,” he said, mentioning PageRank as an example. “They made the search bar extremely consumable.”

Similarly, he wants to make GraphQL easy for developers to use — to hide the complexity for both backend and frontend developers.

This is a similar philosophy to most “serverless” companies in today’s software landscape — Vercel, for instance, aims to abstract away complexity for developers. But also, it’s a continuation of the trend for middleware companies to provide API management platforms for enterprises — like Apigee and MuleSoft from the first era of web APIs.

The key difference with APIs in 2022 is that there are now several viable alternatives to REST, with GraphQL being the most promising.

Photo by Tim Mossholder from Pexels.



Source: InApps.net

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download

      Success. Downloading...