Panel Discussion: The Future of GraphQL in the Enterprise (by GraphCMS)

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Panelists:

Michael Lukaszczyk - Founder and CEO, GraphCMS

Uri Goldshtein - Founder and CEO, The Guild

Evan Weaver - Co-Founder and CTO, Fauna


Moderator: Alexandra Buckalew - Senior Product Marketing Manager, GraphCMS

FAQ

Initially niche, GraphQL gained popularity by addressing pain points associated with REST APIs. Its adoption has grown, with its use expanding from simplifying data fetching processes to becoming a standard for building scalable and efficient APIs.

GraphQL is a query language for APIs and a runtime for executing those queries by using a type system you define for your data. It provides a more efficient, powerful, and flexible alternative to the traditional REST API.

GraphQL serves as a contract between backend and frontend teams through its schema definition language (SDL), which facilitates clear communication on the data requirements and capabilities, allowing for parallel development and more cohesive collaboration.

GraphQL offers benefits such as reducing over-fetching and under-fetching of data, providing a powerful type system for APIs, enabling better team collaboration, and facilitating easier integration with various microservices and third-party APIs.

API federation with GraphQL refers to an architecture where multiple APIs can be combined into a single GraphQL schema, allowing developers to query data from multiple sources as if from one unified API. This approach enhances the developer experience by simplifying data integration and management.

Future developments for GraphQL may include enhancements in security standards, more widespread adoption beyond just application development (e.g., by data analysts), and innovations that simplify complex data integrations across diverse systems.

GraphQL handles security through fine-grained access control and validation mechanisms. Performance in enterprise applications is managed by optimizing queries with features like query batching, caching, and by limiting query depth and complexity to prevent abuse.

One of the main challenges is managing complex authorization rules across various services when federating APIs. Additionally, ensuring efficient data fetching and handling the integration of different data sources without performance bottlenecks remains a significant challenge.

Uri Goldshtein
Uri Goldshtein
Michael Lukaszczyk
Michael Lukaszczyk
Evan Weaver
Evan Weaver
Alexandra Buckalew
Alexandra Buckalew
37 min
09 Dec, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Discussion on GraphQL and enterprise featuring panelists Evan Weaver, Uri Goldstein, and Michael discussing their experiences with GraphQL and their respective roles in the industry. Exploration of early adoption and evolution of GraphQL, highlighting its significance as a contract layer between backend and front end data APIs. Evolution from binary interchange formats to GraphQL, merging semantically constrained and high-performance aspects in API development. GraphQL's benefits in architecture, content federation, and API composition enhancements. Evolution of GraphQL towards internal infrastructure use and seamless API integration. Challenges in decentralized data communication, significance of GraphQL integration with Fauna, and potential evolution of GraphQL mutation support. Community-driven evolution of GraphQL, broader usefulness predictions, and feature expansion vision for GraphQL's future.

1. Introduction to GraphQL and Enterprise

Short description:

Welcome to our discussion on the future of GraphQL and Enterprise. I'm Alex Bukalu, the Senior Product Marketing Manager with Graph CMS. We have prepared questions, but feel free to ask your own in Discord. Now, let's start with introductions. Evan Weaver, CTO and co-founder of Fauna, shares his experience with GraphQL. Uli Goldstein, from The Guild, discusses their work with GraphQL and open source projects.

Hi, everyone, and welcome to our discussion around the future of GraphQL and Enterprise. As we already said, my name is Alex Bukalu. I am the Senior Product Marketing Manager with Graph CMS.

Before we get started on introductions, I just want to say we do have some questions already prepared, but if you have any questions for our panelists, please put it in Discord. We will try our best to get to all of them, but our panelists will definitely reach out to you afterwards if we can't make all the questions.

All right, so no one came to hear me talk, so let's get started with a round of introductions. If everyone could say their name, what you're currently working on, or where you're currently working, and then a little bit of background into your experience with GraphQL. Let's start it with Evan. Hi, I'm Evan Weaver. I'm CTO and co-founder of Fauna. Fauna is a serverless data API with a GraphQL interface, and my first exposure to GraphQL was through Fauna. So, I worked at Twitter before Fauna, and then we were a consultancy for a while, moved into database development, because we felt like the world wasn't difficult enough for us. We were a tech-first startup focused on solving these global transactional data distribution problems. And we found that ultimately, we had a shared vision with people in the JAMstack space, the React.js space, the GraphQL space, everyone working in kind of this new stack environment who wanted to consume software via APIs, not from provisioning infrastructure and that kind of thing. And that led us to adopt GraphQL as our native interface for Fawna, and it's been off to the races since then. And we're excited to help with other vendors in the space and build this new stack and new ecosystem.

Nice. Ari? I'm Uli Goldstein. I'm a member of a group called The Guild. We do a bunch of open source work around GraphQL and in general. The first I heard about GraphQL was actually... I used to work at Apollo, but at that time, it wasn't Apollo. It was Meteor.js. And we were... It was a full-stack framework, written in JavaScript, and we're debating what would the next major version of Meteor would be. And at the exact same time or around the same time, Facebook released GraphQL. And we kind of like shifted into, you know, like, first of all, that we want to focus on the data layer and then also that we want to build solutions around GraphQL. And that's what became later on Apollo and Apollo Server and Apollo Client. But ever since then I left Apollo and started the guild. Very nice.

1. Panelists Introductions and Experiences

Short description:

Discussion on GraphQL and enterprise featuring panelists Evan Weaver, Uri Goldstein, and Michael discussing their experiences with GraphQL and their respective roles in the industry.

Hi, everyone, and welcome to our discussion around the future of GraphQL and enterprise. As we already said, my name is Alex Buckaloo. I am the Senior Product Marketing Manager with RastCMS. Before we get started on introductions, I just want to say we do have some questions that are already prepared, but if you have any questions for our panelists, please put it in Discord and we will try our best to get to all of them, but our panelists will definitely reach out to you afterwards if we can't make all of the questions.

All right, so no one came to hear me talk, so let's get started with a round of introductions, if everyone could say their name, what you're currently working on or where you're currently working, and then a little bit of background into your experience with GraphQL. Let's start it with Evan. Hi, I'm Evan Weaver. I'm CTO and co-founder of Fauna. Fauna is a serverless data API with a GraphQL interface, and my first exposure to GraphQL was through Fauna. So I worked at Twitter before Fauna, and then we were a consultancy for a while, and moved into database development because we felt like the world wasn't difficult enough for us. And we were a tech first startup focused on solving these global transactional data distribution problems. And we found ultimately, we had a shared vision with people in the Jamstack space, the React.js space, the GraphQL space.

Everyone working in kind of this new stack environment who wanted to consume software via APIs, not from provisioning infrastructure and that kind of thing. And that led us to adopt GraphQL as our native interface for Fauna, and it's been off to the races since then. And we're excited to help with other vendors in the space build this new stack and new ecosystem. Nice. Uri. I'm Uri Goldstein. I'm a member of a group called the Guild. We do a bunch of open source work around GraphQL and, in general. The first I heard about GraphQL was, actually, I used to work at Apollo, but at that time it wasn't Apollo, it was Meteor.js.

