Building Modern APIs with GraphQL

hello everyone can you hear me soundcheck okay everyone please scoot in toward the middle more folks are filtering in and their seats up here please make some room for everyone all right good afternoon I'm Robert with AWS I'm gonna talk to you about graph QL graph QL is an open source declarative API query language that was created at Facebook has now used at other companies such as Amazon Microsoft New York Times Twitter and Virgin Trains before I dive in let me introduce myself I'm a principal Technical Evangelist with AWS I joined AWS last year prior to that I was a software engineer at Facebook where I worked on the graph QL team and contributed to the graph Gale specification and before that I was a software engineer at Microsoft where I worked on the.net framework Xbox windows server and the startup business group I'm proud to announce that last year I published my first book check it out but don't buy it or read it I prepared a demo for you that we're gonna follow along with if the Wi-Fi network is helping out we can go to this URL and your phone or your laptop and follow along can everybody see this okay in the back show hands yeah okay good all right for this demo we're going to do a very simple exercise we're going to fetch the names of all the Star Wars characters that appeared in movies with Luke Skywalker now of course we need some api's to do this and the links that we have up here this first one is the Star Wars rest API it is at swap eco let me zoom in a bit and this API has a bunch of Star Wars data such as characters films planets starships and what-have-you and it's frequently used as an exemplary REST API that is an API that specifically abides by the uniform interface constraint in plain English that means that this resource references other resources by means of these hyper media links for example the home world is designated by this URL for the home world field instead of an embedded JSON sub structure but let me make a note of this rest architectural style for a moment this field I don't actually know what the shape and the structure of this home world field is maybe it has a property called name that'll tell me the name of the home world that Lucas from maybe it has a property called mass maybe it has a location for where the planet is in the galaxy I just don't know but I do know that I can copy this URL and I can paste it into the browser over here and then I get the resource that represents planets slash one which we can see is the planet that Luke lives on or lived on and I can see that it also has a bunch of other related resources it follows this exact same pattern and has these other hypermedia links to express this resources relations to other resources such as residents on the planet and films that the planet appears in now with this knowledge of the Star Wars REST API let's revisit our requirement fetch the names of all the Star Wars characters that appeared in movies with Luke Skywalker well this is the great thing about REST API so as as human beings we kind of we're so used to navigating websites that we kind of know how to do this right we can just go in here and look at all these films we can say well I could perform an HTTP request against every one of these films for example let's take the first one and we're gonna paste it into the browser and we say ok well this film has a bunch of characters this one represents Empire Strikes Back it has all these characters in this array here and I can just click on each one of these and get the name out of the related resource for each character simple enough right well let me point out another thing in the process of fetching this film resource there's a lot of data that I didn't actually use all I needed was this characters array but in fact when I performed this HTTP GET against film / - I have all this extra data check out this opening crawl text field this is the text that Scrolls up when the movie starts I'm not using that data at all but it came with the resource nonetheless so we're gonna see why all this stuff starts to matter when I run the demo and so in here I'm just going to open up the network inspector and when I click fetch with rest let me show you the code briefly it's going to run this function right here I'm not going to go through all of it but this run rest function we've hard-coded the URL for Luke Skywalker and then we do exactly what I just described we're making these HCP calls to fetch the Luke Skywalker resource we take the characters array and then we fetch all of those resources and then when when we have all those we massage the data a little bit and then we put it into the names field which is an invisible field right now because we haven't run the the demo yet now I'm gonna switch over the network tab and I want you to pay attention what happens in the network tab when I click fetch with rest okay so it looks like we made about a hundred Network requests in order to fetch the names of all the characters that appeared in movies with Luke Skywalker and collectively it took little over three seconds okay that's a REST API we all know what that is what about graph QL this is a talk about graph QL so the second link takes us to the graph QL API of course would be nice if it were running let me fix that and let me bump it up everybody see this in the back in the back ok some hands ok thank you so this API is the exact same data that we saw in the Star Wars REST API but I've rebuilt it as a graph QL endpoint and what we're looking at here in the browser is called graphical graphical is the graph QL IDE using graphical on the left hand pane here we can offer a graphic ql document we send it to the server the server executes it and then sends us back JSON in the right hand side here so what can we write in terms of the graph QL document to know that we can click this schema button and that'll tell me all the types that are supported on this API particularly if I wanted to do what we did with the Star Wars API I can click this film's field but the difference is that before I ever perform an HTTP GET request against a URL I can preview this type I can see that film has a bunch of scalar fields in the form of title episode ID opening crawl etc but where before we had hyper media links for the character field we now have a graph QL relation and this relation allows us to click through the characters and see that if I were to fetch the characters field on the film I get an array of objects of type person and each person has these scalar fields name height masts hair color and then it itself has a whole bunch of other relations so using this we can see that this is a way to explore the graph of data that I have here now that I know what the schema is I can go in here and write my query I'm going to specify that I want to execute a query which is the only operation type that this API supports right now I want to fetch films and then for each film I want to fetch the title so there we have all the movies that are in this particular set of data and I've just specs only the title if I just want the title for the movies I see that this particular API has it is not up to date with the last Jedi good taste I choose to ignore that movie as well and I said that we can fetch characters in line right here so for each character in the film I can come in here and say name and now I don't know the formatting is a little bit off I mean let me blow this up here and now we can see that we've only fetched the names of the characters for all the films and I don't have any of that extra data that I didn't use going back to the demo this means that if I fetch with graph QL let me show you the code briefly this is the graph GL request notice that I still have to do some massaging of the data after it gets to the client but none of these calls are asynchronous none of these calls are Network requests the only network requests is fetch graph QL up here and this query looks a lot like what we just offered in the Korea Explorer so if I click fetch graph QL I can see that the same data came back except it's much faster less than half a second about 6 times faster than the rest API call why because it's only one Network call just to prove that that is actually happening let me refresh this get a clean Network tab I'll run this again so you can see that there's just two network calls one is for the HTTP options call for cores and then the second one is the one that actually returned the exact data that I asked for and we'll talk more about this later but this is one of the super powers of rest or graph QL because you can get exactly the data that you asked for and nothing more nothing less okay let me break down what we just saw we authored a graphical document in graphical we sent it to the server the server validated and then executed that document and then it's sent back the response as a JSON document but there were some rules when we were writing that that document we said hey it starts with the operation type and then it's followed by that pair of curly braces and then within the curly braces we wrote some other text write the curly braces in the operation type those are all part of the language specification for graph QL you can think of it as a little bit like sequel without even knowing the schema of the tables you're working with you can roughly tell whether or not a query is valid sequel syntax so it is with graph QL next we had the selections which were was when we fetched the people and the films and the characters and all the different fields we wanted out of those types and that's schema specific that's domain specific that only works because the schema for the graph QL API for Star Wars had those specific types with those specific field definitions and finally there's a server that answered that query there's this process running somewhere it takes this document as input it parses it and it validates it and it assembles the response after it gets the results from fulfilling the different fields it's also instructive to talk about what graph QL is not despite the QL in a name it's not a graph database query language it's also not a solution for client-side state management and this is tempting because when you see this object come back in the exact form that you want maybe you want to just use it directly and get rid of any sort of client-side caching layer but that's generally a mistake there's more work to be done after the data reaches the client such as D normalization and caching and cross referencing so graph kill doesn't solve any of those problems for you it's not a solution for binary streams we saw that all the data that was coming back was text and it was expressible in a JSON document and that's exactly what graph QL is used for it's not going to be a good solution if you are using it for large file transfers if you're using it to stream audio or video it's not what it's built for and it's also frequently confused with the Facebook Graph API they're not the same thing the Facebook Graph API is Facebook's REST API for third-party developers it's not limited to any specific databases or it doesn't have to use the base a database at all all the fields in the graphical schema are optionally backed by what are called resolver functions the resolver functions are just regular functions in whatever language you choose to write which means that you can return data that is generated on the fly data that is right out of a cache data pulled from a flat file or of course data read from a database it's not exclusive to the JavaScript ecosystem there are implementations of graph QL in every popular language and on the front end you don't have to use some sort of web technology react relay it's a great solution for these kinds of technologies but it's just as applicable if you're building native applications for iOS and Android or even just writing bash scripts or command line utilities and lastly at the transport level it's not restricted to HTTP you frequently see graph QL used with HTTP but that's because of the ubiquitous ubiquity of HTTP in fact if you want to use the graph QL subscription operation HTTP isn't even sufficient so you can use whatever transport you'd like as long as it supports request response style semantics and guaranteed in order delivery semantics of TCP so we saw some operations I talked about operations briefly and we saw the query operation in practice and the query operation roughly models a read this is an operation where you are not changing the state of the server by executing it so you can run this as many times as you want then you have an operation called the mutation and the mutation is used to roughly model writes and it's called a mutation because conceptually it should mutate the state on the server and lastly we have the subscription the subscription operation creates a persistent connection between the client and the server and then whenever the underlying domain-specific event triggers the selection set is react Secutor and the data is pushed back down to the client and using the subscription operation you can build all sorts of interesting real-time use cases like chat applications or transportation or communication applications you name it but I want to mention one other thing these operations have especially the query and the mutation operations are only here for semantic purposes that means that you can go and create a mutation that doesn't actually change any data and you can also create a query that actually goes and deletes a bunch of rows from the database it would not be intuitive and it would probably really be really confusing to whoever's using the API but you can do that just like you can mess with the HTTP verbs get put post delete right so let's put the query under a microscope this query document what we're looking at here is a query document and this contains valid graph QL text within the first word here is special this is the operation type following the operation type we have an optional operation name the operation name is an alphanumeric string specified by the client and this string is helpful if you're trying to trace or debug this request on the server next within these parentheses we have the input variables and at the very top the query name defines all of the input variables that the subsequent selections will use in this case the lowercase ID is the variable name and the uppercase ID is the type ID is a graphical primitive type and the the bank means that this is not an optional variable it must be supplied or else the graph Gale server does not need to evaluate any further and then you can see that we actually use the ID in the author field right inside the selection and by doing this we can make this entire query reusable we can pass in whatever ID for the author that we want to fetch and then we will fetch the field specified here for the author with the matching ID this highlighted section is the selection set for the entire document and this specifies the structure of the JSON blob that's going to be returned to us when the graphical success' graphical server successfully fulfills our request author here is the route field think of this as the entry point into the graph of data you need to start accessing the graph somewhere and this is the field that you use to enter it and then here we have a selection set on a nested field for books or saying for all books fetched title and ISBN and this is instructive because the graphical query the fields must terminate in what are called scalar fields these are strings bools int enums you can't just say I want books because it doesn't know what fields from books to fetch and it would not result in a legal graph qaul query so at this point you're probably wondering what we've seen what graph QL is like from the clients perspective what does it like to build a graph QL server and I'm going to show you the code for the graphical server that we were just using the starwars graph QL server can everybody see that in the back ends okay I'm gonna keep going this graph QL server is built with a ecosystem project called Apollo server which is one of the most popular graph kill servers oh sorry should have okay now can everybody see that in back okay thank you so this server what we're doing here is pretty simple this entry point server TS is just instantiating an instance of the Apollo server and we're passing it a schema and as we saw earlier this schema really defines everything that this graphical server is capable of so let me just click through to the schema how did we build the schema well not that helpful wait we have this handy build schema function but I passed in a bunch of resolvers and these are the resolvers that fulfill the data for all the different types for the film's resolver and go back here and show you the film's resolver runs whenever I try to access this root field films how was that defined in the code this is what it's doing it's saying under the query I'm going to return a collection of films and where do I get those films it's just from a flat file right now okay and knowing that I can come in here and I can start creating other fields as you see here I wanted to share a little greeting with everyone but we can change this thing and we can add any field we want I can create something called foo and then I save this I have a hot reloading feature running here so it'll recompile the server and restart it anytime it detects a change and now if everything worked accordingly then I should be able to go back to graphical and I should see this field show up so I click on you to the schema I can see my foo field has shown up it says that it returns a type string so I can come in here and do something like that and that's it pretty simple and these resolvers so for example in the schema when we compose these resolvers this is where we can kind of leave out entire resolvers for hole types let me resume in the slides okay I also wanted to mention that that particular example was built with a project called type graph QL and it was using typescript and as I said before graph QL is available in just about every popular language so if your Java developer your.net developer you if you are a Python developer there are graphical servers available in all those languages and they're very well tested and they're run at massive scales okay a bit of history how did we get here well in 2012 we built graph QL internally at Facebook for the data fetching needs of our native mobile applications and this was this was back before we open source graph QL so we iterated on the internal version of graph QL for a couple years and in 2015 we open sourced it by creating the specification as a separate project and then in 2018 just last year we announced the formation of the graphical foundation which is organized under the CNC F and the graphical foundation is a neutral governing body that will ensure that graph QL can evolve in a healthy way without any undue vendor influence for the years to come and graph QL is proven at massive scale specifically have Facebook with over 2 billion monthly active users we were seeing collectively over a trillion graphical queries per day and now we see similar scales at Amazon and github and Coursera Yelp New York Times all these other big companies that are starting to use graphic you all but there are a lot of other api's we talked a little bit about rest but there are so many others so gr PC thrift json-ld and we'd be here for a long time if we were to compare graph QL to all of these other API solutions so I'm going to compare to rest because rest is generally the the API technology style that the most number of people understands because it's the technology of the web and so I'm going to do a comparison between these two but instead of treating this as a scorecard where we tally up the score at the end and then we just choose one and nor the other one forever these are all going to be couched as trade-offs in some cases rest is going to be better in some cases graph QL is going to be better but before before I dive in here let me see a show of hands how many people here know what a REST API is okay keep your keep your hands up keep your hand up only if you think you're gonna agree with everybody else what a REST API is okay a lot of hands went down a couple hands this is awesome I want to talk to you afterward so a lot of hands went down and that's because rest has no shared definition in fact the origin of rest is that dr. Roy fielding created this dissertation where he described the architectural patterns of the web back in 2000 so it was kind of a what do people build what were the successful patterns and then let me give those things names and as a result it shouldn't surprise us that there is no shared definition the closest thing you get to the rest definition is the dissertation which contains six architectural constraints I'm not going to go into all of those but you can go and find online is everywhere but graph QL is different graph QL is not up for debate it's not up for interpretation there's a specification and an implementation so if I tell you have a graph kill server there's a very good chance you can figure out how to use it without ever talking to me again they also differ in terms of the conceptual organizing model at the heart of rest you have the resource which is identified by the URI and the resource roughly translates and you can think of it as a virtual file that lives on the server but with graph QL the conceptual model is the graph that is a collection of nodes and edges that relate those notes and then on each node there are scaler properties rest in graphical also different in terms of the organizing organizing model and here I say that rest is federated what I mean here is it's trivial to have rest resources link between different domains for example on a Wikipedia article I can have a URI that references something from IMDB which references something from a Facebook post which substance is something from CNN that's what makes the web so great in graph QL because there's no standard addressing model for any particular node graph QL is centralized and it's difficult to go and create a schema that spans the entire way I would just say that that's almost impossible so these differences matter a lot when you start to talk about whether you're building an API for a first party developer that is a developer that works within your company or a developer that works outside of your organization graph QL rest also has this concept called related operations on resources it's part of the uniform interface constraint and what this says is that if you're looking at a given resource let's say it's an appointment there are hyper media links that allow you to operate on that resource so for example you can change the time and date of that appointment with that embedded hyper media link you can cancel the appointment or you can move around usually all the operations that can affect that resource that are advertised right there but graph Gale doesn't have a similar concept if you're looking at a particular node there's no way to say give me all the queries and all mutations and all the subscriptions that will tell me whenever this object changes for example the closest thing graph Gale has to that is something called introspection an introspection is a special query that you can execute against the graph QL endpoint that can dump out the contents of the entire schema and the introspection query is exactly how graphical the tool that we were using earlier was built that tool goes and executes an introspection query and then it uses the data that comes back to populate that schema button and with all the types and the relations between those types for rest there's no there's no there's no similar thing at least not in any sort of standardized way that I've seen because what you're essentially asking rest is give me an index of all the different resources and their fields and the types of all of those fields the only way that rest supports this is if you add in additional frameworks like swagger on top of it and that brings us a data typing with rest for the example that we saw earlier before I fetched the resource representing the planet I didn't know what fields are on that resource and I didn't know what the types are I don't know what fields are numbers whether their floats whether they're in sweather there's strings but graph Gale tells you that in advance with the introspection query so that schema also acts as this type system that spans between the client and the server and this data typing will be come in handy later and there's also no support for real-time or at least no true real-time support I would say because this is specifically because of the of the rest constraint known as the statelessness constraint and the statelessness constraint makes it difficult for the client in the server to remember what transpired in their conversation up until now so it's difficult for the server to say well let me push this new payload because I couldn't keep track of all the other ones whereas in graph QL graph no subscriptions are stateful graph Gale doesn't have anything like the statelessness constraint so it supports real-time operations via subscriptions well the trade-off here is of course that once you have a stateful system that adds challenges when you try to scale it now there are a lot of challenges that face modern API a modern API design efficiency predictability security documentation versioning and on and on and on and I'm gonna pick out a couple of these and talk about how graph QL addresses them or chooses explicitly to not address them the first is efficiency and that's what the entire demo was trying to show at the start of the talk for efficiency there are two common problems with api's the first is called over fetching and this is where the request contains the data that you asked for but it also contains a bunch of other data for example like that opening crawl text that was included in the film document we didn't need that to fulfill our requirement but the data came along nonetheless the second problem is under fetching and under fetching is when the response does not contain enough data and this is exactly what happens when the document that you request contains a hyper media link if you need to follow that hyper media link through there is no recourse but to make another Network request and under fetching gets worse the better you get at implementing the rest constraint node known as hey Dios which stands for hyper media as the engine of application states this is the thing this is the part of the uniform in America's face constraint that makes documents reference to one another via hyper media links the more you have of those the more subsequent network requests are necessary that's why it took about a hundred network requests to fetch all the names of all the characters that appeared in films with Luke Skywalker and the last point is why does this all matter well it matters because networks suck and I think we failed to appreciate just how much of a problem this is let's make a quick comparison if we were to read one megabyte of sequential data from a modern SSD that takes about four hundred microseconds but if we send a packet round-trip from the u.s. to Europe that's gonna be a hundred and fifty milliseconds that's a difference of about four hundred four hundred times that would be like the difference between ordering something on Amazon and getting next days shipping versus getting next year shipping so it's a huge difference and also let's not forget even if we live in developed parts of the world networks can still degrade very quickly case in point the Wi-Fi network here at this conference or if you are at an airport right imagine trying to run that rest demo at an airport or off of the conference Wi-Fi I don't have anybody brave enough to try that already no hands ok and yeah and so also a lot of parts of the world their their networks their mobile networks are just catching up sometimes they have data allowance caps sometimes the transfer rates are capped at 2g rates and so you really want to be careful with using the network with executing superfluous network requests and consequently this is what graph QL is great at this is where graph Gale shines the client gets to declare all the data that it wants in advance and it gets exactly that data no more no less in a single network round-trip this also reduces the need for client-side joins error handling and retry so the type system from the schema we know the types of all the different nodes that are in the graph and the scalar fields that are on those types and what this allows us to do is to have increased predictability when working with our API it reduces the cases where we try to deserialize a field into a mismatch data type and get an exception it reduces the cases where a field doesn't exist at all and it works particularly well with native clients that are built with statically typed languages such as Objective C and Java and at Facebook in particular this allowed us to generate typesafe client code for ios and android which means that we can detect compatibility breaking changes as quickly as possible in the development feedback loop another really interesting benefit that graphical brings is that in a tables fluent domain modeling and this is from the domain driven design book by Eric Evans in 2004 Eric had this idea that both technical and non-technical people develop what he called ubiquitous language and the ubiquitous language is just plain language that is used to describe the business processes entities and relationships well with graph QL because the relations are always nodes and edges the queries end up being a very close a very closed model of the language that you use to describe what's going on and that means instead of describing your business process in terms of HTTP verbs and resources and/or tables and joins and rows you're now just using natural language you're saying for the film get me all the characters in the film for the character get the name and this means that you can develop this shared language more effectively you can develop the ubiquitous language to mean more to more people with less confusion versioning the web has really spoiled us if anybody's been building native applications for mobile you know that this versioning strategies are not really foolproof because the web essentially gives you the ability to force the client to download the latest version of the app every time they visit the web page but on a mobile device maybe the user has run out of storage maybe the user has chosen to disable automatic updates you can't guarantee that that native application is running at the version that you want to run and as a result the best practice for graph QL api's is to not version them and we know this is possible because the largest grunt of fuel API and use that Facebook has over 10,000 types and has never been versioned and the cool thing is that you can fire up a version of the the Facebook mobile app back from 2013 and it still works to lien documentation graphical is probably the best example of a graph QL tool but there's other tooling that you can build with the introspection query and the graphical language specification the best example would be the IDE integration with vs code here's a quick demo of it let me see if I can get this playing so here if you're in vs code you don't have to ever have to leave vs code you can start writing the query you can start pulling out the fields in the different types you can get in line intellisense to tell you that something is wrong a field doesn't exist or you've validated the graphic your syntax rules and all this because we've pulled the entire schema from the server by way of introspection query earlier so the client knows before it ever has to execute the network request what is a valid request look like okay authentication and authorization this is this is one of the most commonly asked questions for graph QL how do you do authentication how do you do authorization I don't have an API where anybody can just ask for anything and quick refresher authentication refers to who you are and whether you can prove who you are an authorization refers to whether you have the permission to do what you want to do so to make that to make it more clear we're going to look at the stack stack diagram authentication and authorization actually don't happen in graph QL at all and so it's a bit of a weird question to ask how you solve this problem because if you think about a REST API it also doesn't happen inside the rest layer either it happens before at the HTTP server and that's where this server is checking the validity of the access token that the client is providing or some sort of HTTP header right and if that's that token has a bad signature it has a bad validity period well then the server just rejects that request it just says this is a bad request you don't have a valid auth token I'm not gonna go any further and try to execute anything else and so it is with graph QL if there's an authentication token and that authentication token doesn't pass the check you don't call graph QL at all there's a server layer ahead of it that integrates with the transport layer that will reject those requests authorization is a form of business logic that's why I've pulled out into this business logic layer and to understand why authorization doesn't go inside graph QL let's use the counter position what if it did go inside graph QL what if I had a rule what if I were building a blog and I had an authorization rule that said something like only authors and admins can view a blog post in a draft state if I put that rule into the graph QL server and I have a legacy REST API and I also have an RPC API where exactly is that rule enforced if it's enforcement a graphical server my best recourse is to copy that code into the other ways in which the data can execute write and copy the code around it doesn't seem like a good idea think of another way how would you unit test this business logic rule only authors and admins can view their draft posts if it were in the graphical server again that means that you have to lock load up the graphical server and then run an integration test to just test that one rule that authorization rule so that's why graph QL authorization rules belong in the business logic layer where the rule is uniformly enforced across rest graph QL RPC and any other way that you use to call into your business logic now I just covered a lot of challenges from on an API and that's just the surface and we know that building graphical servers is difficult that's why at AWS we built apps sync app sync is a managed graph QL service that deals with a lot of the most common challenges that come up when you're trying to build a graphical server what I showed you earlier with type graph QL and V s code was where you're composing this schema yourself and you're starting the server yourself but if you want to go the serverless route you want to go to managed route you want to take a look at app sync first and just to go over some of the common challenges that app sync deals with authentication and authorization it's automatically integrated with Cognito user pools for automatic real-time updates app sync supports subscriptions and I mentioned earlier that's very challenging just to scale out a stateful real-time server here especially for subscription support apps Inc does it for you and not only that it triggers those subscriptions whenever a declarative set of mutations is executed it also supports connectors with common AWS data sources such as lambda s3 or our server lists and more and also on the front end when you're using app sync you have these really cool features that allow you to build offline first capabilities so you can still use the the api's when your client is offline and then later on appsync can help you resolve the document conflicts for the updates ok when should you use graph QL I don't think this question is talked about enough anytime you use something new there's a learning curve there's a cost that has to be paid compared to the thing that you already know so if you already have a REST API on you know perfectly well how to use the REST API when should you move to graphical or from RPC to graph Gale from anything in a graph QL and I'm gonna give you a general answer this question it's really when do you use any new technology and I stole this from Martin Fowler he calls this the design stamina hypothesis and this came up when he was asking the question what is the purpose of good design he visualized it like this if you have on the x-axis time and on the y-axis cumulative functionality that your project has to deliver then when you start the project with no design you can actually move very quickly in the beginning because there's nothing to getting your way that's why the slope in the beginning is very high buts as you start to add more and more features the lack of design starts to starts to force the project to weigh in on itself changes are slower when you change one thing here something else breaks somewhere else so you need organization you need design consequently he believes that good design looks like this it means that any time you spend choosing the right design pattern on the right framework or adding documentation is time spent not adding incremental features that's why good design takes away from cumulative functionality in the beginning and where these two lines cross is called the design payoff line so the overly simplified conclusion here is that if you're below the design payoff line in terms of complexity you don't need to reach for something complex but if you're going beyond the design payoff line in terms of complexity you need to have good design in place whether that's design patterns whether that's rich frameworks whether that's react whether that's relay whether it's graph QL that's when you want to start thinking about it okay it looks like we are out of time but very quickly you want to get graphical and production do not build the entire schema upfront build it piecemeal definitely share and educate your team share the information with your team so everybody knows what's happening check out a lot of these advanced use cases for graph QL people use them as API gateways people use them for third-party services people use them to make service to service calls definitely check out app sync Apollo server Prisma and hoster 'his or is really cool if you're using Postgres you can generate a graphical server right on top of Postgres some of the resources and thank you very much i'm roberts please remember to fill out the survey at the end it's in the events app thank you very much [Applause]

Channel: Amazon Web Services

Views: 37,141

Rating: 4.9425836 out of 5

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS Summit

Id: bRnu7xvU1_Y

Length: 45min 29sec (2729 seconds)

Published: Mon Jun 03 2019