 Hello, everyone. I'm Drishti Jain and I'll be talking about GraphQL in general as well as how we can use it in PHP. To start off to tell you a little about myself, so by education, I'm a computer engineer. I'm a tech speaker and a mentor to a number of students in India. So I flew in from India for the talk today. I'm really excited to be in London. This is my first time here. It's pretty cold, but yeah, the conference makes up for it. I'm also a social entrepreneur. So I established a nonprofit organization back in India. We are working in 10 cities, and I aim to use technology to help the underprivileged children and also a way in which due to lack of resources financially, they're not able to invest their time or learn about technology. So I do that during weekends, along with my regular day job. So let's directly start on to what GraphQL exactly is. So GraphQL is an open source data query and manipulation language for APIs. It provides a complete understandable description of data in the API. So GraphQL is like a query language. Whenever you want to get data from various data sources, it could be from a single data source or from multiple data sources. GraphQL comes very, very handy. We'll be looking into exact features of GraphQL as well. But to give you an overview, it helps you retrieve data exactly the way you want to, and you do not have to put in extra effort to bring data into a particular format that you want. And that is why it gives clients the power to get exactly what they ask from various data sources. GraphQL also makes it easier to evolve APIs over time. So many times we do realize that the requirement, the business requirement of our application might change over time. But we would have to support the existing structure as well as support the new structure that is there. So we have a great way of handling deprecated fields in GraphQL, which makes it very easy to maintain your application over time, even if there are a ton of changes due to some of the other business requirement. And apps using the applications that we build using GraphQL are fast and stable because they control the data that they get and not the servers exactly. So to give you a mental picture as to where does GraphQL sit in the whole application, so it is between the client and the data sources that is there. So whatever the client requests for data that comes in through the GraphQL layer, and so the client and the servers or the data sources that you have interact with each other through the GraphQL layer, it lives between the client and one or more data sources. That is also very important. And these data sources could be in various forms as well. It is not necessary that if you have a MongoDB database, all the sources have to be that. You could have MySQL, MongoDB and anything that is already there as a part of your data storage. You must be wondering, so at runtime, what does GraphQL exactly look like? To make it a little easy to understand, I'll give you an example. So consider there are three people, person one, person two and person three. This is a real-life example. So consider that they speak different languages and have different knowledge. And the aim is to find answer to a question which can be done only when we get inputs from all these three people. So we would have input from person one, person two, person three. But they speak different languages. And they have different sets of knowledge. We need to combine all these three knowledges together in order to find the answer to the question. So how would we do that? Wouldn't it be very easy if we had a translator who knew all three languages? Right? So in a similar way, it's what... So the spring structure could be like a translator who's curating all the knowledge in different languages that the three people speak together. And then answering the question. So that is exactly what GraphQL does. So it interacts with the various data sources that we have, curates it and gives the answer to the query back in the way we want. And it could be from various languages. In our case, it would be computer programming languages from different sources as well. Coming to what the origin of GraphQL was like. So GraphQL was developed in 2012 at Facebook. And it was open sourced in 2015. The reason why GraphQL came into existence was because of the nature of data that Facebook was handling. So we all are using Facebook or have used Facebook. We know that every profile of a user that is there has multiple fields. It could be right from the profile image to the friends that are there, the comments a person makes, anything the person shares, plays. All of that is a huge source of data. But they wanted a way in which they could extract only the information that is necessary to them in the required structure that they want for their output to be like. So there was nothing that existed at that point of time. It was only REST APIs. But that faced the issue of under fetching and over fetching. So because of that, it wasn't very efficient, especially when you're dealing with millions of people and a lot of records per person about each and everything. You have to retrieve, for example, if you just want to retrieve the names of people earlier, if GraphQL wasn't there, they had to do the normal REST API request, get everything and then extract the name out of it. That is unwanted wastage of resource of time. So they wanted to create a solution for something that they were facing on a regular basis. So that is how GraphQL came into existence. And later on, they open sourced it in 2015, which makes it pretty cool that all of us can use it freely now. It's open source. A lot of you must be wondering, so exactly where do I picture GraphQL versus REST in my head? So REST follows a resource-oriented model. So if we have data of players, coaches, and teams for any game, so in case of REST, our endpoints would look something like this. We would have players, if we have IDs assigned to the players, we would have the endpoints like these. But in a dynamic environment, this faces a lot of issues. The two major ones being underfetching and overfetching. So underfetching in the sense that you get, if we have IDs of the players, and we also have, for example, the hometown of players, but if we just go to the endpoint of slash ID, we would just get ID. So that would be underfetching of data. And overfetching would be if we are fetching everything about each and every player, but we only wanted the ID or the name. So that leads to overfetching. So both of these problems were two major problems that were happening whenever we worked with REST APIs. So this is a problem that both these problems are hard, and there had to be some other solution that we could go about in order to solve both these problems. So underfetching led to a lot of extra amount of queries that we had to fire back to the database to get the information that we needed, and for every time that we needed it. So we needed a better solution than REST APIs. I'm not saying that there's no solution in REST. There is. It is to create a lot of bespoke endpoints. So for each and every kind of information that you anticipate you might encounter in future, you would have to create separate endpoints for each of them. But that solution is not scalable, especially with time. Once you have new business requirements coming in, you'll have to create more and more endpoints. That would just keep on making it very difficult for an application to scale up, and moreover, to maintain it and keeping it consistent with the current data that we have. So all of these problems were solved once GraphQL came into picture. GraphQL made all developers very happy because of the primary way in which GraphQL works, of retrieving data the way we wanted. So a diagrammatic representation of what data fetching through REST APIs and GraphQL API looks like. So if we have posts, comments, and authors, in REST, we would directly have to go to each and every endpoint. But in GraphQL, we would be interacting with the middle layer of the GraphQL and then getting the data that we need. A few of the design principles of GraphQL. The first one is that it is hierarchical. The fields in the queries are nested within them. So the way you want to maintain your hierarchy of getting fields back, you can easily do that in GraphQL because it is very hierarchical. It is product-centric. That is, it is driven by data needs of the client and not the way we want it as a developer. So the query that a client would be firing and the person would be getting the data back exactly the way he or she wants it to be. Also, it is strongly typed. We'll be looking into type and field system that is there in GraphQL, which makes it strongly typed in the sense that the way you have defined your schema and the way you want to retrieve it back using types and fields makes it easy even on our coding part. And there are client-specific queries because the client is able to control what information he or she wants and not be a victim of over-fetching or under-fetching. Also, it is very introspective. It is able to query the GraphQL server's type system. A few of the features of GraphQL. So GraphQL queries access not just the properties of one resource, but also smoothly follow references between them. Oh, sorry. So we can retrieve multiple resources in a single request. Whatever are the fields that we require, we can pass them together at one point and get them back. We do not have to send in multiple requests again and again to get the required information that we want. And apps using GraphQL can also be pretty fast on slow mobile network connections. That is the reason, because we are fetching multiple resources in a single request and we are not sending in multiple requests for multiple resources. It has a declarative data fetching, so you query and get exactly what you need. If you just want the name, so you just request for name. If you want the name and the height as well, then you would request both of them. So depending on what you need, you would request only that specific field. You get nothing more, nothing less. And GraphQL queries always return predictable results. So if you have queried only for name, you know what to expect back. If you have queried for multiple fields, you know that you will be receiving multiple fields back. So that makes it very, very easy to understand of the data you would be receiving back. Apps using GraphQL are pretty fast because they control the data that they get and not the server. So it is all data centric and the way you are requesting, you get the result back in the same structure. And it is organized into types and fields. So here you can see that we have the type of the query that we are requesting and various fields in that. So that gives a distinction to the huge amount of data and the various attributes of data that we have. It accesses the full capabilities of your data from a single endpoint as well. So it also handles deprecated fields very well. Here you can see that we are adding new and new fields to our data. And also we are removing some of the fields. So using at the rate deprecated, we'll be able to tell GraphQL that this is something that is not supported in the present and the future, but was already there. So that way, if you have queries built on the system that was there about, say, five years ago, you do not have to change the complete code for that just because your fields have changed. Because otherwise it will be very difficult. You'll have to recreate everything from scratch even for a simple modification that comes in. So handling deprecated fields and enabling a single evolving version is the most important capability which attracts a lot of developers to use GraphQL instead of REST. Because it's very easy and it is also easy to communicate to somebody else, a fellow developer who's also working on the project. He or she would directly see at the rate deprecated and understand, okay, this field was there earlier. It is not there right now, but we need to have a support for that field because it might be used in some call in our program somewhere. So instead of just deleting it, we mention it by deprecated. And this also helps us give a continuous access to new features of our application that we might be interested in to go ahead and build on. Talking about the GraphQL type system. So the GraphQL type system model consists of two things, that is types and attributes. So each attribute has a type and a type could be any four, could be one of any four of these. It could be ID, Boolean string or a user-defined data type. It completely depends on you as to what, depending on the data that you're handling, if it is a string type, a Boolean type or numerical in nature, or some self-user-defined kind of data, you can have that as well. And so since it is GraphQL, we are structuring our data into a graph form. So taking the example of, say, Facebook, the reason why GraphQL came into existence. So the complete data could be organized visually in the form of a graph. So a graph would have nodes and edges. So the nodes are the user-defined types, and the edges are the attributes that have user-defined types. For example, if we have to find a relation between a player and team, so a simple graph would look something like this, where a player is associated to a team through an edge. So all of the data that we are working with in GraphQL would be structured like a graph on paper, because there has to be some relation between each and every attribute with a parent attribute or a child attribute, since it is very hierarchical as well. So you would have subfields inside a major field. A few of the important concepts. So I would be showing in some code snippets as well now, which would give you an idea as to how do you exactly go about starting off with GraphQL. So the first one is query. So the example I'll be following in my presentation would be of... You can imagine the data to be of a data of countries, and each country would have a name associated with the continent the country is present in, and later on, for some features, we'll also have monuments present in the country. So a simple query for fields on objects would be something like this. We use the word query, and then inside braces, we write the country, and the country would have name and continent. So this makes it very evident that it is pretty hierarchical in structure. Whenever you have to query something, you would write it something like this. It is very easy to understand if you've worked with JSON and all as well. It's very straightforward. You don't have to learn a completely different new syntax or a way of writing it. The query and the response have the same shape. So if I'm firing this query of country with the name and the continent, the result that I would get back would be the country name and the continent together in pairs, since I'm querying it that way. So you do not have to worry if you would also get monuments even though you do not want that. If you just want a list of the names of countries and the continent it is in, you would just get that because the query that you're firing only includes those two fields. So we're talking about fields. So field is like continent here. Fields can be of scalar type, or it could have some subfields as well. So for example, if we have monument as a field, monument could have a name as well. So this is a non-scalar kind of a field that we are firing in the query itself. And having objects as fields avoids making multiple requests for related resources. So if you want, in a general case, otherwise you would get the list of countries together and then for every name you would fire a query to get the monuments in that country. So instead of doing it in two steps, you can directly combine it and do it directly so that you are not querying again and again for resources which are related, like fields which are related. For example, the monument is related to the country. So you can directly query it at this same moment as well. So arguments, if there is an ability to pass arguments in the fields, so for example, if you want to get information about a particular country, so you can pass it as an argument just like you would do in any other language, simply the attribute name colon and the value of the attribute that you want to look into. So in rest, you can pass a single set of arguments. But in GraphQL, every nested field can also have arguments being passed. So that makes it very, very efficient and a major advantage of GraphQL over rest. That GraphQL having this feature makes it a complete replacement for making multiple API fetches. So for example, here, you can see that we can have the argument to be passed as the name as well as if we are talking about the height of the monument, we can pass in an argument there as well. Here also an interesting thing that I'm doing is that if the height is, say, in meters, but you want it in, say, foot. So in a normal case, you would do that conversion either at the client side or at the server side depending on your application, but you can skip that and directly do it here itself. So small data manipulations like conversion between units can directly be done in the query that you are sending in. So you can pass arguments into the scalar fields and convert it here itself. There are a lot of new libraries as well being built by others, and they are submitting it as well, which help us to do more things like these. You can also write in your part to it. Otherwise, basic conversion units can directly be done here. You must be wondering all of the examples that we saw were dealing with static data that we are typing in and getting the query for that. So how do you work with dynamic arguments? How do you add in variables to it so that it becomes extensively used in most of our applications? So in that case, there are just three things that we do. So we replace the static value in the query, and we declare the variable name as one of the variables accepted by the query and pass the variable name and the values in a separate JSON along with the query. So it would look something like this. So for example, if we are searching a country, so instead of having a name already defined, we can have name as a variable, and then below you can see that in a separate JSON kind of format, we can pass in the list of possible variable values that can be there. Schema is the way... The GraphQL schema language is the way we store data on our server side. So we have to define some structure, some schema, so that it defines the way in which our total data would be structured and stored in that way at our server side. So here you can see that we have name, a continent, and along with that, the type. So the name has to be a string. The exclamation mark shows that it is a non-nullible kind of a field. So the name cannot ever be empty. And monuments having square braces shows that it is a list of objects because a country would have more than one monument considering that assumption. Also it is possible to write comments. I'm not sure if it's very visible. It is hash followed by whatever is the comment that you want to write. So it is not a very fancy new syntax for writing comments. It's the regular... You just write hash before the line that you want to comment, and you can comment it as well. So the advantage that having comments in your query as well, it helps with documentation as well. If you are writing a part of it and you have to pass it on to somebody else, how do they understand what exactly is your query trying to do or what was your thought process in order to go about from start to end for that particular query? So you can do that using comments right in the query that would help you in the documentation purpose of your GraphQL queries. One of the most important type that we have to take into consideration are the root types. So GraphQL queries begin from root types. There are two major root types that I'll be going into, the query and mutation. We could have a query for country name and size of the country that we want to retrieve. So it is analogous to the GET request. So whenever you are fetching data from your database or multiple data sources, you would write your query along with the keyword called query. It is optional along with the query name as well as optional. But if you have to reuse a query, so it will be very difficult if you do not have a name or an identifier attached to that query. So you can do that. By convention, query is used, the word query is used to define a GET kind of a request whenever you are fetching data. And whenever if you are adding data, if you're adding some data to your data sources again, so like a put kind of a request, we use the word mutation. That is to modify the server side data. So technically a query as well could be used to write data back to the data sources, but just by convention so that everybody understands what the query is trying to do, we use mutations for put kind of requests and query for get kind of requests. So these were the basics of the things that you need to know in GraphQL. And so we would look at the client side GraphQL as well as the server side GraphQL. So the client side GraphQL are the queries to fetch data from GraphQL server with schema. So for example, the queries from JavaScript, these are made via HTTP request to single endpoints. So on your client side, you would obviously want to retrieve data from your data sources. So you would have query. You can either go ahead and code each and everything that you want on your client side for the GraphQL, but also to support you in your development process, you could use some of the libraries that are there. So there are many GraphQL libraries based on whichever language you're working. Also the knowledge of GraphQL would be useful for you even if you at some point migrate to some other language. If along with PHP, you have some other side project that you are working in some other language, the knowledge of GraphQL would directly be applied there because it does not depend upon the basic language that you are using it in. So a few of the client side GraphQL libraries that are there are Apollo, client, Relay, Loka, Nano GQL, GQL and many, many more. So talking about Apollo, so this is the official website of the project. You can go through the documentation. This is for the client side GraphQL library. So Apollo is a complete state management library and why people prefer this over some or the other library because it has declarative data fetching. It completely removes the part wherein you have to manually track the loading states whenever you are receiving the data back. So depending on your choice, the way your application requires some of the other fields on the client side, you could choose between many of them, many of the libraries that are there. This is about Apollo. Another interesting one is Loka. This is the official GitHub page for the project being maintained. So Loka is a single JavaScript GraphQL client that works in all JavaScript environments. You can directly see that there's a HTTP transport being called and the query that is the country name and size is there and then you have your response back onto your console. So if you read about it, it might seem overwhelming just because we know that GraphQL is the buzzword around, but seeing the code snippet, you must have realized that it is not complex at all. If you just give GraphQL a little time, you'll be able to see that it is pretty easy to understand and to use it in your day-to-day development as well. So coming to the server side GraphQL, so server side GraphQL is implementing the schema in order to return the data requested by the client. This is very, very important because getting data from your server is being done at the client side, but you need a way to define your GraphQL server. So how do you do that? There are a few libraries. Some of them are even PHP centric, so Cyler, GraphQL PHP, GraphQL Relay PHP. These are the three most popular libraries that are used for GraphQL and PHP server. So talking about Cyler, this is the official website for Cyler. You can go ahead, read more about Cyler and see if it is the library that fits your project or not. So the functionality that Cyler provides over other libraries is the WebSocket subscription service that is exactly based on what Apollo does. So many people use this as a combination as well. So Cyler for the server side and Apollo for the client side because the interaction makes it very easy. So a code snippet of what a hello world program in Cyler would look like, a normal hello world program. So in the top, you can see the schema that we have defined for the query type, which just has a feel as hello. And then we have our PHP script where there are a lot of... In the Cyler library, there are a lot of things already defined. So in your code, you can directly use that. Also, you can see that the resolver has the query in the way that GraphQL works. And also, Cyler enables you to handle errors if they happen at runtime. So the last part, if you see of the code, you'll see that what to do if you get an error. So you can do that as well. Another interesting server side library that is there is GraphQL PHP. This is the official GitHub page. So it is the PHP port of GraphQL reference implementation. And the major advantage is that it provides type introspection. So if you want that as well in your application, you might prefer this over other. So we have looked into various libraries which would help you in creating the server using GraphQL at your server side. So how do you exactly, if you want to create a GraphQL server in PHP, what are the major things that you would want to know? So at first, just like this picture, it might seem very complex. It's beautiful at the end. It's pretty cool, but it has so many components. How do you exactly go ahead and try and create a GraphQL server in PHP on your own? So let's look at how do you accomplish this task. So the first thing you want to know whenever you're creating your own server is that how do you handle the queries which are being fired from your client side? So queries are made via HTTP requests to a single endpoint. So you have to have a way to handle all of the queries that you have. So the most important part is this. The GraphQL double-colon execute query. It parses, validates, and executes the query. So this is one important thing which makes your server to be a GraphQL server in PHP. Then you have to write in resolvers. So resolvers, if you practice a little bit, it becomes very easy. Otherwise resolvers is the place wherein you might get stuck when you're first starting out. So don't worry, most of the people get stuck, but if you just go through it once, once or twice if you try coding it, it'll become very easy. So resolvers tells how to get the data for the particular field that you've requested in your query. So this could be anything and everything that you want. So in the example that I've been following since the start of my presentation, for countries, names, monuments, that example, so in that case, a resolver would look something like this, wherein for each of the field, say if you have in your query, you have the field called country. So your countries would have the type and how do you resolve it? So you would have the function which would retrieve the data back. So you need to define resolvers in order to handle queries at your server side. And the resolve function can be implemented how you want to get the data back. So it could be SQL queries, cache, or any other API. For scalers, the return value will be the field of the value. And for object types, the return value would be passed on to the nested fields. So if you are querying for monuments as well, then the name and the height of the monument, the return type would depend on those return types since it is a non-scaler kind of a field. So the slash symbol got replaced here. Otherwise, it is GraphQL slash type, slash definition, slash object type. That is just a conversion, the cable conversion thing, I guess. But to let you know, you need to have an entry point into your API. So how would you do that? So if you see the code for resolvers and that for entry point, you'll see that the resolver code is there as it is. And we have a statement at the top called use GraphQL slash type slash definition slash object type. So you need to have, you have to define this for the entry point into your API. You could have another one as well for object and define it there as well for the query type. And each field has a type and a resolve method for getting the data. And there are custom object types. So since we are talking about user defined data types in GraphQL, but how do you actually handle custom object types? So if you want to give in a condition for it being not null, so where do you exactly give that on your server? So under the config, after type, you can define if it has, if it is okay being null or not, or it is a mandatory field. And that way you will be able to exactly define the data that you will be retrieving back. And also in case there is some error which needs to be, shown to the user if a field was required and is not filled by them, so how do you do that? You need a way to define if the field would be null, not null, or some other condition that you want to emphasize. So these are the four main things, the only four things that you need to know in order to create your own server. So that is custom object types, the entry point to API, the resolvers, and how do you handle queries? So looking at the code snippets, you would have realized that it is very, very simple for you to use GraphQL to build your own PHP server. So yeah, that is how our server gets built. So just like the Rangoli here, we have learned how do we create a complex, a thing which looks complex to us, but if broken down, if we use the divide and conquer strategy, we are just breaking down our difficult task into small parts, into the four main things, and yeah, that is how our server gets built. A few tools that are there where you can start off, especially if you are new to GraphQL, just to get that speed on how do you do that. So there are a lot of tools like GraphiQL, LibGraphQL, Parcer, GraphQL language service, and QuickType. The one that I prefer the most, the one that I used when I was starting off with GraphQL, was the first one that is GraphiQL. So it is the major benefit that it has. I'll go more into it. So this is the official GitHub page for GraphiQL, and the major advantage that GraphiQL has that, it is a graphical interactive in-browser GraphQL IDE. So you do not have to install anything on your machine. If you just have a browser and an internet connection, that's it. That's all that you need to try out GraphQL on your own. And another important benefit is that it has automatically generated documentation. So for each and every query structure, the schema of the query that you'll be defining, you would want to document what does it exactly mean. It automatically creates that. You can also edit it. So you are building your GraphQL queries as well as doing the documentation for it at the same time. This is a screenshot of what GraphiQL looks like. So you can just search for GraphiQL on Google or go to this official website and you'll find a link to access it. There are a lot of free and open source simple projects that you can query on and find out how do you work with GraphiQL. So if you like Star Wars, so there's a Star Wars API that you can work with GraphiQL. If you want to find out more about songs, so Spotify has open source, their GraphiQL link. So you can directly go there, search query, and you'll get to know how do you exactly work with GraphQL. Or if you're a fan of Pokemon, somebody has also built one for that. There are a ton of open source and freely available GraphQL APIs that you can go just to get to know how do you work with GraphQL. So the GraphiQL console looks something like this. It is divided into three parts. The rightmost part that you see is the documentation that is there. So each of the fields and the type of the field that is there is mentioned there. Also if you want to add in something on your own, you can do that. Here you see on the leftmost, this is how you write your query. So there is a variable called ID here being used. It also has a smart interface. As soon as you press control space, you would see a dropdown of the way the data is structured. So that makes it very intuitive and easy for somebody who's starting off with GraphQL to understand how do you exactly work with it. Also in the bottom you'll see that if you have selected name, so you'll see the data type, that is string, because it could be different for different things like height, mass, it could be something else. So how do you get that? And then as soon as you run it, so you get the output in the middle part of your screen. So you can pretty much see that the way you're querying it, you get the result back the way it is. So no over-fetching, no under-fetching, getting exactly what you need, and that is what makes GraphQL very, very efficient. So the references and attributes of my presentation, graphql.org is the official website for the GraphQL project. There are a lot of... There's a good amount of documentation as well as if you want to explore more or finances to something that you're working on, you can post it there on the community forum as well. And the second reference is the book that I actually used when I was starting off with GraphQL. It is a good book if you like to read things through book and learn and then explore it online. So that is a book that I used. And yeah, that's it from my side. Thank you.