And we were, it was a full stack framework written in JavaScript and we're debating what would Meteor, what would the next major version of Meteor would be? And at the exact same time, or around the same time, Facebook released GraphQL, and we kind of like shifted into, you know, like, I thought, first of all, that we want to focus on the data layer, and then also that we want to build solutions around GraphQL, that's what became later on Apollo, and Apollo Server, and Apollo Client. But ever since then, I left Apollo and started the Guild. Very nice, very nice, thank you. And last but not least, and not only just because he's my boss, Michael.

Thanks, Alex. It was a great intro also from your side. So I'm Michael, I'm the CEO and Co-founder of GraphCMS. We provide a GraphQL native content management platform. So you can use GraphCMS to distribute your digital content onto any platform.

2. Introduction to GraphQL Adoption

Short description:

I'm Michael, the CEO and co-founder of GraphCMS. We provide a GraphQL native content management platform. My first touchpoints with GraphQL were early on, and I found it very interesting due to the pain points with REST API. We had the idea to build the first GraphQL enabled headless content management platform, which has now become GraphCMS. It's exciting to see how GraphQL has changed over the years. We'll discuss the adoption of GraphQL in this panel talk.

Very nice. Thank you. And last but not least, and not only just because he's my boss, Michael. Thanks, Alex. That was a great intro also from your side. So I'm Michael. I'm the CEO and co-founder of GraphCMS. We provide a GraphQL native content management platform so you can use GraphCMS to distribute your digital content onto any platform. And my first touchpoints with GraphQL actually were quite early. So soon after the first spec got released, I think it was end of 2015. It was very niche back then, but it was all the buzz on some medium, on some Reddit. I was consuming all this stuff and I found it very interesting because back then I find there was a lot of pain points when working with REST API. So I found this technology, GraphQL, I found very interesting. And soon later actually, we had the idea to build the first GraphQL enabled headless content management platform, which has now become GraphCMS. So we've been adopters from the first day and it is very exciting to observe also throughout the years, how GraphQL has changed over the years. The arguments why you would use GraphQL nowadays, they have changed quite a bit. So it was interesting to see the transition throughout the years. And I think within this panel talk, we'll talk a little bit about what actually happened and what were actually the adoption of ways of GraphQL. Awesome.

3. Evolution of GraphQL and Interchange Formats

Short description:

GraphQL is a natural next step in the convergence of the RPC data interchange format landscape. Traditional interchange formats lacked standardization and reusability, while more performant formats were not approachable for average developers. GraphQL merged these streams, providing a consistent, semantically constrained, and reusable schema system that is human-readable and performant.

All right. Well, let's dive right in with some questions that we've already assessed from the community. So looking at our first question, I think, Evan, this is going to do really well with your experience, but it is when looking at the evaluation of GraphQL or evolution, or evaluation, my apologies, evolution of GraphQL, how did it become the perfect contract con tap layer between backend and frontend and the data API to use? So I think to me, GraphQL is a natural next step in kind of a convergence of what's happened in like the RPC data interchange format landscape over the last five years or so.

If you remember way back in the day, which hopefully you don't, you know, like it's 1982 and you're trying to query Oracle for the first time. Like basically what you put on the wire is a dump of what Oracle has in memory. If you're the client, then you have to figure out how to serialize things. So it pleases the esteemed database server and if it doesn't please the esteemed server, then you don't get a query. And like that is not a reusable interchange format. Like there's nothing standardized or general purpose or even abstract in any way about the way you talk to the traditional RDBMS. And that goes for Postgres and MySQL too.

And kind of in response to those interchange formats, we started to get a series of things which were more general. One of the first being Corba in the early 90s. And it was still binary. Didn't really have any concept of the semantics of the data it was exchanging but types were well-defined. Like the big-endian, little-endian problem was solved, which used to be a whole thing which blissfully we don't have to care about anymore. It was OS-independent and so on. And that kind of evolved with the rise of the web into XMLRPC which was human-readable but not much more. And then we had this bifurcation where XMLRPC was slow but webby, so to make it more usable, more intuitive, more approachable and truly like something a developer could use without having to read the docs, you know, REST sort of evolved from that and REST said, you know, we're going to constrain the semantics of what APIs can do to a standard set which is already supported by HTTP and that will allow us to, you know, speak APIs in a common language and a common way. And effectively, JSON became the type system for REST.

At the same time, you had other, you know, on the other side of the fence, so to speak, and you had GRPC, AVRO, Thrift, like these binary, more performance-oriented interchange formats, RPC frameworks, you know, sets of servers and clients which were compatible and reusable. You know, they had schema discovery and that kind of thing. So, they were very performant for general purpose, you know, SOA architecture, but they weren't approachable and consumable by the average developer. They weren't human readable. They weren't, you know, legible without looking at the docs and digging into the schema registry and that kind of thing. And what GraphQL really did is merge these two streams, you know, the consistent, semantically constrained, reusable thing with the general purpose high performance abstract thing back together. And now we have a schema system. You can discover the schema. You can discover the verbs of your endpoint, but the types are constrained. So it's human readable. JSON is now performant for machines to parse and omit.

4. GraphQL and Architecture Techniques

Short description:

GraphQL has come up with a really easy format to use in between those teams backend and front end team. The schema definition language (STL) serves as the contract, allowing development to happen in parallel. The ease of use of GraphQL is significant, and the query language provides information about the consumer's intent. It can lead to sending less data over the network and enable smarter scheme evolution. Techniques to get the most out of GraphQL and architecture include Content Federation.

And it's kind of the first time we've gotten the best of all worlds in terms of a standardized API format. So I think from our perspective, you know, almost all data interchange with machines that isn't hyper-specialized is going to move to GraphQL. And I think that's a good thing.

Yeah, I think I would like to add to that. So you mentioned, uh, I completely agree on this and you mentioned already throughout the years, uh, what, what became important in sort of an interchange format is the type system is really, uh, the, the, the easy reasoning, the, the, the simple reasoning of what kind of data you can actually expect or how you would describe actually the data that you would store or interchange. And I think GraphQL has come up with a really easy format to use in between those teams backend and front end team. There's this centerpiece in GraphQL, which is the STL, the schema definition language that to me is really the contract. And it is sort of an abstraction or an agreement between the two teams and, uh, ideas and, uh, around API, what you would like to implement. You need a certain function, a certain functionality. You define on this STL and you have a type system and from now on, uh, you can branch out and development can happen actually in parallel. So the backend behind it can actually be implemented. But also the front end teams already know what kind of data to expect from the backend once it's there. So it's, it's not only the technical aspects, but I think what's really exciting about GraphQL also the organizational aspects that, um, that just allow teams to work better in an independent way.

