The power of GraphQL

- [Instructor] GraphQL is considered by many to be the most logical way to build an API that is consumed by both JavaScript applications as well as mobile applications. We should start with the very basics here, and talk about what GraphQL is. First and foremost, GraphQL is an API or an application programming interface. It is designed to serve data when requested to other systems or other parts of the system itself and full stack engineers know all about that. It is also a query language for that API. This allows you to structure queries against the API to get data that matches what you ask for. Most importantly, is that it is a runtime for answering the queries. GraphQL not only is the API and the language to query it, but it also provides a running mechanism to fetch and serve data. Now, one of the coolest aspects of GraphQL is that due to its graph nature and how the query works, you can ask the API for exactly what you want and structure it how you want it and then you will be rewarded with the data, exactly how you need it, whether you traverse the graph or request a single type. So now that we know the basics of the, what it is, let's talk about why you would use GraphQL. One of the biggest advantages for front end developers especially is the concept of a single request. With that single request, you can get the resource, all resources, or a selection of resources. To do this with REST, you would need at least two APIs, most likely many more. In addition to control of which resource you get and how many instances you get, you can filter the payload of the response to only return the fields that you need. With REST, you always get the whole object. So, we can get one or more resources and one or more fields on those resources, but then we get to sub-resources. With REST, we often get an ID on the parent and then call a different API to get the sub-resources, based on those values in the parent object. With GraphQL, we don't need to do that. We can leverage the graph nature and pull back all sub-resources of a parent resource, or a single sub-resource, or just fields within that resource. Now you add that into filtering and we start to get a real picture of what we want, what we can return, and how we do it. Another advantage, especially in the front end world, is that we don't need multiple endpoints configured. In a REST world, we often need base URLs for each service. With GraphQL, we only need the URL of the GraphQL server. Type safety is very important to many developers and GraphQL provides type safety, unlike REST. Now, like it or not, APIs change and non-passive changes causes us to deal with API versioning in REST. With GraphQL, however, versions are a thing of the past. We leveraged schemas and registries to handle different versions, but we still have one instance of our GraphQL server. Now we're going to talk about the how to in this course, specifically for Java developers using Spring, but there are a lot of other implementations, things like Go, JavaScript, and others that you can use to implement GraphQL servers. Again, in this course, we're going to focus on Java and use Spring as our native runtime.