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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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...

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.

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.

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.

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.