Yeah, I love that. I love the idea of a schema as a contract. That's a really nice way to look at it. Um, cause marketing, I know for a fact developers always have kind of a divide between them sometimes when it comes to these tools and technologies, um, I had a question. Okay. No, I just wanted to say, I agree with all of that. I, I also think, you know, I'm also came from the web services world and with Dole, and like we used to have, like, we used to have like a, you know, contract based APIs before I think, but I mean, you know, the ease of use of GraphQL I think is, is, is significant. I think something that for me is also, um, uh, very interesting is the query language, right? So basically that, um, now the consumer, like the provider can have some information about what the consumer actually, the intent of the consumer. And I think that could actually lead to a lot of profound things around APIs in general. I think, um, you know, currently we're using it like the main use case that people are talking about is like sending less data over the network. Um, but I think, you know, it could actually lead to a another, like aspect of GraphQL which is like scheme evolution in a smarter way. And I think, um, that's a very interesting, uh, property that, uh, I think would for, for like third party APIs could be very profound, this information could be very valuable. Thanks. Nice. Um, all right. Well, talking of scale and production, um, I think this question fits in nicely. What are some of the techniques you've seen companies use to get the most out of GraphQL and their architecture? Um, let's kick it off maybe with Michael, maybe Content Federation.

5. GraphQL Adoption and API Composition

Short description:

In the last year, the idea of GraphQL in the enterprise has become more dominant. Companies are now building GraphQL APIs around multiple microservices, allowing for exciting composition of APIs. Merging APIs together creates a new universal API, simplifying the developer experience. This trend, known as Federation, is being pushed forward by Apollo and other tooling providers like Casura and the Guild. Customers are excited about the concept of Federation and see it as a solution to headaches in previous projects. The adoption of GraphQL is moving from microservices to macro services, creating a composition of larger services.

Yeah. Yeah. Um, it's, it's, it was interesting to observe throughout the year. So the typical arguments for GraphQL in the early days, it was the, uh, like preventing the over-fetching and under-fetching, giving more, uh, giving more power to the API consumer to the client to be more flexible on this. Um, then later it evolved it more and more type generation around GraphQL became important. And I'm pretty sure Uri can talk a lot about this and it will be exciting to talk about this also to touch about the developer experience aspect of type generation, et cetera. But in the last year, uh, it is really interesting to observe in the whole GraphQL space that the idea, uh, of, of GraphQL or the how GraphQL sits in the stack of, uh, let's say an enterprise, uh, has become, became more dominant. It's bigger. So, uh, earlier we would observe that companies would build GraphQL APIs around single services, like encapsulate only one microservice, but then, uh, more and more we see now as those microservices are there in those GraphQL APIs are, are there for those single microservices composition. The composition aspect of APIs becomes very exciting also. So, uh, let's say you have a couple of API APIs that don't speak with each other, but all of them give you a certain subset of data. Let's say, let's say you have a CMS API to fetch content, but let's also say you have a product information management system in your stack or a digital asset management system that is delivering, delivering you also data either via REST API or GraphQL API. When it gets exciting in terms of developer experience and, and, and, and the ease of use of an API is when you merge those APIs together, you compose them together and you get one new universal API out of it. So developers then consuming all of those services, they only need to speak one language and speak to one API. This is a trend. I'm not sure if, if Apollo actually coined the term Federation, or if it's a term from the GraphQL space itself, but definitely Apollo was pushing this trend forward. And then then also other tooling providers like Casura or like the Guild actually recently doing a lot of development around this with GraphQL Mesh. This is something that we observe recently in the ecosystem that excites customers and a lot when we speak about how to orchestrate and combine those APIs, they really get excited, like conversations change really. And and you would always hear, yes, if I would have known about this concept of Federation or how to compose APIs in my last project, that would have saved me a lot of headache. So we see an adoption from microservices to we call them internally macro services. I'm not sure if this is actually the right terminology for this, or if it means something different, but I like the term growing, going from small single services to a composition of a pool of something bigger.

6. GraphQL's Flexibility and Tool Choice

Short description:

GraphQL's use is expanding beyond the security perimeter, allowing for greater flexibility in service location and integration. It decouples clients and enables the use of serverless and third-party services. This opens up opportunities to choose the best tools for your use case, independent of cloud providers or security frameworks.

At Fauna, I think, go ahead. At Fauna, I think one of the trends we see and hope continues is it's adjacent to the federation you're talking about. Originally, GraphQL was something that lived at your security perimeter. You have all of the backend crap in the firewall in the cloud account. It talks to each other in its own way with its own security policy and it presents a GraphQL interface to the consumer, like whoever's building the mobile app or the developer using your API, that kind of thing. But now we're seeing, and Fauna is certainly part of this trend, now we're seeing its use internal to the infrastructure. It's a good general purpose format, partly because of the constant negotiation of the representation it decouples clients, which can all be within the security perimeter or not. And the more the security model for GraphQL on the web evolves in the future too, the less it will matter where these services live, you'll be able to use more serverless services, more third parties integrated together seamlessly in a way that right now is kind of hard to do unless you're locked into like a single hyperscale cloud vendor's personal world. So one of the things we're most excited about is that not only does it make infrastructure services easier to consume and easier to understand and easier to integrate, but it lets you choose best of breed tools for your use case, regardless of your existing commitment to a specific cloud or to a specific vendor or specific security framework and that kind of thing.

7. Merging and Unifying APIs

Short description:

There's a lot of investment in the GraphQL space, enabling the combination and merging of APIs. Vendors are providing a set of predefined API connectors, allowing developers to select and interchange them. APIs can be combined into a central service or registered in a service registry and compiled into an SDK. This infrastructure allows the benefits of merging APIs without going through a central place. The vision of a decentralized system, similar to the semantic web, is an amazing idea, where information on querying and communication remains distributed. The merging of APIs on the client side has limited use cases due to the need for back-end management of authentication and authorization.

Yeah, absolutely. And I think there's, we can observe a lot of investments in the whole GraphQL space going that direction, enabling those use cases to combine and merge APIs like just recently Netlify I made an acquisition. They acquired OneGraph, which I found very interesting as a tool. And so they're following, they're evolving to the vision also now to merge those or to give an easy to use marketplace for APIs, for JAMstack APIs, getting them together. And I think that's a very interesting value proposition. I think that is something that we will observe more in the future.

Actually having vendors that provide a big set of predefined API connectors, you could just select some of them and define eventually business logic on how they actually interchange and then you get a generated API out of it, being able consuming all of those services. Yeah. I'm also very excited about merging multiple APIs. But I think sometimes if we go into the details on these things, first of all, merging multiple APIs doesn't mean that you actually have to merge them all into one central place and then rely on that one central point of... Like, what are you merging basically? Let's say if you have, let's say, a lot of different services on the network, you could basically combine them all into one central service. And then everyone who wants to consume these services will go through that, let's say, central gateway or central point. And on the other hand, you could just register all those different services in a, let's say, service registry or something like that. And then you could basically merge them and then, let's say, compile it into an SDK. Now that SDK could run locally on the consumer. That consumer, like Evan says, it could be a client outside of your network, but it could be a service internally inside your network. And that service would, basically, that SDK would make you feel as the developer, as if you're querying this one giant graph and this one central place. But at the end of the day, it could run locally on the consumer. And the requests will actually grow directly into the services that you're trying to query. So that's like an infrastructure that I'm really excited about, like that we could get some of the benefits of this merging of multiple APIs. But then it doesn't have to actually go through a central place.

