Video details

GraphQL Berlin Meetup #20: Beginners Welcome + quiz with prizes!

GraphQL
02.03.2021
English

🎤 This edition of GraphQL Berlin Meetup is dedicated to the new adepts of GraphQL art. We've two amazing speakers scheduled for this event:
◭ Vignesh T.V. - "GraphQL from A to Z"; ◭ Stephan Schneider: "Ramp up your GraphQL learning experience with data you already have".
Dominik Kress, the author of "GraphQL: Eine Einführung in APIs mit GraphQL" will drop by to chat about some challenges that the new GraphQL users could face.
Prize pool for this meetup's quiz:
◭ "Learning GraphQL: Declarative Data Fetching for Modern Web Apps Book" by Alex Banks and Eve Porcello
◭ Prisma swag (t-shirt, stickers, face mask)
◭ Contentful swag (socks, stickers)
0:00​ - Intro by Daniel Norman 3:11​ - Vignesh T.V. - "GraphQL from A to Z" 50:55​ - Quiz 56:45​ - Technical Difficulties Hiatus 58:19​ - Interview with Dominik Kress 01:09:19​ - Quiz 01:13:25​ - Stephan Schneider - "Ramp up your GraphQL learning experience with data you already have" 01:53:16​ - Quiz

Transcript