I think there's like this vision that I don't know, there was this semantic web, many, many years ago, that people were talking about and this is like, I think it's a very amazing, it is an amazing idea. I think if we're looking at either one day one company will maybe be able to establish something like that, I think in my opinion, in my vision, it has to be decentralized. It has to not go through one central place that everyone is going to query through that place and then call all the rest of the world. It would have to be something a bit more, well, maybe there's one place you take that information of where can I query and what could I query? But then, you know, the communication itself would stay distributed. Yeah, I don't know. Right, right. But it's an interesting idea to do the merging or the unification of the APIs on the client side, basically on the SDK side, though I would assume that the use cases are a bit limited, because if you want to mesh multiple services together, there has to be also like the rules of how authentication and authorization between those services are managed. That has to happen on the back end or at least not on the client side. I mean, that would be insecure.

8. Challenges in Federation and Benefits of GraphQL

Short description:

Authentication and authorization are significant challenges in GraphQL federation. If the underlying infrastructure doesn't align with the authorization and identification semantics, it can lead to breaches and maintenance issues. Performance management is another concern, but GraphQL's web security model allows clients to bypass performance limitations. Fauna, for example, enables routing to the nearest data center for improved performance. Adding GraphQL to Fauna has been beneficial, providing an approachable interface for operational data and avoiding constraints of other tools like SQL or existing APIs.

So I could see like both trends evolving, especially as there is a lot of public APIs where it's fine to just get data from, and in that sense, it's a perfect valid use case. Yeah, or maybe like, let's say you could somehow handle, you know, each service handles their own, let's say, authentication or authorization. It's an interesting topic.

Just to add to this, I think not necessarily those services can take care of authentication, authorization, but if you do also cross joins of data, you want to join data across multiple systems. The authorization logic that needs to understand the joining also needs to happen somewhere in front. I think this is one of the very big challenges actually in federation, how to do authentication. Authentication is probably the easier part. Authorization is really hard because you have to do this basically on your GraphQL layer that federates everything together. That's a challenge for existing middleware that tries to layer GraphQL on top of Postgres for example. That's one of the reasons Fauna is a NoSQL database with our own query language, which essentially extends GraphQL for mutation purposes. If your underlying infrastructure doesn't share the same authorization and identification semantics as the tools farther up the chain, then you end up with potential breaches and a lot more developer headache and maintenance just to get your basic queries running. And I think performance management is in a similar place with GraphQL right now. Like you can federate a whole bunch of APIs, but if you're trying to do this massive merge query of different vendors and one of them is slow, like what do you do? And one of the benefits of infrastructure services offering GraphQL instead of more like long lived connection oriented interfaces and proprietary interchange formats is that the web security model allows clients to do a run around some of those performance considerations when they're in the way. So you can have your federated layer, can query, cool stuff, do cross joins, whatever you want there. But if some query is more performance-sensitive for the user experience, you can hit that service directly from the client, wherever the client is, and then you can, especially at least with Fauna, you can get routed to the local, the nearest data center for the region group that that database is in. You don't have to like backhaul back to US East One, which is probably down because you know...

I would have actually one follow-up question to you, Evan, in regards to Fauna. I've been playing around with Fauna earlier. It's an amazing tool, really. Back then, there was only FQL, basically the Fauna query language. Later on, you added GraphQL to the mix also. Did you see a change? Did the adoption of the tool benefit for adding the GraphQL layer to it? Yeah, absolutely it did. In infrastructure, it's important to have an approachable interface for whatever that means. That could be SQL, but then you're constrained by whatever SQL can do. SQL was designed for business reporting, and extending it beyond that is challenging. So, we believe it's not the ideal interface for operational data. It's great for analytics, OLAP, that kind of thing. You could also do something like copy an existing popular API, like Mongo, or something, and try to take advantage of that client ecosystem. But then again, you're constrained by the existing capability of that tool. You're constrained by that vendor's ability to evolve the spec against your wishes, which is a real problem that AWS has with DocumentDB, for example.

9. GraphQL's Potential and Extensibility

Short description:

GraphQL can help provide a more general purpose interface and API that can be extended to support the specialized value of your tool. It overcomes the limitations of REST in expressing transactions and schemas. There is potential for collaboration and a more elaborate version of GraphQL that incorporates storage and shares semantics. Extending GraphQL to support mutations and transactions is possible, but it will likely evolve from the community rather than a committee-driven standard.

Or, you can pick a more general purpose interface and API that can be extended to support the proprietary and specialized value of your tool. And that's what GraphQL can help you. And REST was too impoverished from a semantic perspective to do this well. There were only so many verbs. If you build a relational REST database, it just doesn't make sense because you're dealing with one object at a time. There's no coherent way to express a transaction or that kind of thing. There's no schema. There's only the URI hierarchy, for example.

But at the same time, if you expose an API in Thrift, yeah, people can get drivers to connect over TCP IP and do Thrift stuff. But there's nothing shared or comprehensible or human readable about the semantics. So for us, GraphQL was the perfect kind of initial on-ramp to the Fauna experience. We're working long-term to essentially marry GraphQL and FQL together as tightly as possible so that it's not discontinuous when you have to switch from GraphQL land into this specialized, extended land.

That makes complete sense to me. Thanks, Evan. Do you think, by the way, do you think there's a place for, I know it's just a random idea, but there's a working group in GraphQL, a sub-working group around GraphQL over HTTP. Do you think there is a place for, let's say, storage? I don't know how to say it, but let's say all kinds of people are building actually GraphQL over databases or things like that to collaborate on, let's say, a more elaborate version of GraphQL where you share some semantics with how you query certain things. I don't know. Do you think it's something that is possible or it's like those different solutions are too different?

So GraphQL doesn't have a mutation language. It gives you schema. It gives you selection. It gives you resolver endpoints which are defined elsewhere. What happens in the elsewhere is completely unconstrained right now, for better or worse. You see systems that basically shove a bunch of SQL into the resolver endpoint. It has very little to do with what's presented in the GraphQL interface itself and so on. Can we extend GraphQL as a language to support mutations and transactions generally in a seamless way? Yes, we can. I don't think it's going to evolve as a committee-driven standard. I mean, I'm on the GraphQL foundation board as well and I don't think it's the right thing for GraphQL as an oversight group to mandate. I think it's the kind of thing which will evolve from the community and we'll start to see patterns emerge and vendors like ourselves will offer innovations and ways to conform with the existing GraphQL semantics and still do more sophisticated data logic and even compute logic as well and others will adopt those and potentially at some point that can be standardized or at least partially standardized which is more reflective of how CGo evolved originally too you know we had system R and then we had Oracle's implementation of that which essentially set the first standard.

Oh thanks a lot Evan. I think looking at the time Alex, do we have more questions lined up? We don't have too much time left but I have kind of a sweeping question for all of you that I'm very interested to ask.

10. Predictions for the Future of GraphQL

Short description:

The future of GraphQL holds exciting new features and interoperability with other API specs. Adoption of GraphQL is expanding beyond engineering, with potential use cases in data analysis and marketing. The security model and the ability to mix and match infrastructure and services are areas of interest. The panelists express gratitude for the discussion and encourage follow-up questions.

I was just really curious about with your time with GraphQL, what are your predictions for the future? Either because of GraphQL or clients or you know anything? Ulpi you want to start on this? Sorry what's the question again? It took up for me just when you asked. Sorry the choice of doing this over zoom. What are your predictions for the future for GraphQL? How will it change things? How how will it evolve? I know very general like you know, very vague question but. It's the philosophical questions now. Dig deep.

I think some things that I don't know I can so some things that I care about or I hope will happen is I think there's a lot of new features coming. They're coming slow and it's a good thing but they're coming like defer and stream, live queries, one-off directives, client-side malleability, like there's a lot of new spec changes that I think are very exciting. They're already being used in let's say inside Facebook for example and I think they will be valuable for many others. One thing that we did recently is that we gave options for people to use these features outside of the spec as well and I think that might encourage more people to try these features out and then give feedback and that will actually make their working group and just adopt these things faster. A bit like what Evan said, that there will be some people push the envelope forward and then others, the standards will follow. And I think also, so that's something that I care about and I think it will be easier. I see also in our case, we see more and more of that interoperability with other API specs. So in our case, we're talking about GraphQL Mesh where it's a tool where we could take any basically source like OpenAPI, Swagger, gRPC. So and then basically convert that automatically into GraphQL and let you query these things. And first of all, I think it will help a lot of adoption because I think it makes it easier to just start with GraphQL over whatever you have already. And the second thing that we're seeing is that by interrupting with those, all these different protocols, we actually find really cool features in these other protocols that we want to then bring into the GraphQL spec. So yeah, those are just a couple of things that I'm excited about.

Evan, what would be your prediction? I mean, I think, you know, we see lots of refinement and evolution of the small features, extending for common web use cases. The things I'm excited about are, you know, more long-term, like can GraphQL be useful outside of the typical, be more useful outside the typical, you know, frontend application querying and API context? Like, can we get the security model standardized in an interoperable, general-purpose way across vendors and the entire ecosystem? You know, can— like, you know, REST provided implementation patterns and made things comprehensible for an individual developer. But it didn't give you that, like, so to speak, like rich tapestry of services you would consume, like we were promised in the Symantec web days or the XML RPC days, like, you know, the dream that, you know, you'd have one cent to get a stock quote and you'd go find the best service on the fly to get that quote and it would come back in a common format. Like, people aren't really going to do that, but what they are going to do is be able to mix and match very aggressively more sophisticated and special-purpose and innovative infrastructure and API and business services than they were able to before. And I have just a quick addition to this question. It was given to us by the audience. But if you could expand also on any use cases you wish Gracuel could expand on in the future. So just putting that out there for the last few minutes, if anyone has any ideas.

Michael, please go ahead. Yeah, I think I can take this. So also what I wanted to say in terms of the predictions as I see, I think we will see more adoption of GraphQL outside of the engineering space even. To me, GraphQL is a simplified or can be a simplified SQL that enforces some rules. And therefore, it's also very useful query language for data outside of the engineering application development. I'm thinking of data analysts eventually or marketing team that need to get information, very complex data graphs, information on eventually marketing data. So to me, I think we'll see adoption of GraphQL outside of engineering. Yes. Alright. Well, I think that is the perfect place to stop this discussion. Thank you guys so, so much for being such good sports and answering these questions and giving such wonderful, valuable insights. And yeah, if you have any follow-up questions, please put them in discord and our panelists will get to them soon. So thank you guys so much. Okay.

QnA

Adoption and Evolution of GraphQL

Short description:

Exploration of early adoption and evolution of GraphQL, highlighting its significance as a contract layer between backend and front end data APIs as discussed within the panel.

And my first touch points with GraphQL actually were quite early, so soon after the first spec got released, I think it was end of 2015. It was very niche back then, but it was all the buzz on some medium on some Reddit. I was consuming all this stuff and found it very interesting because back then I find there was a lot of pain points when working with REST API. So I found this technology, GraphQL, I found very interesting. And soon later, actually, we had the idea to build the first GraphQL enabled headless content management platform, which has now become GraphCMS. So we've been adopters from the first day and it is very exciting to observe also throughout the years how GraphQL has changed over the years and the arguments why you would use GraphQL nowadays, they have changed quite a bit. So it was interesting to see the transition throughout the years. And I think within this panel talk, we'll talk a little bit about what actually happened and what were actually the adoption waves of GraphQL. Awesome.

All right, well, let's dive right in with some questions that we've already assessed from the community. So looking at our first question, I think Evan, this is going to do really well with your experience. But it is when looking at the evaluation of GraphQL or evolution or evaluation, my apologies, evolution of GraphQL, how did it become the perfect contract layer between backend and front end and the data API to use? So I think to me, GraphQL is a natural next step and kind of a convergence of what's happened in the RPC data interchange format landscape over the last five years or so. If you remember way back in the day, which hopefully you don't, you know, like it's 1982 and you're trying to query Oracle for the first time, like basically what you put on the wire is a dump of what Oracle has in memory. And, you know, if you're the client, then you have to figure out how to serialize things so it pleases the esteemed database server. And if it doesn't please the esteemed server, then you don't get a query. And like that is not a reusable interchange format, like there's nothing standardized or general purpose or even abstract in any way about the way you talk to the traditional RDBMS. And that goes for Postgres and MySQL too. And kind of in response to those interchange formats, we started to get a series of things which were more general.

Evolution of Data Interchange Formats

Short description:

Exploration of the evolution from binary interchange formats to GraphQL, highlighting the merging of semantically constrained and high-performance aspects in API development.

One of the first being Korba in the early nineties. And it was still binary. It didn't really have any concept of the semantics of the data it was exchanging, but types were well-defined. Like the big Indian, little Indian problem was solved, which used to be a whole thing which blissfully we don't have to care about anymore. You know, it was OS independent and so on.

And that kind of evolved with the rise of the web into XMLRPC, which was human readable, but not much more. And then we had this bifurcation where, you know, XMLRPC was slow, but webby. So, you know, to make it more usable, more intuitive, more approachable and truly like something a developer could use without having to read the docs, REST sort of evolved from that and REST said, you know, we're gonna constrain the semantics of what APIs can do to a standard set, which is already supported by HTTP.