- Welcome to the Beginners edition of GraphQL Berlin. This edition of the meetup is dedicated to the up-and-coming adepts to the GraphQL art. So while this meetup has started in Berlin. The transition into this online format has allowed us to bring together the global GraphQL community. I'm your host Daniel, and today we have two speakers, and a special guest is gonna drop in. Our first speaker is gonna be Vignesh T.V. whose talk title is, "GraphQL from A to Z." Followed by the special guest. And finally, Stephan Schneider, who's here to talk about "Ramp up your GraphQL Learning Experience With The Data That You Already Have." This meetup is organized by Prisma, and in case you're not familiar with Prisma. Prisma is the easiest way to work with databases in Node.js and TypeScript. So, today we'll be running a quiz throughout the event, and the quiz will be split into two parts. In order to participate, you can go to slido.com/graphql, and we will drop the link in the chat so that you can find that quickly. And the first place of the quiz will win a Learning GraphQL book by O'Reilly, Prisma swag, Contentful swag, And then the second and the third places will also win some of the Prisma swag, and the Contentful swag that you see on the screen. So, to get us started, we already have a little poll here, and we'd love to hear where you're joining us from. I'm joining from Berlin. Vignesh, I believe, is joining us from India. And our other speaker, Stephan and our special guest, Dominik I believe are also joining from Germany. So we have a guest from Kenya, that's lovely to hear. We're already covering two continents. We have Bangkok, Thailand. So that's three continents right there. Let's see, London. So as you all join in, be sure to keep your Slido window open, so that you can participate with in the quiz, because the quiz will be running throughout the event. We also have the U.S. so we have now America, too. So, it's really lovely to see how the global GraphQL community's coming together. And I think we can already introduce Vignesh. So I'd like to introduce Vignesh before he sort of comes on stage. And in case you don't know, Vignesh is the founder of Timecampus a bootstrap startup building, a time management platform for users and businesses. Before becoming a solopreneur. He led a research and development team of 25 at Ramco Systems. And also served there as a consultant for some time. He spends his free time blogging on Medium ans about a range of topics from time management and productivity, to the open source ecosystem. So GraphQL, Kubernetes, web components, architecture and so on. So now without any further delay Vignesh, how's it going? It's nice to have you here today. - Hey, Daniel, it's good, going actually, apart from the COVID situation, we have out here. So, everything's great. So how are you? - I'm doing well, it's a little bit cold here in Berlin but, I'm really excited about some of the content that you have ready for us today. - Yeah, I'm excited as well. Actually I really, I'm excited after seeing all the people joining from throughout the world. So yeah, hi everyone. - Okay, so without any further delay I give you the stage. - Sure. So let me begin so that I can quickly get started with the session. So yeah. So, I hope you are able to see my screen if I'm right? Okay, yeah. So today's talk is going to be about all about GraphQL, right? So as Daniel mentioned so we are going to talk about GraphQL A to Z. Actually before starting off this session I had a discussion with the Prisma team, on how we should title this talk. We started off with the title, "GraphQL A to Z." Then I titled it, "Diving Deep into GraphQL." But then finally realized the fact is that it is not possible to cover A to Z, or go deep into GraphQL in the 30 minutes I have, 30 to 45 minutes I have. So it's not possible to go deep, but what I will do in this session is probably take you through, or walk you through a crash course of what GraphQL looks like, the entire ecosystem of tools out there. And once you are introduced to everything probably you can read more data on that, or read the blogs in this table. So let's get started with a quick introduction about myself. So myself Vignesh. So as Daniel introduced to all of you I'm a solopreneur working on Timecampus which is a time management platform for users and businesses. And I led an R&D team before. So my background is a full stack developer and I used to work on develop as well and quite a bit of machine learning. So, I like to call myself a generalist. And this is what is Timecampus all about. So it's a time management platform. It's a bootstrap startup. We are launching soon in two months. So, we have a lot to talk about, so without any of this introduction, so let's jump into GraphQL straightaway. And for a context, so this is what the stack looks like. This is what we use at Timecampus. So if you see all of it is bleeding edge, I would call it a cloud native stack, and you see graphical right out here. So it's basically a stack, which is meant for solving the next generation problems in a most interesting way. So, I will actually give you a context about all of this at the end of the session, but let's jump into GraphQL for now. So, this series on GraphQL is what I published on Medium a month back. And it's probably about 66 minutes long. And we are going to probably shrink that into 30 to 45 minutes, and probably give it to you in this session. So, that's what we are going to do. And let's jump right into it. So, what is GraphQL? And all this content which you see here in this slide is taken from GraphQL, so I have done nothing here. So I just put over all the amazing content out here. So you can basically see what GraphQL is in one slide. So GraphQL is a query language for APIs. So you have risk APIs, which is one way in which you can query data, do operations on data. So you can create, records, update request. So you call it CRU, right. So GraphQL is like a compliment to REST, or rather I should say, substitute to REST, not compliment. So it basically, takes over from REST, on all the challenges we had with the REST. So from having to define every single end point for each and every operation we would want to do, for instance, for getting the user information you would probably probably define an API. For creating a post, you would make an API. For getting the list of course you would make an API. So the list went on, and on, and on, and it became difficult to manage. And it's not just that problem. Now we had ton of other problems, because, you had to make a ton of initiative calls, just to get information. So that's where GraphQL came into picture. And the most important part about GraphQL is it comes... As I said, it takes over from the challenges with REST API. So let's quickly get into it, probably you can understand more as we go on. So first step is ask exactly what you need. So if you want a user name, or user information, or if you want to get on a list of all your friends that's exactly what you ask for, and that's exactly what you get. So if you see here, you just ask for a hero name and what you get is hero name. And the second part is, you can get as many resources as possible in one request. So, it's not necessary to make a single record for getting the user information and another four posts, and other four comments. So you can rather, for instance, in this case I can ask a hero name, I can ask his friends, and I can ask their names and whatever. All the information, all the related information I want, in a single query, or mutation. So that's the power of GraphQL that to reduce the end number of CDU requests you make into one. So that's an amazing part. And the next important part is the type system itself. So GraphQL has a powerful type system which is also served documenting, for instance in case of APIs I have to define a swagger documentation to compliment all the APIs which I have. So, I have to define what my payload is going to look like? what my end points is going to look like? What are the types, every different, all the things, right? And it's not also enforcing. And then you have to go to the code and add validations to it. So, you had to do a ton of things to get it strictly type complaint. And sometimes you might end up defining a swagger documentation for a field to be string, and you might end up using the same field as APIs. So it doesn't enforced a type of swagger is meant for documenting the type. So rather, in case of GraphQL we have a powerful type system, which helps you not just document, but also in four steps. So your validation would allow you to query or do mutations, if the type doesn't match. And if you see here, it's not just a type of a single element. So you have listed elements out here, and you have a powerful type system, and you navigate through. So there are basic types of GraphQL support. One would be ID, ID type, a special type of hold IDs. Another one would be String. Another one would be Boolean, and another one would be Float and then Intesa. So these are all the types which are GraphQL supports in out of the box. But you can also add eight to it. You can define your own scaler, or you can define your own DateTime type. So you can define your own geocoordinates. So all of the power is lifted. So GraphQL tends to be minimalistic framework for all the people who are out there. So yeah, that's what GraphQL is all about. So as the website states, describe your data as to what you want, and get predictable results. So yeah, that's pretty much GraphQL. And let's dig deeper into this scenario. So, in case of REST API you will basically create multiple versions for multiple sets of data. You're going to query, going to mutate. So each and everything will have its own versioning. So, but in case of GraphQL what you have is a single endpoint. So /GraphQL and that is the only end point you use for doing all the operations. And if you want to add a new field, remote field, you just operate on the same field. The market has deprecated, you use directives to market as deprecated and you just proceed. So, I don't want to make this a GraphQL tutorial so I will just stop here. So what you can do is you can also generate a code, you can generate a TypeScript code from GraphQL schema. So because GraphQL is strongly typed, you can do a lot of powerful things with it. Your editor can support intelligence, and you can generate, as I told you the TypeScript typed out of GraphQL types. So you can do almost all of it. And not just this, there's a powerful feature called introspection in GraphQL that you can ask GraphQL about the schema and it will return back all the response, regarding the schema itself. So, I'm talking about powerful developer tool. So this is GraphQL, and this is how it looks like. I just quickly skip through this video, so that you probably get the picture. So, you can basically ask for the title of all the films you have, the opening scroll, and you can just ask for the fields what you want and you will get the response. So that's what GraphQL looks like. So you ask for the title and opening scroll and you get exactly that. So if you see here, you just did a control click, and you can drill through the documentation. Okay, I am going into the film type, and I'm going to all the basic types, which it has. So that's the power of GraphQL. So it's not about just the schema itself. So GraphQL has a complete ecosystem around it. So there are a lot of developer tools out there which builds on top of GraphQL using the powerful features like introspection. You have other things like subscriptions, you have the powerful type system. So, GraphQL does come with a lot of perks. But, before we dig into more of GraphQL and the ecosystem, so let's quickly look at a history of how GraphQL has evolved over time. So it was initially created at Facebook. So the Spec was open by around 2015, with the just a rough implementation written in a JavaScript, which is GraphQL today. And after that people really identify that this would be the next birth of APIs. And that's due to a lot of factors. One more important thing about GraphQL is that it is protocol independent. What I mean by that is, so you don't have to worry about whether you use HTTP, RPC, or Websockets, or anything for that matter. So you can directly do all your operations, using the protocol you already use. So that's all the power which GraphQL comes with. And recently Facebook moved GraphQL to GraphQL Foundation. I mean, they created a GraphQL Foundation, and they pushed graphical project there. And now that is where even other projects like data loader and other projects live. So, and here we are today. And if you just look at the GraphQL system, the size of it, it is not possible to talk about all of it in this 30 to 45 minutes I have, but let's do some justice to the time we have, and the tools, and the ecosystem as a whole. So, I don't want to go so deep into REST versus GraphQL but let's quickly jump into it. So, before this was the case. So you have a Backend For Frontends. And so, if you are using REST, this is how you would do backend for frontends For instance, let's say that you have mobile you have a website, you have another client, you have... So, what people ended up doing is, by the way this is the architecture of Spotify, if I'm not wrong. So Spotify, what they did was, they created a separate set of APIs for each and every client they are using. The reason was that they don't want to transmit all the information over the way. So, they didn't want to reuse existing APIs because, existing APIs tended to give a lot more information than what is actually needed. So, what they rather did was they breed out separate APIs for each and every client out there. And that's how they work around because REST, they didn't have any of the solution, because that's all they have explicitly. And if you're using a mobile, you can just query for the data you need. If you're using the desktop, you can just query for the data you need. So that's how the tradition has changed from REST to GraphQL. So, if you see here left and right, so for getting the same information you need to do three requests in REST, and you can just do it all with one request in GraphQL. So you can minimize the number of requests you send over the where, and you can directly get what you need. But now that I have talked about all of this, is GraphQL good for everything? So we do have REST as well, right? Which is a powerful competitor for GraphQL, especially given its simplicity. So sorry if I'm going too fast, but that's because we have a lot to cover. You might actually see me going through GraphQL A to Z. So yeah. So is GraphQL good for everything? And I would say no, the reason is because, it depends on your use case and complexity. So, let's say that you have a simple use case, where all you want to do is get the latest, let's say weather. So in such cases, if that's the single end point you have, so why bother putting up a boilerplate, with GraphQL while add more complexity to the stack? So, you can just define one endpoint, one REST end point, to basically give you the latest weather for the respective location. So, GraphQL may tend to be over complicated and we'll also have some more challenges that we'll be talking about as well. So, GraphQL does quite a lot of boilerplate on the server side to get it set up properly, especially if you are using a federated, or distributed architecture of distributed data graph. So, by distributed data graph, what I mean is you split your schema into multiple microservices. So, GraphQL comes up with all these problems, but yes, there are solutions available to all these problems which are outlined in my blog post. I won't go so deep into all of these, but there is N+1 problems where, you make N number of requests plus one, for making a single graphical request. So for instance, let's say that you want to get your friends and the list of posts each one of them made. So, you will end up making end calls for your friends and plus one calls, and then you have to again, make call to get their posts and then that information. So it comes up with the N+1 problem. Then it doesn't have caching in place because, you typically use a single end point, right? I mean, not typically, use a single endpoint in GraphQL. So, you don't have all of these HTTP caching in place with GraphQL, which you can do with REST. So, because ultimately, all the data is going to be sent through your payroll, and you're going to use a single end point. So there is no point in caching that HTTP end, et cetera. But, there are other ways you can catch the requests. You can use persistent queries. So all of that can be done. And then you have to worry about query complexity. So for instance, as I showed you, so you can have multiple levels of nesting in GraphQL, and there can be end levels of nesting. And as in when the number of levels of nesting increases, the complexity of the query increases, because you have to do a lot more CPU complex tasks, right? And not just that, it's also about the computation you need to do to retrieve the data. So GraphQL talks about the business data graph as you would see, by then, what I mean is, so you don't expose the technical complexities behind the scenes. So you might have named first name as, "First underscore name," in your database, but that doesn't matter. What matters is what you want to expose to the clients from a business perspective. So if you think that, okay, I need to have a user, and he, or she needs to have first name, last name, and all of the information related to it. So, I just define the respective schema, and I define all the fields, which they have corresponding to the prospective schema, without worrying about the technical things behind the scenes. I mean, I don't worry about what database I am using. I don't worry about what the field name is behind the scenes. I don't worry about one data source. I mean, the number of data sources I have behind the scenes. So, it abstracts a lot of things. But, along with it comes the complexity as well, because you don't know how many queries you're going to make to get that respective information. Then you have complex boilerplates, as I told you. So yes, GraphQL provides a huge amount of power to the clients, but that does require a significant amount of work to be done on the server side. Yes, there are tools to make the job easier for you, but that doesn't mean that the complexity is reduced. It's just that it has been made easier for you. And then you can distribute data graphs. So if you are using a microservices architecture, you can put one data graph for every microservice. You can use a Apollo Federation or schema, stitching to basically help you split one data graph across multiple different microservices. So if you are working with multiple teams. So, GraphQL to the client, is always going to be a one schema, or one endpoint, right? So you are not going to worry about... The client is not going to worry about, what a team maintains the respective data graph, or where the data is coming from? What they worry about is, just getting the data from a single endpoint. But, that comes with... Behind the scenes that comes with the distributed architecture as well. So as you scale, as the number of teams increase, you need to distribute the data graph across multiple teams. So, these are some of the technical problems I talked about. There are more which I've written in my blog, so better have a look at it before you jump right into GraphQL, because you don't want to go in the middle and get stuck right? So, better have a look for all of these, but all the time problems technical in nature, not all because, it needs GraphQL requests change of thought from an organization perspective. And that's why people at Apollo have made a great website called Principlesgraphicql.com. And you can have a look at it where they say, "What are the various things to keep in mind "where you build a data graph architecture?" Distributed data graph architecture. Which means, "Okay, worry about the business terminology. "It's not the underlying technical complexities." "Take care of..." What you say? "A federated architecture, have a distributed architecture." So they talk about all of these in the Principlegraphql website, better have a look out for it. That they will talk about the ways in which any business. So GraphQL is not just a tool for developers, but it's also a tool for the business and the product manager around. So, because it gives a better sense into the data, which your business collects. Almost every product has correct data, right? So, it is important for you to understand what underlying structure of the data is? How you want to architect your data for the organization before you jump into GraphQL. So, yeah. No, let's talk about a fully typed GraphQL based architecture. By the way before I go on further. So, if you have any questions, so feel free to drop it down in YouTube chat, or send me a PM. So I would be glad to look at it. But in the interest of time, I'm moving forward. So, let's talk about a fully typed architecture. As it told you GraphQL is a fully typed ratio So, you have a strict schema in place, you have strict data types, which you have to follow. And that is a great advantage because, you get the power of Intellisense validation. So it is better to have the compiler do all the work for you, or the editor do all the work for you, rather than you doing all the work. So that's where it really plays a major role of fully type architecture. Because, you as a user may make a mistake sending a string where the expected type is an end. But, having a fully typed architecture will avoid such kind of mistakes. Not just this, will also help you, give you things like auto-complete. So if you are say, wanting to know what are the respective fields supported in user? Rather than going to the documentation and looking up all the fields, you can just use the auto-complete which it provides. There are lot of other things as well, which it supports, and it's not just for you, but also the tools that you use with GraphQL. So, as I told you, GraphQL provides introspection so you can use introspection to do all of it. So that's why a fully type architecture is really important, because you have an end-to-end validated system in place, where you don't make these kinds of silly mistakes. Because, one small type change can cause a myriad of failures across the stack. So, you want to avoid that, and you want to make the developer experience great as well. So this is why Johann's from Prisma, a CEO of Prisma, had actually talked about fully type architecture in other sessions, I just took a snip of the same. So you have a front end, you have a GraphQL gateway, that all the front end queries, and you have microservices each with its own APIs. In this case, it is GraphQL APIs, it can be REST as well. And you have a DM, data management, or data model in place, and you have a data access layer. So data access layer is where Prisma comes in, or GraphQL mesh, which we are talking about, also comes in, or any ORM for that matter. So, Prisma and GraphQL measure ORMs. And you have a database, it can be anything. So in case of Prisma, example, it's multiple databases. So, and same with GraphQL mesh, it supports multiple data sources. So you can have multiple data sources underneath. And this is a, what you see in right, is how I have architected in Timecampus. So my database is Dgraph, which is a GraphQL native. I use GraphQL , I use TypeScript Codegen to do all the typing for me. So we'll talk about all of that as we go along. So now, before we get into the tools, let's quickly look at how you go about architecting a GraphQL app. So there are a few questions you need to ask. I won't go into all these details completely because you don't have time for this. So, but you need to see, okay, do you need monolith/microservices? Do you need VMs containers, or bare metal? All of these questions will also decide the way in which you would want GraphQL to be architected. Because for instance, let's say you want monolith. If you are using a monolith for your architecture, then you don't need Federation. You don't need schema stitching in GraphQL. So you don't even need a GraphQL gateway. All you need to do is have a single GraphQL server, and then just acquainted it, whenever you need it. or do mutations on that. By the way, by mutations, what I mean is if you were doing any operation except query. So creating, updating, deleting, those are all mutations. So yeah, by microservices, microservices do require a distributed architecture, because you don't have a single point where you can query. Yes, you can have a single GraphQL gateway and then multiple microservices each talking with gRPC. But yeah, it depends on how you architect because, ultimately that's what I'm trying to say. All these, would decide the way in which you would want to architect GraphQL. So VM containers, or bare metal, Kubernetes, Mesos, Swarm, or or OpenStack, scaling needs, because, the more you want to scale, the more you need to see. Because, let's say you have microservices running behind the scenes, and you're using GraphQL for communicating between microservices. Now GraphQL is protocol independent, right. So you can use GraphQL across gRPC. You can use graphical across HTTP So, the entire microservice communication has to be decided based on the performance you expect out of your architecture. So, if you want high performance, then it is better to go for things like gRPC, or HTTP, which is in the line, so yeah. So all of these are some things which you need to keep in mind before you start the GraphQL. So this is pretty much the checklist I use. And I have basically added all, I'm not going to read this out. I've added all of this in the blog which I've written. So you can go into further, but before selecting any tool for my architecture. So these are all the questions I ask. So does the tool solve my problem well? Does it have the right licensing model? Is it open source? Is it supported by the community? How many downloads it has? So, all of these are some questions that you need to ask, before you jump into GraphQL. Because, once you choose a tool, yes, you can change the tool, but it is difficult to change the architecture. So you need to keep the architecture in check, and the tool can evolve over time. So ultimately what I would suggest is pick a tool which is adaptable to change, which doesn't lock you in. So that would be a best start for you. Hah, so we have talked about all of this but, now start the journey with the GraphQL ecosystem. And that's where this disclaimer in place. So, you better not get too overwhelmed by what GraphQL has to offer you, because it has a lot to offer you. So let's quickly jump into it. So, the first one would be VSCode, and if I'm not going to talk about VSCode don't worry. I know all of you are developers so, you use VSCode every day but, GraphQL is one of the powerful extensions. So VSCode GraphQL, Apollo GraphQL. These kinds of extensions, do provide powerful intelligence support, code navigation support. They provide, what do we say, configuration. So in case you are using VSCode GraphQL, you can also execute queries and notations directly from a GraphQL. I mean that from VSCode. So, you can do all of that. So, the reason why I have put VSCode at the first, is because, that's pretty much where we developers live and breath. Okay, you might be using a different editor, maybe Atom or something else. But yeah, so what I'm trying to say is, VSCode would be the first platform and all these extensions are already available. So for instance, you can prefer your GraphQL schema using prettier. So you can, what do you say have linting rules in place using GraphQL ESLint. So, VSCode GraphQL can basically provide you all of these auto-complete and everything. So, yeah, that's VSCode for you. So, now the next thing which you need, important thing which you need is, so if you are using GraphQL and all the tools and ecosystem around it you need a VSCode to configure your schemas underneath. So you need a way to define, "Okay, where does your schema ally?" What are the various ways in which... Where does my documents lay? Where does my fragments lay? So what are the ways in which I want to use GraphQL? Do I want to generate TypeScript code out of it? Do I want to probably use it in a modular fashion? So, all these configurations, will be basically done in GraphQL config, it's not a norm. So you can use your own configuration, to do it. But the reason a GraphQL is really science is because, you got a single tool, or a single place, where you can specify all the GraphQL configuration because, all the tools which built around GraphQL, will need the same information. Almost the same information to identify, or provide features like auto-complete, or anything for that matter. For instance, unless any tool knows your schema, either through introspection, or by directly specifying the GraphQL. They won't be able to provide the powerful features around GraphQL they are providing today. So, that's where you get all the data types. So, GraphQL config is like a single way to provide context for all the tools around GraphQL. So, this is pretty much one way to specify where I've said, "Okay, this is the schema I need, as persuade the wildcard." So I want to use a GraphQL Codegen, which means that I want to generate TypeScript tights auto-craft tool. So I have said that, "Okay, generate the type for me, "and use all these plugins, to generate all the types." So this is what I mentioned, and you can specify multiple projects. And for instance, VSCode GraphQL uses GraphQL concrete to do all of its powerful stuff. So VSCode GraphQL is one of the tools which has been donated to the GraphQL org. It was made in Prisma initially. And they donated it to GraphQL Foundation. It's a really powerful tool. It just needs a bit more maintainership from the community, but it's really amazing. So, you can say, "Okay, this is all the type I have." So it will provide you with highlighting. It will provide you, what do we say, schema highlighting or Syntax highlighting, the code navigation all of that. Auto-complete and everything. So, now coming to the next tool in the ecosystem. So I understand I'm taking you through all of these tools. The main reason is to explore all these tools, so that you can treat them right where it is needed to be a fit. So in a typical workflow what you have is you define your schema, GraphQL schema to define your data graph. So once that is done, so you basically say, "Okay these are all the operations I want to perform." So you define your GraphQL server. You also define the rules you want in place, so that you can establish consistency among multiple developers in multiple teams. So, you need to do all of these, to get a proper GraphQL architecture in place right? That's where you need all these tools. So next I will be GraphQL ESLint. So it's a new tool from the Guild, GraphQL was also from the Guild. And what GraphQL ESLint does is basically, it's a plugin for ESLint, where you can define all the various rules, or conventions, which all the people must follow when they are defining GraphQL schemas, or when they're defining queries, or mutations. So that you have consistency, or even if you don't follow consistency, there is a tool watching out for all of this. So you can say, for instance you can specify that all the operations must have a query name or mutation name. So you have no anonymous operation require deprecation reason, for instance, you can deprecate a field without even giving any reason on why it is deprecated. So you have to be providing a deprecation reason otherwise through an error. So you can turn all these rules through GraphQL ESLint. Next comes GraphQL Inspector. So GraphQL inspector as well a... Assume that you have set up a GraphQL schema, you have defined the queries mutations, but now you want to understand, how many operations actually use that respective field from the schema. I mean, I had defined this field in the schema, but am I actually using it? So that's why you have GraphQL inspector helping you like saying it will help you with coverage. And it will also help you with a similarity. For instance, if you have similar operations, I mean a lot of duplicates. So, it uses the name to find out similar duplicates. So you can remove it if, what do we say, you are repeating the same field multiple times. Or same operation multiple times. And GraphQL inspector can be run as a data bag, as well as in your own CLA. So there are multiple ways to run GraphQL inspector. So in case let's say that you want to set up a request, and you want to make sure that all the schema is validated, it follows all the coverage rules. So you can do it all through GraphQL inspector. And then I added TypeScript as well to the stack because, now all the tools I'm going to talk about from now, we'll actually use TypeScript as a base, because TypeScript is a powerful tooling from Microsoft and you might be already using it. So I don't want to talk so much about it, but like GraphQL it provides a strongly typed system for all the editors and plugins to use. And the developers life is also made more easy. So you have intelligence, you have powerful type system, you have Syntax validations. And you can code in the bleeding edge a JavaScript Syntax without worrying about the compatibility. You can do a lot of other stuff with TypeScript, which I can cover in this session. And in fact, if I'm not wrong there is a Typescript volume data as well. So you can probably join the data group as well if you want. So next is GraphQL Helix. So I don't know if you would have heard about it. So a lot of people use express GraphQL or Apollo server for the GraphQL servers. But, GraphQL Helix is a new entrant in this area, but it it's a GraphQL sever basically but a modeler GraphQL server. So you don't have to worry about all the complexities behind the scenes. Rather, you can just use those features that you want from GraphQL For instance, let's say that you are not using Apollo Federation. You don't want your Apollo server to also include, all the code related to Federation, right. And not just that. So, let's say that you're not using the Apollo stack itself. But, Apollo serve will add all the boilerplate as well, because it needs to work with the suit of Apollo tools. And not just that, even if you're using other GraphQL servers for that matter. Be it , be it Express GraphQL, they come with all the features in bits, but what this does is it comes with just GraphQL as the dependencies, and it works across multiple framework. Express GraphQL works only with Express, right. So, if you want to use with some other framework you need to watch out for some of the GraphQL server. So this works across multiple frameworks, it's modular and you can scale as you go. It supports all the bleeding edge things like subscriptions, libraries, you have support for all of the things which you have in GraphQL. And it has only GraphQL as the dependency. Next tool in the stack that we're going to look at is GraphQL Codegen. So, what GraphQL Codegen essentially does is, based on your GraphQL schema, it helps you generate all the type script types, out of GraphQL schema. So, it essentially helps you write extra code, without having to define all the types yourself. So if you're working on your typing code you pretty much use typing. So interfaces classes, you define types. So, rather than that, since you have already defined all of that in your data graph, which is your GraphQL schema you can use GraphQL Codegen to generate all the other things for you from there. So GraphQL Modules. So if you're using a microservices architecture, it's pretty much evident that you want a modeler architecture. But, even if you're not using microservices architecture, you might want to quote isolation. So today people talk about monorepos, right. You want to have single repository with multiple packages. And it can be a monolith as well. And if you're using a monolith, still there is nothing wrong in splitting the code. In fact, it is highly recommended that you split code within the monolith so that, later if you want to transition to a microservices architecture, you can. So this is where GraphQL modules really help, where it splits your application into modular structures, with each having its own schema, with each having its own set of resolvers and typings. So this way, even if you want to share this module with some of the model you can do it, it supports dependency index injection. So you can do that as well. So GraphQL module is a way to split your GraphQL server, single GraphQL server into multiple modules. So, yeah, and this is pretty much how you use it. So for instance, if you want to, let's say, get a typing for your context, you can do that through GraphQL modules. If you want to, let's say, get the provider. So the classes are called providers because it provides a lot of types for you. A lot of functions for you, you get a provider and you do a lot of operations on the providers. So, this is how a single module looks like. For instance, I just define resolvers, which are related to this module. So I don't want to have a single file with huge number of resolvers as a scaled app, right. So it helps you to split your apps into multiple chunks. Then comes GraphQL Mesh. So GraphQL Mesh is pretty interesting because, it helps you leverage GraphQL without even having to transition all the code behind the scenes to GraphQL. For instance, you might be running GRPC code behind the scene, or you might be using REST APIs already behind the scenes, or you might be using an SQL database, or even Queues. You can just put GraphQL Mesh on top of it. So it will act as an aura, or an abstraction on top, and GraphQL Mesh will take care of the GraphQL part of it. So, it has an execution engine as well. So once you define, or it defines GraphQL schema automatically based on the architecture behind the scenes. And you can modify that as well with configurations. And once you do that, it basically takes care of distributing the operations queries, and mutations across multiple set services. So there are a lot of tools like this. I don't want to go so deep into each GraphQL tools you use for doing things like schema stitching, you use it for other operations behind the scene. Then type document or you have for, what you say, typing all your queries and mutations on the client's side. So in case you want to use, let's say a respective... You want to do a respective operation on the client side. All you do is you just define a respective type, and you define the variables, you get intelligence for that. So, yeah basically you can generate all the documents out of existing schema, and your client can basically query that. Dgraph is a graph database which I use in Timecampus. So that's something which I had a talk, or made a about Dgraph before. So you can check that out for more information. GraphiQL is the ID I showed earlier, which basically provides you auto-complete Intellisense documentation. All of that behind the scenes. And GraphiQL is not a single tool for that matter by that what I mean is it's an ecosystem of tools. So you have a lot of plugins, or packages running behind the scenes. For instance, the GraphiQL language services provides a GraphiQL specific service. And you have plugins which provide functionality for each and everything we are doing with GraphiQL. So, and even other tools, not just GraphiQL, leverage the same kind of ecosystem which GraphQL uses. So GraphiQL acts as a first implemented for all these plugins. And once I GraphiQL has implemented them the other tools also follow pace. Another tool I want to mention here is Playground from Prisma team as well. So that's also pretty good. In fact, GraphQL Playground has joined forces recently. And then there is GraphiQL Explorer. So if you have a schema, and if you don't have developers who understand GraphiQL, or you are starting off with GraphiQL, or even other ways. So if you want to have a simple way to define your GraphiQL queries and mutation by just checking the boxes, and running the operations GraphiQL Explorer is one such tool, where you can just check what you need, and then query it. And GraphiQL Explorer will get the data for you, or define the qualities and mutations for you. Then you have GraphQL Voyager. So we talked about introspection, right. So GraphQL Voyager uses this introspection and basically generates all these data graphs, from GraphQL to understand... So this is like an ER diagram rate. So what are various entities? How do they relate to each other? What are the various fields under those entities? So all of these is where they've got to wait. Then, you have GraphQL Upload. So you have HDB file uploads, similar way, GraphQL Uploads also has a way to upload files and documents, but that is not part of the same spec, but rather there is a parallel spec called multiple GraphQL, multiple spec, which you can use to upload and download files from GraphQL. Then if you're using real-time updates, or real time changes to your GraphQL server that's where you have GraphQL WebSockets. So, GraphQL WS will help you add a real-time update or a change feature to your GraphQL servers. We have Apollo Federation, which helps you distribute your data graph across multiple microservices. So each and every microservice can own a part of data graph. And then ultimately the users can see a single graph where you have all these in place. So this is our Apollo Studio. It's appropriately to not open source one. So, but still it provides a powerful tooling for GraphQL, to explore the schema, to view the change logs, and do all of the things with GraphQL. I added Gatsby here because, it pretty much uses the power of GraphQL to talk to multiple other plugins. So you define all of the data in GraphQL, and that's what Gatsby uses underneath, to do all of its operations. You have Opentelemetry which you can use to do instrumentation, and tracing, distributed tracing of GraphQL resolvers. So if you are using GraphQL server, and you're using multiple microservices, and you want to trace a drastical request across multiple microservices, so you can do it all through Opentelemetry. So recently it has been merged from OpenTracing and OpenSenses. Initially they were two separate projects, but now it has been merged and there is a new GraphQL spec code that you can. I would provide all these slides for you. You can actually go through all of this later as well. Then you have GraphQL Faker, which is basically a tool which helps you mark data based on your GraphQL schema. So if a string it'll probably do a way to expose all the string types. So if you have in detail... I mean it generates random data which you can use, rather than having to define all the data in your database, and then working through it. So rather, you can just say, "Okay, this is a type of data which I want, "and just get it for me." And it'll go and generate all the data for you behind the scenes, for instance yeah, that's what we are seeing here. So, even and the meet. And yeah, I would like to probably stop here. So this is how a typical GraphQL workflow looks like. So you do evaluation and research, get your boilerplate ready. You put together your data graph and documentation, you deploy it, . So there is a typical workflow that you want to use with GraphQL, I have outlined this via the blog, which he wrote. So you can have a look at it as well. I know I went at a huge base, probably if you are a beginner, you might not have understood everything, but, it's a start. So you got introduced to GraphQL. But, if you're not using JavaScript or TypeScript, almost all the tools I talked about today was related to JavaScript or TypeScript. There are other tools, similar tools in other languages as well. And if you want to have a look at it you can go to graphql.org/code. And depending on the language you use, whether it is a Golang or REST, or Java, whatever it is. So there are tools available, which does similar things, but may not be exactly same, but it does a lot of stuff for you. So you can go and check it out, and thank you. So this is where you can reach me. So in case you have any doubts questions, and probably the next time, maybe some other time we can probably go a bit more deeper into GraphQL, but yeah, thanks for that. Hey, Daniel. - Hey Vignesh. So thank you so much for that insightful talk. And we already have some questions from the audience. So, Nerisa asked-- - of course. - "Is GraphQL for smaller scale project, "or bigger scale projects?" Do you want to chime in on that, on how to approach that in such situations? - Sure, so when you are starting off with GraphQL, so graphical is meant to be incrementally adopted. So the scale doesn't matter. So, if you are using in a smaller scale project, you don't need all these tools in place. You just need the minimal number of tools to work, to get started off. And as you scale up, you can probably add more to the ecosystem. So it does cater to all these architecture assessment. - Got it. Okay, so on that note, there's no more questions from the audience. - Thank you, so it was nice meeting you all. - Thank you so much Vignesh. - Thank you. - Okay, so we had another question about Prisma migrate, and we will address that perhaps towards the end of the meetup, or I'll reply in the background. And now we're coming to the first part, the first section of our quiz. So let me just advance the slide here. It seems that, something is eating up my CPU, and slowing my computer down. So I'm sorry, there's a delay there. And now, I'd like to invite you to join the quiz. So, you can join it by going to slido.com/graphql, or by scanning the QR code. So, the first question that we have is, what are the basic data types supported out of the box by GraphQL? We have four possible answers here. First one is Geo, Int, Float, DateTime, Boolean and ID. The second is Float, String, Int, Boolean, and ID. The third is Geo, Int, DateTime, Boolean, and Char. And finally the fourth option is Int, Char, Float, DateTime, and Boolean. So you should be able to already submit your answers. Okay, it seems like every thing is rather slow here. I'm really trying to fix this. However, but it seems that this is beyond my control right now. So... Okay, let's move on to the next question. So, indeed the second option was the correct one, Float, String, Boolean, and an ID. And 80% of you got that correct. Let's see if we can advance this to the next slide. Okay, so we come to the second question. In a well designed schema, if you were to retrieve the profile info of users, their friends, their posts, the comments to the post, and the URL of the respective profile photos, what is the minimum number of HTTP requests, with which you can do that in GraphQL? And now the quiz should be open. Oh, let's see. Okay, so it seems like we're having a lot of technical difficulties right now. I suggest that we bring Dominik to the stage, our next guest while we figure out the technical problems. So, in case you're not familiar, Dominik, is the author of a new book, about GraphQL in German. - Hi there. - And the name of the book in German is "Eine Einfuhrung in GraphQL." So, "An Introduction To APIs With GraphQL." So I would like to bring... - So yeah. Hi Daniel, can you hear me? As it worked off? I currently can't hear you, if you can hear me. - Oh my goodness. We did not prepare for that. - Hi everybody, I'm Natalia. I'm events manager here at Prisma. And so it seems that Daniel's internet is just not there for now, and I will just carry on. So Dominik, congratulations on your book, super well done. - Thank you. - Well, lovely. And thank you for dropping in and joining us, and let's just have like a tiny bit of interview. It won't be as good as if Daniel was here but, he prepared a couple of questions. I'm hoping to deliver them in a way that would enrich the meetup. Cool, so maybe I'll start with, what will be the common pitfalls when starting out with GraphQL, what challenges could the new developers face when trying to get into GraphQL? - Yeah, so yeah, sure. Vignesh talked already about a lot really, a lot of pitfalls that you can have with GraphQL. He did a really, really good job in covering basically all of the topics about GraphQL. - Is that Vignesh? from the backstage as you can see. - Yeah, it's hard to find a new topic to talk about now, but yeah, sure. I think the first biggest issue that newcomers to GraphQL always have is, it's an easy one, because GraphQL is not REST. And I also think GraphQL is not the next REST. In general, I think that the time that we have only one tool that fits every solution-- - Nice. - It's over. And I think, especially with REST, if we think about APIs we always think about REST. And I think that's over, we have different solutions for different problems. And GraphQL is one solution for one specific problem, or a lot of problems basically, but it still has its its specific use. And that is when it comes to complex data structure and especially fetching complex data structure. That's quite an encapsulated like a tree. If you have a complex tree structure of your product, that you want to fetch in one call, GraphQL is perfect but, especially I'm really always struggling a lot if you have a lot of mutations. Especially a lot of mutations, so manipulation of data, in lower levels of your data, because in those terms you have a lot of different methods, or different functions covered in your mutations, and that can blow up your whole schema a lot. And I think so, the first pitfall is always, keep in mind that GraphQL is not REST, and GraphQL is not the solution for every problem. So, get to know what is exactly your problem. And then, think about if GraphQL really solves this problem in the best possible way, or if there is another solution for it. But if you answered that correctly, GraphQL is the answer for my problem. You still have to switch your thinking a bit, when you found-- - Yes, that's usually the case. - Yeah, especially-- - very well said. - If you started with REST, and then you start up with, now my next API will be a GraphQL API. You have to start thinking in graphs and not no longer in individual resources. Again, Vignesh did a great comparison between, what a REST APIs do, and what GraphQL does. And again, it comes up to your data is no longer structured in a flat way. It is structured in a tree, it is structured in a graph. And having a lot of references, especially ID references built into your schema, and then forcing you use it to use that ID reference to fetch another related object, is not the correct way you should work with GraphQL. You directly can nest, all of the objects within a one call and that makes GraphQL really awesome, but it really is a different thinking in that way. And yeah, there's a lot to to think about, for example, if you look at the schema, where you can have those Encapsulations that also needs to having a lot of options on how you can fetch your data. And with that higher power that you give to your clients you also have those clients also have a lot of responsibilities. And you have a lot of responsibilities because, your schema is at the end, the one source of truth about, how you can explore your GraphQL API. And I think if you have some naming problems, some unmatching pattern, or something, that is not that big of a deal breaker in a REST API, because at the end you still have your list of individual end points you can just trigger. I think if you have an inconsistent naming pattern that is something that is always a big problem. And I think, especially in... If you're a beginning working with GraphQL you should definitely be put a lot of focus on naming-- - Right. - As the old saying goes but, the hardest things that IT is naming and casting. - That's the specialty-- - Is that a thing? - flow, aircraft. Yeah it is-- - . Yeah, thank you for that, I see the Daniel is back. Let's see, how are you feeling Daniel? How is your bandwidth? - This is probably the worst nightmare that can happen during a live-- - Even it just, even it just my thoughts, exactly. - But worry not. - I just hope it does. How crazy it does finance the highest equipment I'm running a 16 inch MacBook Pro, the latest and fanciest one. So, I'm sorry about that, but we are back. Thank you so much Natalia-- - I'm happy that you're back. - Gracefully. - Okay Daniel. you hand over to-- to the dark of the backstage where I'm from and the most comfortable, all right. - Thanks, so, I believe that Natalia already asked you a couple of questions, and I probably missed a lot of the interesting, answers. So-- - In fact, she just asked me one question which was the first common pitfalls you have when you're a beginner with GraphQL. One of your prepared questions. So, you handled that really good, no hard to yourself. - Yeah, okay, so I have some more questions. - Sure. - And the first one, when it comes to GraphQL what are some of the testing approaches that you recommend when working with GraphQL? - So, looking back at Vignesh's presentation again, GraphQL is basically built up in... You have your schema on, schema have objects and those objects have a huge list of fields. And at the end, your GraphQL server is just resolving every individual field in a function that is called the resolver. That structure that GraphQL delivers to you is basically already a first good point to start your testing because, at the end every individual field is a resolver, and every resolver is a function basically. So you can have a very good unit testing with it, just to pass your individual end points. So to say your individual fields within the schema, and there are so many test tools to just do that. JS is one of the... No JS test tools I always use to basically test my resolvers which are just functions, so use whatever there. And if you go one layer beyond that, you can just have some basic HTTP testing tool. Again, on all JS like super test, which you can use in order to have some basic various sent against your GraphQL APIs, and good cases, some bad cases. And then you make sure-- - It would be like integration, or end to end test-- - Yes. - Because they're already testing this at the HTTP layer. - Yes, yes, yes. So, since you have your unit tests on the one side by testing and the resolvers, and then mocking the services behind that, it's always a good approach to also have at least some happy case tests for the GraphQL API at the end. It has one good thing, when testing your GraphQL API, you only have to test one end point. That's the good thing. The bad thing is that one end point can be really, really complex. And one good tip I always have when starting GraphQL, and working with GraphQL, especially when you're working with JavaScript, is always, if you have a problem, Apollo always has a framework to solve that problem. - Okay. - And so they also have a very good testing framework to test your GraphQL. - I guess that speaks to the relative maturity of the GraphQL ecosystem in JavaScript compared to-- - Yeah. - Other languages, right? Yeah, in general, the GraphQL community is one of the best communities I ever participated in, as you can see in the meetups the long. But if you look at the documentations, if you look at the all of that, I don't know why I wrote a book about it, when you can get everything in the internet. Alone, looking at, for example, one of the good examples is Shopify. Shopify also uses GraphQL, like really, really major levels. And they have so good documentations about how they handle GraphQL, and how they solve issues and really helped growing GraphQL a lot. - Got it. Thank you so much Dominik Kress for joining us today, and sorry again for the technical difficulties-- - No problem. - We hope to have you as soon again on this meetup. - Yeah, thanks for having me over, it was a pleasure. - Great. So, I think what we'll do now is we're gonna retry to do the the quiz, so that we can retry it. I'm gonna try to share my screen now for the second time. If you haven't already, I know I've said this a couple of times, feel free to join us on the Slido. The Slido/GraphQL. So you just go to slido.com/graphql. And I believe that we've already looked at the answers to the first question, and Tobias was the leader, he got this within 21 seconds. I should point out that the quicker you answer questions in the quiz, the higher your ranking will be. And I believe that we also had this second question. And indeed, that was a single request that you need in order to fetch as much data as you need. And now we come to the third question. Which of the following can be used as ORMs to work with underlying data sources in GraphQL? And so I invite you to join this, and submit your answers. We already have, I see six responses coming in. I'll keep this open for another 30 seconds, or so, just to let all of you get your quiz game going. Let's see, we'll count down from 10 before we close the poll. And that will be 10, nine, eight, seven, six, five, four, three, two. Okay, let's look at the answers. So indeed it's GraphQL Mesh in Prisma. Most of you guessed that correctly. Now we come to another question. How does GraphQL Voyager retrieve information about the underlying GraphQL schema? We have the first option is schema querying, introspection, schema stitching, and subscriptions. and on that note we'll close it. Indeed it was introspection. Most of you got that correctly. And it's gonna be the last question of this section. And then we're gonna have later on, another section of questions. So, which of these protocols are supported by GraphQL? HTTP, the first option is HTTP, RPC and websockets. second HTTP and Websockets, third, HTTP, Websockets, WebRTC, and RPC. And finally, it is protocol independent, that would be the fourth option. So 65% of you voted for it is protocol independent and you are correct it. It is independent on the protocol. And now we're going to wrap up, and let's look at the leaderboard. So, Tobias is still leading the charge, followed by Michael G. and Mathias. So congratulations, you're leading. Let's see if you managed to make it through the second section leading too. Oops, and now, I would like to, sorry. I would like to invite, oh, I would like to, first of all remind you that this meetup is organized by Prisma, I know many of you know that. We recently just launched a new Udemy course, and we'll share the URL for that. This is an end-to-end react with Prisma, and this course covers GraphQL2, and building a front end with next JS. And I highly recommended the course is by Dr. Steven Yense, he's a great teacher. And the next thing is that tomorrow we'll also have the what's new in Prisma livestream. Where Niko and Ryan, my colleagues will be discussing a lot of the exciting new features that we just released, in the 2.16 release. And now, I would like to invite our second speaker for today, Stephan Schneider. And Stephan Schneider is gonna talk today about, "Ramp up your GraphQL Learning Experience "With Data You Already Have." In case you don't know Stephan, Stephan is a backend developer at Contentful, since 2019. GraphQL is not just an interesting technology for him, when he started participating in the company's initial development of their first GraphQL API. And he's not stepped back since, and he constantly plays with new ways to integrate pre-existing data with GraphQL. So we found any further delay I bring you to the stage. Stephan. - Hi, I'm Stephan. - Hi Stephan. - So, let me get my screensharing in here. oops, I got... Should be all right, cool. - Right, . - So yeah, let me get my speaker notes up here as well. So that I won't be seeing , cool. Yeah, so this talk, the title already says, is about how you can use the data you already have. Meaning, some data from like maybe some project, or even from your company, or whatever, that is already existing. And you're like one exposed with GraphQL. Because suddenly, you're like really create a new project with a completely new data set. Or if you do it happens to be like quite overwhelming. And so the first thing is, how do I actually get to that point here? So in the beginning I was working with GraphQL, reading an example tutorial here and there, but then eventually I went with the company for GraphQL. And then we had like different things that we actually needed to try out and needed to do. And to apply technologies with specific questions in mind, or problems that I have. And so, just to doing like something else like a small starter and just learning how to query the data with it, was just not sufficient for me. So why we don't actually want a starter here? It's like, yeah, starter is a great way to show it a specific way of implementing something. And to scaffold stuff. You want to wire up, it gets be project. You have some content providers, some stylings, and default functionality, that tracking also if you want to combine together. And there's a really good to have a stater that gives you something. But, if you really want to understand the technology and want to reuse it afterwards, and remaster it, I don't think that this is really giving you much. And so I was then being asked by, "Stephan, at some point," but you know, developer relations person from Contentful who's also very active in the community. Maybe some of you know him. And he was like reaching out to us tonight. "You're doing so much with GraphQL, "What are actually the tutorials that you like?" And I didn't have an answer to that. Really not because I was never really following it. And I was like, "Why don't I actually encourage "more people to try it out with your own data?" And that's what I'm here for today. So, I wanna encourage you to try it out with data you have to prove to your project or your company. That GraphQL is a good option to choose here. And therefore we are not using the Starter, because that just shows that the project works like GraphQL itself works. And it's more about like you the data. And we are going to show you how we can do that, for your use case, so that you can actually get going and understand the underlying functionality. So you could argue, "Well "I can do the same thing was just like to do MVC "or simple block example. I can still build that from my ground up. And yeah, you can do, it's not specifically thrilling if you ask me, I don't really get my dopamine out of it. If something works, it's not really... My brain doesn't really know what it was expecting for you to see when you get the first time results, because it's not your data set. If you have something you're very much in love with, or you at least know the data should, then you see some data and you know directly, or immediately whether that's what you were expecting or not. So like the feedback loop for your brain also get better. I also like to do MVC , you can compare it quite good with other implementation. So, if you were there for like, I want to show off a new project, like Helix or Nexus or whatever, and I want to show that it works, or how it works then to do MVC is a great thing. You can just jump in there, and give a specific feature set, you can replicate, and then you can compare it. And I think that's the difference here. If you're just doing it for yourself, with some kind of an intrinsic motivation, you want to prove to yourself that something would work with you, or for your use case. Then you're doing it like for yourself, and only you need to work with it, or understand it. Maybe some people from the company you wanna pitch it to. So it's like more intrinsic motivation. Extrinsic motivation would be for me here, you wanna showcase it. You want to put it into a blog article, everyone should read no matter whether they know your data domain or not. Then, having something very easy to understand, like it to do MVC, or block like a vertical . So it's not like fighting for doing it either way. It's just what do you want to achieve with it? So pitfalls. Because we all like to know about pitfalls up front, right? And usually, projects tend to go into two different directions. Either they generate no code for you at all, I will show you that in a second. And to me, I then struggled to understand what is actually going on in the background. And you don't really see the seam, or you don't learn too much from it. Or, you just like generated all the data you have, depending on what kind of data source you take. There can be a lot of code that gets generated. And initially you don't really understand what it's doing and you might not want to have that because you then need to touch all of them if you need to adjust it. So for me, that's like also very overwhelming. Then you just have like, "Okay, it just generated me, "dozens of things what is it actually doing?" And then also you might have some incompatibilities, let's say you use some character that is not allowed for GraphQL typemen. And the tool doesn't catch it properly. Also then probably the whole graph generation will just fail if you want to use it as schema. And there's usually not a partial generation you can do. So what can be those kinds of things wherever you need to do that is... One second. So for example, if you say you have a database already, on the database you have all the data already. So you are generating it from that database, you're getting the code generated, and then you look at it and see like, okay, maybe it fades because there's an ID field missing or so. We on our product that I will show you later, have an artist type, or artists object, which has no ID field, it only has like a slack, because slack is unique to it. So we didn't see we need to use an integer, but some tools might expect that. And then you actually need to work around that. We're in, got some tips on how we can do that later. And then at the same as Dominik just mentioned like naming conventions, they might just not match. We will see that on the example with Prisma later on, where I was using like the , I was called to the table naming in a database which didn't work out without some mapping. It will work in short. So, what I will be demoing right now is, Klubnacht, Klubnacht is a project I'm building with two friends, I have been building this two friends. Which it's literally just like a timetable app for club. And some of you might recognize it, yeah. So that's like from pre COVID area, obviously because nowadays we wouldn't need to go there. But if you go on some event, you get hear who is playing and you can actually do that retroactively so that you can see here. And then you can click on people to see when they have played and so on. So it's also rather simple from the data set. And we have been building that and we have a database for it, but we are only doing that on some REST ish API by now, because it has been a while since we have been working on that, the last time. What I want to use for that is how's it work. Some of you might've heard 'cause like for showing, what they are doing radically different than all the others. And whether that's actually good for the learning experience. So the terminal window up here. First I actually wanted to show here, is that I think would be better. So this year, for example, is the artist's table from what I've just showed you in this system, Which is rather simple. Oh, here you cannot zoom in, okay. Just very simple and here at MPID actually already, and give a name slack, whether it is like a resident which is like some kind of special things for an artist to be in a job. If you're a resident you basically are. One of the cool guys there. And you can see this is like lowercase here and on some other fields here is the site base, but it contains data where you need it, oops! You need it here. And we should be able to just generate that data over query from it. Hasura is very simple when it comes to that. If you have a database already, especially. Hostplus, which we happen to have. You can just oh, English commands, here you can obtain that from the website, which is this connecting to my local database here we are using for development. Once you start that actually in the background responds your Hasura. Terminal. , I think console, . Which we told it to be available on port 80/80. So we can go to 80/80, you can actually see here that it did a whole lot of you already. You have some nice visual, it's not that bigger for everyone here to see. You have a nice UI already where you can do things, you can explore already. And how we actually get the data, is by doing it here in the data. You can just go there and say, "Oh, here, look "we have tables that we are not tracking." So in preparation, I have already clicked here on the track button for the artists. And once you do that, you can already see here data to be previewed. You can modify the schema and edit it. So this here give you a whole lot of things. So in the end, if you can go back here to GraphQL, and probably be able to click on here. I guess I've already GraphQL API run. I mean, that's pretty awesome for you to get started but, if we come back, what have we actually learned right now? We have a GraphQL API, yes, but what do we know about the schema? What do know about how it was generated, how it works? And do we really now feel like more confident in working with the technology for anything bigger? I would argue no. So, there are other ways on how that can be done. And one of that is Prisma, or . And no I was not forced to bring in Prisma. It just happens to be a very useful tool. If you want to work against database, or data. And especially if you want to have more precise look on what is going on. Prisma is different to Hasura here, in that it doesn't just do one command thing and you're done but it actually generates your schema, or it generates these files, that you can then later on use to query your things while implementing the GraphQL schema by yourself. You can integrate that with other starters of tooling, to take that part away from you, but they are not very opinionated around how the GraphQL, or the data you expose to the GraphQL will look like in there. And then there are also tools that help you convert in JSON's shapes to GraphQL, because you might not just have the data readily available in the DB already. So if you happen to have just like a set of fixtures, you could use the whole core GraphQL adjacent server, so I think, but you have to have some very specific data set, that you have to put in there. And it's not really always to do that sometimes, and other times it might be. So again, here, it's more around... Oops, sorry. It's more around what do you want to achieve with it and what exactly went wrong. For some people just like showing yeah, here, this is how club timetable API would look like. Hasura definitely , right? But if we want to extend it later on, to example, provide for an artist, the next events and so on, we might need to customize something and we would need to research again how to do that within that system. So you would learn Hasura but you wouldn't necessarily run the GraphQL. Same could be argued with Prisma but here it's actually that you don't do on post-purchase, or SQL Lite or whatever. But you learn the Prisma way of how to generate your thing. How you will eventually end up consuming that in GraphQL, would be still up to you. So, here let's do the same thing with the Klubnacht Prisma client. You will actually finally run into that naming problem, and I can show you how that was actually solved. So here I should actually have, yes. So with the Prisma schema, just make that way more bigger for you. So the actual interesting part you provide by yourself is up here in schema Prisma file. And we're basically just saying, "Hey, go to the post-birth "and generate us something for JS file." Actually the TypeScript client, but, well, it sounds good at the end of the day. Then within our show, we have some one command that then can flex the schema from database, invites you those Prisma models. As you can see here already that model is also lower case, and it contains all the snakes case formative here. But, it actually already looks quite good. You get a good understanding of it, and it looks somewhat GraphQLish right? And that's also because it actually gets used for that later on. But, you wanted to generate something that is more in the shape of how which would be passcode case to an uppercased. P here, and an uppercase A here and no underscore in between. Luckily there is actually a tool that does that for you automatically. I run that over it and then afterwards it looks like this. And that one here looks already quite understandable to me. And I would feel confident in working with that somewhere within our core base. But, mind here this is like not GraphQL in itself right now here. This is just giving you a nice query layer on top of it. And for example, you could have as well have a corporate specific query layer. We have that at Contentful when we were building something. And then within our resolvers, we were just using our extraction and could still reuse a good chunk of functionality later on, in the old GraphQL. And this, go back, here? No, is it? All right, fine, here. So after you have actually generated the client that's what I was looking for. This is the only thing you got. Prisma client. And then for every type you have something generators here already. So you get actually type safety. And this one here will take away most of all the things you will ever wanna do in the first iteration of GraphQL API. And for people who are very, very new to GraphQL this one here is what we mean like the revolve on the revolver function, also Dominik was talking about earlier. If we resolve, we have to stick the assumption that it will always be something like that. And in here we can actually use that, the Prisma generated code. What we do by that, is we are actually defining ourselves here, how the data should be fetched later on. So if we combine that with this schema, SQL we are going to generate then, We explicitly define what we want to expose. And I think that is a very, very crucial. And we will get to that later that you're only doing in the beginning, like what you need. And don't try to get like all of your domain inter-GraphQL at the same time. Try to adapt it in increased fashion, and like step-by-step, and don't overwhelm yourself. In the end it's always about that, that you feel comfortable, and you feel like you've learned something because in the end, what gives you the dopamine? It's like the learning effect. That's how our brain works. And you want to teach yourself a bit, right. We are all at home, you're all struggling. Tease yourself a bit, get some dopamine, by just getting success when you do. As one might have recognized in here we currently don't have any data GraphQL schema defined. And this is actually fine, because as I said we had the REST API already beforehand. So, what we can do is we can use another tool, that gives us some rough overview of how that GraphQL schema should look like. And this called Transformthetool, it's a very handy website. I can only recommend that for you. Whenever I need to transform data in between formats, I usually look at that first, and why can I not use this you know? Well, yes. Oh, okay, well. This here is the website here is my locally running API that is actually . And if we look on a specific artist, we get events. This is basically reflecting right in this page. And if we are just lazy and want to have something, we're not so familiar with the GraphQL or Syntax yet, give us something that we can use to create an event, or an art. Here for the event is actually nicer because of this, nest Playtime. We can just copy the JSON and drop it in here. Oops, . And what can we get out is already the GraphQL schema definition, language that you can use afterwards. Most tools like Apollo, or most of the other things that Vignesh was telling you already about. Here we have slacks being string fields. You could now take that, and change the example being the ID fields. So now you have very, very much fine-grained specific, hands on dirty work with your data. And I think that's because that's where you feel comfortable. You know that data, you probably spot that here right away if you would be in that domain. And also the pay times here, linking already to an array of artists, you get some nice naming actually in sort already. And you can take that. And over this one here. And then later on use it in the types to actually combine that. So you might be wondering why we are only looking at Query here right now. And that is very easy to reason about, but you might still get that wrong. It's easy, but it's feasible to later on add more things to your GraphQL schema when you proceed. So what you wanna do is, you wanna provide the core use case, that you will be doing with the GraphQL API. And that usually is consuming data. You already have existing data that we were infecting on. So there's a known set necessity for you, to write mutations, to like put data into the system first just so that you can use it. And actually it would also be kind of like, you might be overthinking yourself. You might want to validate, or the user input. You might want to do some roles authentication, or whatever. That's all, everything, not that you should do, in your very first attempt on a GraphQL API. You should just get you the best, visible result output you get. And for that, you need a prototype. Even if you would design a mutation first, you would still need a query objects type later on, to actually get something back from that mutation that you've sent. So when you send the mutation, you also specify a query afterwards, that is executed to give you back, to see what has changed, or the success . So, you would either way still need to write the query path. So in the beginning, although with nothing else, querying is important. If you then at some point feel keen, or curious about mutations, this person, for example, it would be covered the client would also provide you with methods there, or you can then like step-by-step increase it. It also very important for mutations, think about it in a way on what you want to instruct the system to do. Don't do it like in an update X to Y kind of fashion, for I don't know, shopping, I think Shopify has this real expressive end product to cart mutation. Then, this is like really clear on what you wanna do. And in the beginning you might not know all these use cases that your API will have, because you're still thinking in REST terms, or even other terms like RPC, or whatever. And you might just have those create, read, update, delete scenarios in your mind. And once you work with the data, and you understand how they link to each other in the graph, you will come up with more specific mutations to do. I want to hear it, can we not stretch enough? Do only what is necessary. Yeah, your authentication I mentioned, or query complexity also is a very good point actually. Query complexity can limit the amount of data you can pull out of your GraphQL API. And you might think, oh that's super important to show to my company. So I show we cannot be DDOSed, or people cannot abuse us, to get like all the data. And yes, that's true. But those things and those scenarios, can be implemented later, and actually should be implemented later, because in the beginning, again, you're thinking in REST terms, you might not know, what is the most best query to get out of it. For example, for our Klubnacht homepage, or an entry, in the beginning you might just say, "Okay, you know what? "I just need an entry." Then, like in any event, sorry. And then once you have an event, you'll see, "Oh, I actually want like the one to the left "and the one to the right as well." So you could provide your previous event, or next event, also as fields on the GraphQL API. And that increases the complexity of the query you need to do. So design, or limit afterwards that protect your infrastructure, but designed for the most clear and expressive query user should be doing to get the data together. Also, you might be thinking, "Oh, I need to integrate that "within our current infrastructure," or something like that. "I need to prove that, "our HTPP server implementation that we have can do it." And we have the same thing in our company was in a Contentful because we are using Harpy for our services. And Harpy is a very good server, my point of view, but it was lacking a very good integration with GraphQL, or has been at least, because as Vignesh was mentioning with GraphQL headaches you can actually get that, it's like mostly every HTPP server running. And that, if I would've known that beforehand probably would have spent a couple of hours, because I was trying to embed that, and it didn't want to work properly. So in the end, we were using Apollo server, which was just giving us a little bit of a quick start, so that we could just get it running. The thing here to stretch again, it's transporting dependent in the end, it's about the schema. You just make the schema accessible via the HTTP server. But as long as you're building and working on your GraphQL schema, and resolve documentation it will work with all the service you can come up with in the end. You don't need to do it right now. You you're using Fastlyfire, or whatever. It doesn't matter, just go for Express GraphQL, go for Apollo server, and have a look afterwards. Yeah, there are things you should be careful in the beginning. And this one here is just like a personal experience. I don't know where the other people were actually struggling with it, but I found that to be kind of a nice anecdote. And that is the pagination approach. So, what I was doing in the very, very initial things when working with GraphQL, was just to collection it's narrowed, right? So I think even on the, on the GraphQL page is done like that, that you are showing, like the lists of things as an area. And that can work, but for most of the real world use cases you have, you need to slice those collections into subsets query, and you need to all of them. And this changes how you GraphQL skills more look like. If you don't care for that in the beginning, it is still possible to implement it. But type names change a lot, I figured, at least if you want to keep them consistent and expressive. Because now there was one more nesting level in between, that you need to go down. And that should just be accounted for. There are two frequently used things which is like offset based, color-based pager nation. And it doesn't actually matter at the beginning, which or both you choose and you also don't need to implement it. Just get the nesting part right. Just make sure that, if you are giving us, let's say here, events, and an artist has, yes. You know, all the way on here. And the artist has events, you could say, "Yeah, okay." That is just like the event. That would mean you always get all the events to it, that it's not necessarily what you want. What you probably want is if you have events, which is like an artist events collection. And see, your things start changing already. And then, you have this type here, which has depending on your implementation. And as I said, you can just admit that for now, I have, for example, skip for limit, or has some kind of cursor, you want to get the after. But both things are of importance here that you need to decide whether you wanna go with a relay-based approach, or the usual items based approach. You can read up on that if you're curious, for now I would just recommend you just put here items in, and then items are actually , very good. This way you can later on decide what kind of pagination you want to have without changing all the things you have done so far, all the example queries you might have shared. And yeah, the implementation for that is very easy, because at the end of the day, this is just an identity resolver here. The items just take the events that were passed and just pass them through. So, you don't need to care for that in the beginning. But, for me it's about a couple of hours of work, I would say. Yeah, you might be wondering now, well, this looks like very doing here. And why don't we actually have all those cool tooling above that are like, bootstraps all the project, generates everything. If you're in the end recommending us to go back, and just do it manually. Well, this is not what I'm recommending for everyone, but just if you really wanna deep dive into it, if you really wanna master the technique, you wanna learn this, you wanna validate a specific use case. Then the resolver is your best friend. You can do a lot with it. And like also was a type definitions when you do them with Nexus or GraphQL compose, you can do so much with it. And in my point of view, you would only scratch the surface if you're using only generation tools. If you want to get the best out of it for your customer, or for your project, or whoever, you probably want to touch it to your needs. And for that, these resolvers here, are very, very handy. It would blow up the whole part of the talk like how to use them properly. But don't be afraid to just have a couple of them here and there, everywhere, that are searching your data and providing it too. You will see eventually how to reuse them, or how to structure them away for you. And there are probably also the great talks you can look at, on how to do that. But, mind that you will eventually need to vibrate these. And there's nothing wrong with it, and it's like not a code so that are needed to implement that and get another revolver. If you are happening to derive the things from JSON that we did here, probably you don't need to do much with others for your leaf fields. So the scaler things you have started and so on. Those are by default resolved by the name of the field. So if you provide the Playtimes GraphQL type, a Playtime object, then it will just work and resolve it. It will take the ID property, if you go to the ID field. And this helps you in the beginning, so you don't need to type them out expressive every time, for every single field, but you can rely like on this default feed resolver, and only care for the juicy parts where you're like you don't go into the database, fetching your things. And this, oops! My , going away when I flipped the things. Sorry, I hope I have not been rushing too much through this. I wasn't actually sure how much time I just took here, I think it was a bit too much probably. And yeah, like shout out here to organize actually, with Prisma, it's a breeze to just use the resolvers. Just writing them is more or less a couple of lines of code every time. And you get the things out of the database. And I'm very looking forward to actually bring that to Prisma. Even though I need to do my own manual mapping, toward database schema, I think that's definitely worth it. And yeah, with that, I will conclude, and thank you for your time, and feel free to like ask the questions now. And the quiz questions are more or less, the things I want you to take away from this. So, I hope you enjoyed it. And that's . - Stephan, thank you so much for that. That was really insightful. And it was really interesting how, I think you provided a strategy for anyone to get started with GraphQL today. With the data that they already have. So thank you for that. I think we had one question come in-- - Sure. - I'll share my screen. Let's see. Oh, bring up my screen. So, this was a question that came from Bruce. It came a bit earlier, but perhaps you want to chime in on that, especially since you said, "Hey, you know what? "You can just start off with just queries. "You don't need to necessarily worry "in the beginning about mutation." So, having used it in a lot of systems, it's definitely great for read heavy APIs. Do you see times where GraphQL shines for mutation operations, compared to REST and RPC? - I think RPC can be quite comparable to GraphQL mutations, because there you also have more expressive-- - What? - Sorry. - No, so on RPC you also have very expressive kind of course you do. Telling it explicitly what kind of action you wanna do. And that is what I would say is comparable to both of them. So I wouldn't really say GraphQL shines there. When it comes to updating data compared to REST, I'm still on a split side. So that's why I'm also probably encouraging people to go with Query first, because it depends on what you're working with and the domain you're working in. For me, I'm usually thinking in terms of Contentful, because I've been there for like four years. So we they're one to just like update an entry, for example. So usually you don't cross many boundaries, between anything where it would justify having a graph. So you don't just like doing the REST put to like update it. It's totally fine, while when you want to consume it, we're very data graph, heavy, Contentful it's like a graph of content, is the content graph really. So you can currently and taps with and get multiple levels of linked things wanting together. But, when you update them you probably don't want to do that. So, to cut it short, I don't think I have good things where GraphQL shines for mutations except for the expressiveness, for the UI developers. Mostly I would say, working against your API, so they can be like very expressive, or you can design very expressive things for them, for like the things, put something to cart, or add a comment to a blog post, or whatever you can come up with in there. This is where it shines, but not necessarily for very generalized kind of update strategy. - Got it. Great, and someone asked about the link for the transformer tool, and I shared the link pf the Transfomertools-- - Oh, thank you very much. - I just discovered it too, and I think it's wonderful-- - Yeah, it helps me so much all day, whenever I need to do something like, I have some data shape here and I want to get it somewhere else. I'm like, "Okay let me first check it transformed tools, "so that I don't need to do it." And otherwise I can still search on, and yeah, that's a good time-saver. - Gotcha, do you want to stay online for the second round of the quiz? - Yeah, sure. Maybe just very quick to this Dgraph query question. - Yeah, -- - I think Dgraph has a GraphQL like kind of thing, to query its data from the database. So I'm not aware that there is any other connectors that making it more spec compliant, but I also have not worked with the Dgraph in bigger scenario. I've literally just set it up once and try to play around. And I thought it would actually be supporting GraphQL, and only supports a superset of it. The types of scrips, JavaScript kind of thing. So if you have more information around that feel free to reach out for more discussion, whoever you are anonymous. I would be curious on like what the actual problem is there. - Oh, great, we have Vignesh who just dropped a comment, and he's like, "Yeah you have a Dgraph GraphQL, "which you can use." So I guess in this case, if you're implementing a GraphQL API that isn't the one that the graph is exposing, you could make GraphQL calls to the Dgraph. - Yes, exactly, but for that you wouldn't need a Dgraph specific thing. Actually, that's also a cool part here. You could use anything that generates your GraphQL, or client in terms of client to communicate with that GraphQL server. So you could use the thing I just showed with like the Prisma, for example, general, prefer probably not but, using something that just takes the GraphQL schema from Dgraph, and exposes it to you, and then you put those calls into the resolvers. Or you think about some kind of schema, federations, stitching, whatever. But, in general, I wouldn't recommend exposing a GraphQL interface of your database directly to the customer. I would rather shield that, even if you do like a request, or two more than you would necessarily need to do, I think it's worth it for not exposing it to the outside world. - Yeah, yeah, absolutely, I agree. Great, So let's get started. Thank you again for this talk, and let's just jump into the quiz. So, you should have the quiz open window. And let's get ready. So, we have 35 participants so far. And now, we come to the first question. So picking your own data set is a good choice when you... First want to dip your toes into GraphQL. Second, want to try out specific language features. And third, present something in a community talk. Okay. Let's see if we can get to 20. Okay, the results are rolling in, and let's count down to 10. So 10, nine, eight, seven, six, five, four, three, two, one. - Not quite the 20. - So most of you pick the best choice. However, and that was the wrong one. And the right one was, if you want to try out specific language features. - Yes, so if you're very new to GraphQL, and like you have never really dipped your toes with it. I don't think it's good, like immediately going with it, go with something like first. Take your data when you know how GraphQL works. If you don't understand how the schema language works, or how the queries are written, I don't think it makes much sense to directly jump into working on that with your own data. Get the GraphQL language straight first, before, I mean, it was like, dip your toes. Maybe that was also a bit misunderstanding, but yeah, once you want to try out actually the language feature in its implementation, go for your own data. - So we come to the second question. What's not a good format for your data to work with? XML, SQL, or JSON? These are tricky questions. They remind me of the driver's license theory questions. - Yeah, I have to be honest, I was doing them very, very late in the preparation phase, and was inspired by weakness questions, because I was struggling to come up with some. So in the end they became maybe a bit too much of a test. - No worries, I'm glad that we have you here live with us so that you can explain. So we've got 18, I think we can stick to that. And most people picked SQL, but that was also the wrong choice and it was XML. And I guess this was slightly confusing because... Oh, let's see. - Yeah, I can see. I mean, it's actually nice. I'm just getting feedback to my talk here, but basically the question answers. The SQL part might be confusing. I guess it was here maybe due to the naming problems that I was showcasing, but, yeah, that was a fall from my side, because I actually wanted to show this it's still very much capable of working with it. And I thought that I was like showing us Hasura and Prisma, quite good that there is good ways on how to use the SQL, to get your data on. - All right, let's move on to the next question. The best route type to start with is: First, mutation because we need to import data into the system to work with. Second is query, so we can visualize our use cases early. And third, mutation, for best library loading style developer experience. - Oh, should actually have been subscription down there. Did I send that wrong, or put it in wrong? I'm sorry, because the third one would be subscription. - Okay-- - For the best library loading style. - So the third would be subscription for best library loading style-- - Yeah. - Developer experience. Okay, so let's see if we can get to 18, give it a couple more seconds. And all right, let's close it. And most people picked query, which was the correct answer. And finally, what should be considered during the first thoughts about the schema? Authentication, HTTP server framework, or third option is, collection pagination. So, a quick reminder that the first prize for the quiz will be a GraphQL or Riley book, and Prisma and Contentful swag. So, let's see if we can get the last votes in. And we'll close it. Most people picked the third option, which was indeed correct, collection pagination. This is our last question for the quiz so get ready, because your speed matters. And perhaps we should show the leaderboard before. So, Mathias is still leading the chart, followed by Bruce and Tobias. Okay, so Hasura, Postgraphile, json-graphql-server, share the problem. First, they can't customized. Second, they require a specific data shape. And third abstracting away the actual schema. - I think I've actually completely forgotten to showcase Post-GraphQL, but that's like literally kind of the same as like has the Hasura thing, just more low-level thing for your own hosting. And yeah, JSON GraphQL so that was to me, actually I think may be GraphQL, so JSON server I talked about it. I think you got it. - All right, let's close this. And the correct answer was abstracting away the actual schema. So they obstruct the way your schema and you sort of just get a GraphQL API. - Yeah, this one here was actually also supposed to be a bit tricky because I think they all do somehow apply like they require a specific data shape. It's like applying to one of them, but not for the others. So yeah, and there are also depending on how you treat it. So yeah, people should be fine if they have selected it. - Okay, so we have a winner, Mathias, you will win the Riley GraphQL book. Please feel free to reach out to Natalia via Twitter, or to me, you got my Twitter handle just below my name. Same thing for Mathias and Bruce, who will also get some Prisma, and the Contentful swag. So, on that note Stephan, I'd like to thank you we're two hours in. So thank you all of you for having joined today, and sorry again for the technical difficulties. Sure, we'll get that resolved by the next meetup. And again, we are looking forward to seeing you again at the next GraphQL Meetup. So, have a good one. - Thanks for having me, see you. - Ciao, ciao.