And what GraphQL really did is merge these two streams the consistent semantically constrained reusable thing with the general purpose high performance abstract thing back together. And now we have a schema system. You can discover the schema, you can discover the verbs of your end point but the types are constrained. It's human readable. JSON is now performant for machines to parse and emit. And it's kind of the first time we've gotten the best of all worlds in terms of a standardized API format.

Organizational and Technical Advantages of GraphQL

Short description:

Merging of semantically constrained and high-performance aspects in API development through GraphQL. GraphQL's Schema Definition Language facilitates agreement between backend and frontend teams, enhancing parallel development. The organizational benefits of GraphQL promote independent team work and streamline data interchange processes.

They weren't, you know, legible without looking at the docs and digging into the schema registry and that kind of thing. And what GraphQL really did is merge these two streams the consistent semantically constrained reusable thing with the general purpose high performance abstract thing back together. And now we have a schema system. You can discover the schema, you can discover the verbs of your end point but the types are constrained. It's human readable. JSON is now performant for machines to parse and emit. And it's kind of the first time we've gotten the best of all worlds in terms of a standardized API format.

So I think from our perspective, you know, almost all data interchange with machines that isn't hyper-specialized is going to move to GraphQL. And I think that's a good thing. Yeah, I think I would like to add to that. So you mentioned, I completely agree on this and you mentioned already throughout the years what became important in sort of an interchange format is the type system is really the easy reasoning, the simple reasoning of what kind of data you can actually expect or how you would describe actually the data that you would store or interchange. And I think GraphQL has come up with a really easy format to use in between those teams, backend and frontend team, there's this centerpiece in GraphQL, which is the STL, the schema definition language that to me is really the contract. And it is sort of an abstraction or an agreement between the two teams and ideas and around API, what you would like to implement, you need a certain function, a certain functionality, you define on this STL and you have a type system. And from now on you can branch out and development can happen actually in parallel.

So the backend behind it can actually be implemented, but also the frontend teams already know what kind of data to expect from the backend once it's there. So it's not only the technical aspects, but I think what's really exciting about GraphQL is also the organizational aspects that just allow teams to work better in an independent way. Yeah, I love that. I love the idea of a schema as a contract. That's a really nice way to look at it because marketing, I know, for a fact, developers always have kind of a divide between them sometimes when it comes to these tools and technologies. I have a question. Okay. I just wanted to say I agree with all that. And I also think, you know, I'm also came from like the web services world and we still and like we used to have like, we used to have like, you know, contract based APIs before, I think. But I mean, you know, the ease of use of GraphQL, I think is significant. I think something that for me is also a very interesting is the query language, right? Like the fact basically that now the consumer, like the provider can have some information about what the consumer actually the intent of the consumer. And I think that could actually lead to a lot of profound things around API's in general. I think, you know, currently we're using it like the main use case that people are talking about is like sending less data over the network. But I think, you know, it could actually lead to another like aspect of GraphQL which is like schema evolution in a smarter way. And I think that's a very interesting property that, you know, I think for like third-party API's could be very profound and this information could be very valuable. Nice.

Optimizing GraphQL for Enhanced API Composition

Short description:

Techniques for maximizing GraphQL benefits in architecture include Content Federation and type generation advancements. The shift towards composing APIs from individual micro-services to a universal API enhances developer experience and simplifies communication. Apollo and other tooling providers are driving the trend of API composition, leading to excitement and efficiency in orchestrating multiple APIs.

All right. Well, talking of scale and production, I think this question fits in nicely. What are some of the techniques you've seen companies use to get the most out of GraphQL in their architecture? Let's kick it off maybe with Michael. Maybe Content Federation. Yeah, yeah. It was interesting to observe throughout the year. So the typical arguments for GraphQL in the early days, it was the like preventing the over fetching and under fetching, giving more power to the API consumer, to the client, to be more flexible on this. Then later it evolved that more and more type generation around GraphQL became important. And I'm pretty sure Uri can talk a lot about this and it will be exciting to talk about this. Also to touch about the developer experience aspect of type generation, et cetera.

But in the last years, it is really interesting to observe in the whole GraphQL space that the idea of GraphQL or how GraphQL sits in the stack of let's say an enterprise has become more dominant. It's bigger. So earlier we would observe that companies would build GraphQL APIs around single services like encapsulate only one micro-service but then more and more we see now as those micro-services are there and those GraphQL APIs are there for those single micro-services composition, the composition aspect of APIs becomes very exciting. Also, so let's say you have a couple of APIs that don't speak with each other but all of them give you a certain subset of data. Let's say you have a CMS API to fetch content but let's also say you have a product information management system in your stack or a digital asset management system that is delivering you also data either via REST API or GraphQL API.

When it gets exciting in terms of developer experience and the ease of use of an API is when you merge those APIs together, you compose them together and you get one new universal API out of it. So developers then consuming all of those services, they only need to speak one language and speak to one API. This is a trend. I'm not sure if Apollo actually coined the term federation or if it's a term from the GraphQL space itself. But definitely Apollo was pushing this trend forward. And then also other tooling providers like Kasura or like the Guild actually recently doing a lot of development around this with GraphQL Mesh. This is something that we observe recently in the ecosystem that excites customers and prospects a lot. When we speak about how to orchestrate and combine those APIs, they really get excited. Conversations change really. And you would always hear, yes, if I would have known about this concept of federation or how to compose APIs in my last project that would have saved me a lot of headache. So we see adoption from microservices to we call them internally macro services. I'm not sure if this is actually the right terminology for this or if it means something different. But I like the term going from small single services to a composition of a pool of something bigger. At Fauna, I think... Go ahead.

Expanding GraphQL for Seamless API Integration

Short description:

GraphQL evolution towards internal infrastructure use within security perimeters and broader service integration. Emphasis on infrastructure simplicity, flexibility, and tool selection independence. Investment trends in GraphQL space towards merging APIs and creating a marketplace for interconnected JAMstack APIs.

At Fauna, I think one of the trends we see in Hope, Hope Continues is it's adjacent to the federation you're talking about. Originally, GraphQL was something that lived at your security perimeter. Like, you have all the back-end crap in the firewall, in the cloud account. It talks to each other in its own way with its own security policy and it presents a GraphQL interface to the consumer, like whoever's building the mobile app or the developer using your API, that kind of thing. But now we're seeing... And Fauna is certainly part of this trend. Now we're seeing its use internal to the infrastructure. It's a good general purpose format, partly because of the constant negotiation of the representation at the couples, clients, which can all be within the security perimeter or not. And the more the security model for GraphQL on the web evolves in the future too, the less it will matter where these services live. You'll be able to use more serverless services, more third parties integrated together seamlessly in a way that right now is kind of hard to do unless you're locked into a single hyperscale cloud vendors, personal world. So one of the things we're most excited about is not only does it make infrastructure services easier to consume and easier to understand and easier to integrate, but it lets you choose best of breed tools for your use case, regardless of your existing commitment to a specific cloud or to a specific vendor or specific security framework and that kind of thing.

Yeah, absolutely. And I think there's a we can observe a lot of investments and the whole GraphQL space going in that direction, enabling those use cases to combine and merge APIs. Just recently, Netlify made an acquisition. They acquired OneGraph, which I found very interesting as a tool. And so they're following their evolving to the vision also now to merge those or to give an easy to use marketplace for APIs for JAMstack APIs, getting them together. And I think that's a very interesting value proposition. I think that is something that we will observe more in the future. Actually having vendors that provide a big set of predefined API connectors. You could just select some of them and define eventually business logic on how they actually interchange data. And then you get a generated API out of it being able consuming all of those services. Yeah. I think, you know, I'm also, I'm very excited about like, you know, merging multiple APIs. But I think sometimes if we go into the details on these things, like there's more, first of all, merging multiple APIs doesn't mean that you actually have to merge them all into one central place and then rely on that one central point of... Like what are you merging, basically like, let's say if you have, let's say a lot of, you know, different services on the network, you could basically combine them all into one central service and then everyone who wants to consume these services will go through that, let's say central gateway or central point. On the other hand, like, you could just register all those different services in a, let's say a service registry or something like that. And then you could basically merge them and then let's say, compile that into an SDK. Now that SDK could run locally on the consumer, that consumer, like Evan says, like it could be a client outside of your network, but they could be a service internally inside your network. And that service would, you know, basically that SDK would make you feel as the developer as if you're acquiring this one giant graph and this one central place, but at the end of the day, it could run locally on your, on the consumer and their requests will actually go directly into the services that you're trying to query. So that's like an infrastructure that I'm really excited about, like that we could get some of the benefits of this, like merging of multiple APIs.

Decentralized Data Communication Challenges

Short description:

Discussion on decentralization of data communication, challenges in authentication, and authorization in federated environments, and the significance of matching authorization semantics for secure data interchange.

But then it doesn't have to actually go through a central place. I think, you know, there's like this vision that I don't know, there was the semantic web, you know, many, many years ago, that people were talking about and this is like, I don't know. I think it's a very, it is an amazing idea. I think, you know, if we're looking at, I don't know, one day one company will maybe be able to establish something like that. I think in my opinion, in my vision, it has to be decentralized, like it has to not go through one central place that everyone is going to query through that place and then call all the rest of the world. It would have to be something a bit more, well, maybe there's one place you take that information of where can I query and what could I query, but then, you know, the communication itself would stay distributed. Yeah, I don't know.

Right, right. But, it's an interesting idea to do the merging or the unification of the APIs on the client side. Basically on the SDK side, though I would assume that the use cases are a bit limited because if you want to mesh multiple services together, there has to be also like the rules of how authentication and authorization between those services are managed. That has to happen on the back end or at least not on the client side. I mean, that would be insecure. So I could see both trends evolving, especially as there is a lot of public APIs where it's fine to just get data from and in that sense, it's perfect valid use case. Yeah, or maybe like let's say you could somehow handle each service handles their own, Let's say authentication or authorization or yeah, I mean. Yeah, I mean, it's an interesting topic.

Just to add to this, I think not necessarily those services can take care of authentication authorization, but if you do also cross joins of data, you want to join data across multiple system, the authorization logic that needs to understand the joining also needs to happen somewhere in front. I think this is one of the very big challenges, actually, in federation, how to do authentic. Authentication is probably the easy, easier part. Authorization is really hard because you have to do this basically on your GraphQL layer that federates everything together. That's a that's a challenge for existing middleware that tries to like layer GraphQL on top of Postgres, for example, and that's one of the it's one of the reasons Fauna is a no-seagull database with our own query language, which essentially extends GraphQL for mutation purposes. Like if your underlying infrastructure doesn't share the same authorization and identification semantics as you know, the tools farther up the chain, then you end up with potential breaches and a lot more developer headache and maintenance just to get your basic queries running. And I think performance management is in a similar place with GraphQL right now, like you can federate a whole bunch of APIs. But if you're trying to do this massive merge query of different vendors and one of them is slow, like, what do you do? And one of the benefits of infrastructure services offering GraphQL instead of more like long live connection oriented interfaces and proprietary interchange formats is that you know, the web security model allows clients to do an end run around some of those performance considerations when they're, when they're in the way. So you can have your federated layer can query cool stuff, do cross joins, whatever you want there. But you know, if some query is more performance sensitive for the user experience, you can hit that service directly from the client and wherever their client is. And then you can, especially at least with Fauna, you can get routed to the local, the nearest data center for the region group that that database is in. You don't have to like backhaul back to US East one, which is probably down because you know...

Significance of GraphQL Integration with Fauna

Short description:

Exploration of the benefits of adding a GraphQL layer to Fauna, emphasizing the importance of an approachable interface and the limitations of SQL and REST in handling operational data effectively.

I would have actually one follow up question to you, Evan, in regards to Fauna is I've been I've been playing around with Fauna earlier. And it's an amazing tool, really. Back then, there was only FQL. Basically the Fauna query language. Later on, right. You added GraphQL to the mix also. Did you see a change like the adoption of the tool that did it benefit for adding the GraphQL layer to it? Yeah, absolutely. It did. It's important in infrastructure. It's important to have an approachable interface for whatever that means. So like that could be SQL, but then you're constrained by whatever SQL can do. SQL was designed for business reporting and extending it beyond that is challenging. So we believe it's not the ideal interface for operational data. It's great for analytics, OLAP, that kind of thing. You could also do something like copy an existing popular API like Mongo or something and try to take advantage of that client ecosystem. But then again, you're constrained by the existing capability of that tool. You're constrained by that vendor's ability to evolve the spec against your wishes, which is a real problem that AWS has with DocumentDB, for example. Or, you know, you can pick a more general purpose interface and API that can be extended to support the proprietary and specialized value of your tool. And that's what GraphQL can help you. REST was too impoverished from a semantic perspective to do this well. There are only so many verbs. Like if you build a... Like you can't build a relational REST database. It just doesn't make sense because you're dealing with one object at a time. There's no coherent way to express a transaction or that kind of thing. There's no schema. There's only the URI hierarchy, for example. But at the same time, like, you know, if you expose an API in Thrift, yeah, people can get drivers to connect over TCPIP and do Thrift stuff, but there's nothing shared or comprehensible or human readable about the semantics. So for us, GraphQL was the perfect kind of, you know, an initial on-ramp to the Fauna experience. And we're working long term to essentially marry GraphQL and FQL together as tightly as possible so that it's not discontinuous when you have to switch from like GraphQL land into this specialized, extended land.

Potential Evolution of GraphQL Mutation Support

Short description:

Exploring the possibility of extending GraphQL to support mutations and transactions seamlessly without a committee-driven standardization.

That makes complete sense to me. Thanks, Evan. Do you think, by the way, do you think there is a place for, I know, it's just a random idea, but like for, there's like, let's say, a working group in GraphQL, a sub-working group around like GraphQL over HTTP. Do you think there is like a place for, let's say, storage? I don't know how to say it, but like, let's say, all kinds of people are building actually GraphQL over databases or things like that to collaborate on let's say a more elaborate version of GraphQL where, you know, you share some semantics with how you query certain things and yeah, like, I mean, I'm just, yeah, I don't know. Do you think it's something that is possible or it's like those different solutions are too different?

So, yeah, GraphQL doesn't have a mutation language. Like it gives you schema, gives you selection, it gives you resolver endpoints, which are defined elsewhere. Like what happens in the elsewhere is completely unconstrained right now for better or worse and you see systems that basically shove a bunch of seagull into the resolver endpoint. Like it has very little to do with what's presented in the GraphQL interface itself and so on. You know, can we extend GraphQL as a language to support mutations and transactions generally in a seamless way? Yes, we can. I don't think it's going to evolve like as a committee-driven standard.

Evolution and Future Predictions of GraphQL

Short description:

Evolving community-driven evolution of GraphQL, including innovations leading to standard adoption, and exploring broader usefulness outside typical contexts.

I mean, I'm on the GraphQL Foundation Board as well, and I don't think it's the right thing for the GraphQL as an oversight group to mandate. I think it's the kind of thing which will evolve from the community, and we'll start to see patterns emerge. Vendors like ourselves will offer innovations to conform with existing GraphQL semantics and do more sophisticated data logic. Potentially, this could be standardized or partially standardized, reflecting how SQL evolved originally.

Cool. Thanks a lot, Evan. Looking at the time, Alex, do we have more questions lined up? I have a sweeping question for all of you that I'm very interested in asking. I'm curious about your predictions for the future with GraphQL. How will it change things and evolve? New features like defer, stream, live queries, and client-side availability are exciting. Making interoperability with other API specs easier, such as with GraphQL Mesh, can boost adoption and innovation.

Evan emphasized refinement and evolution of small features, extending for common web use cases. Long-term aspects like the broader usefulness of GraphQL outside typical front-end applications and API contexts are intriguing. The community-driven evolution of GraphQL, where innovations lead to standards adoption over time, resembles the historical evolution of technologies. Exploring these evolving trends and potentials can shape the future landscape of GraphQL usage and integration.

Feature Expansion and Future Vision of GraphQL

Short description:

New exciting spec changes, enabling feature adoption outside the spec. Enhancing interoperability with various API specs via GraphQL Mesh. Long-term vision of GraphQL's utility beyond standard contexts, focusing on security model standardization and innovative infrastructure.

So some things that I care about or I hope will happen is I think there's a lot of new features coming. They're coming slow and it's a good thing but they're coming, like defer and stream, live queries, one-off directives, client-side availability. Like there's a lot of new spec changes that I think are very exciting. They're already being used in, let's say inside Facebook, for example, and I think there will be valuable for many others. One thing that we did recently is that we gave options for people to use these features outside of the spec as well. And I think that might encourage more people to try these features out and then give feedback and that will actually make their working group just adopt these things faster. A bit like what Evan said, there will be some people push the envelope forward and then others, the standards will follow.

And I think, also, so that's something that I care about and I think it will be easier. I see also, like, in our case, we see more and more of like making that interoperability with like other API specs. So in our case, we're talking about GraphQL Mesh where it's a tool where we could take any basically source, like OpenAPI, Swagger, GRPC. So, and then basically convert that automatically into GraphQL and let you query these things. And first of all, I think it will help a lot of adoption because I think it makes it easier to just start with GraphQL over whatever you have already. And the second thing that we're seeing is that by interrupting with those, all these different protocols, we actually find really cool features in these other protocols that we want to then break into the GraphQL spec. So yeah, those are just a couple of things that I'm excited about. Evan, what would be your prediction?

I mean, I think we see lots of refinement and evolution of the small features, you know, extending for common web use cases. I think that the things I'm excited about are more long-term, like, can GraphQL be more useful outside of the typical, you know, front-end application querying and API context. Like, can we get the security model standardized in an interoperable, general purpose way across vendors and the entire ecosystem? You know, REST provided implementation patterns and made things comprehensible for an individual developer, but it didn't give you that, like, so to speak, like rich tapestry of services you could consume. Like we were promised in the Symantec WebPage or the XML RPC days, like, you know, the dream that, you know, you'd have one cent to get a stock quote and you'd go find the best service on the fly to get that quote, and it would come back a common format. Like people aren't really going to do that, but what they are going to do is be able to mix and match very aggressively, more sophisticated and special purpose and innovative infrastructure and API and business services than they were able to before.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

From GraphQL Zero to GraphQL Hero with RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Local State and Server Cache: Finding a Balance
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Panel Discussion: Future of React
React Summit US 2024React Summit US 2024
39 min
Panel Discussion: Future of React
Watch video: Panel Discussion: Future of React
Kent C. Dodds
Shruti Kapoor
Mark Erikson
Eli White
Mofei Zhang
Theo Browne
Tom Occhino
7 authors
We're going to be doing a future of React panel discussions. React 19 is in RC stage and we're excited to hear when it will be stable. The React compiler is here to stay and is the future of developer experience and tooling. React 19 brings exciting features like RSCs and consolidation of the framework. React's commitment to community and innovation is commendable. The React team values feedback and actively engages with the community. React's future includes supporting the community and enabling smooth migrations. There's a need to teach underlying concepts and educate AI systems. Teaching and adapting to React can be challenging. The React compiler changes default re-rendering behavior. Collaboration with Next.js and Vercel has been valuable for React's development. Appreciation for the community and partnerships with Vercel and Microsoft.
Batteries Included Reimagined - The Revival of GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Batteries Included Reimagined - The Revival of GraphQL Yoga
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
Rock Solid React and GraphQL Apps for People in a Hurry
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Rock Solid React and GraphQL Apps for People in a Hurry
The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out RedwoodJS.com for more information.
React 19 Panel Discussion
React Summit 2024React Summit 2024
27 min
React 19 Panel Discussion
Ryan Carniato
Evan Bacon
Sathya Gunasekaran
Tim Neutkens
Brooks Lybrand
5 authors
The Talk revolves around React 19 and the React compiler, highlighting its new APIs, optimizations, and impact on frameworks like Next.js. The React compiler has undergone multiple iterations, resulting in improved performance and alignment with developers' expectations. The integration of React with Next.js simplifies rendering and offers free optimizations. There is excitement about the opt-in approach of React Server Components and the potential of underrated features like suspense and transitions. Overall, React's influence on the JavaScript ecosystem and UI libraries is acknowledged and appreciated.

Workshops on related topic

Build a Headless WordPress App with Next.js and WPGraphQL
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
Build with SvelteKit and GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Workshop
Scott Spence
Scott Spence
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
Relational Database Modeling for GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
Workshop
Adron Hall
Adron Hall
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
Build and Deploy a Backend With Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Building GraphQL APIs on top of Ethereum with The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
Workshop
Nader Dabit
Nader Dabit
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.