Kam Figy - Uber Modern APIs for Sitecore

you all right I got some fun stuff to show you guys today if you don't know who I am I'm cam Figgy I work on Team X's Sitecore weird like the R&D division for Ricky and JSS right now we've got another fun project to show you guys today so you might be wondering with the fella to leave vague title what we're actually talking about today here's a better title for the conversation graph QL all the things so who knows what graph QL is okay more of you than I actually thought great so graph QL is a query language for your API so it gives you graph QL Facebook made it in 2012 and they open sourced it in 2015 in the last year or so it's grained an incredible amount of traction because it gives you the ability to run front ends of any kind like graph QL is designed very explicitly for the needs of front ends and when I say front ends I don't just mean JavaScript most of the tooling for graph QL and most the usage of graph QL is in JavaScript but it is by no means the only thing that can consume it Facebook originally made it to power their mobile app so it's it's relatively agnostic you can raise PW A's you can use all sorts of other things and that has really amazing tooling like mind-blowing ly amazing tooling the api's can self document themselves because they are there in respectable so you can query a graph QL API to get information about what's in the API it has a typing system which means that it you can reason about the API and give you yourself those great tools that I talked about and use ours functionality and therefore real time stuff so if you've heard a signal or something like that graph QL subscriptions give you a very similar experience to signaler but over graphic UL instead so let's talk a little bit about graph QL and its advantages so I think you'll agree after we look at all this that it's time to give your REST API a rest and take a look at graph QL so let's talk a little bit about how graph QL is different than rest api's so the biggest thing is it doesn't over fetch so if you've used a REST API unless you have very custom difficult to use extensions to it chances are it returns a relatively fixed data set for each endpoint probably more data than you need half the time if you're using it for a front-end where maybe you've got six or eight components that all depend on the same rest endpoint two of the components maybe just need a title but maybe the rest of them need you know five or six fields so if you see up on the screen you've got the example of the the content service output from SSC it gives you that fixed set of like all the fields with a whole bunch of extra data like clone ID that you probably don't actually care about then graph QL you can write a query that gives you only exactly what you're after and you specify exactly the fields you want and you can also do crazy stuff with data relationships so in a REST API where maybe say you want to get a cycler item maybe you want to get its children maybe you want to know what fields are on its template or something like that you would need to probably make you know anywhere between three and you know n requests if you needed to make a request for like say each field data or request the item service for each child and maybe you have a hundred children well making a hundred HTTP requests isn't gonna fly but in graph QL you can say hey I want the children and you can say I want to know the child and the name and all you get back is a JSON array that has only the name in it you don't get anything extra so it's extremely bandwidth efficient and it's very good at handling data relationships like this graph QL as I mentioned earlier is typed so unlike most other api's I mean there's stuff like swagger for rest that's not really a standard that gives you some capabilities of documenting stuff in graph QL you can see these screenshots up here this is a tool that is looking at live API documentation it's a tool called graphical that we'll look at in a minute that will tell you what you can do on an API what the types of all the fields are and lets you query them all very very easily and a super awesome UI so let's go take a look at that UI can you switch the demo please okay so this is the site core implementation of graphical so let's start by taking a look at the docks so in the graphical docks we can browse through everything that you can do in the schema or we can just go and start writing a query so if I write a query I'm just going to hit control space you can't really see but that's what I'm doing and it's gonna show me exactly what I can do at that spot just like intellisense in visual studio so we're gonna write a query and we're gonna write a very simple query so we're gonna make a selection set so it's called when you put it between brackets I'm gonna hit control space again and it's gonna tell me what all the route things I can query in this API so I got items sites templates I can do content search and there's some other sample stuff in here and then you can see the the schema and type there at the bottom that's the introspection you can query on the number types in the system you can query on what the schema is what the hierarchy types in the graph because as you might imagine in graph QL your API is a graph so you've got nodes that are connected to each other so we're gonna query on item and item being an object also needs a selection set to tell us what we need to get out of the item and if I hit control space again you can see we have a whole bunch of stuff that you might expect to get out of an API in psycorps and in case anyone's wondering this is 100% live running on site core like nothing is faked here so I'm gonna get saved ID and I'm gonna get path and I'm gonna run it so I got the psych core root item I got its ID in path which is you know not particularly impressive but if we go and do something more interesting like say I want the children and maybe I want to know their name and whether they have children of their own there we go super easy there's all the children's every day and say maybe I wanted to know on the route item its template and I wanted to know what fields it had on it and I run that and I get that show the templates own fields for the route which has no fields right so let's go and query an item that actually has fields so you can also do arguments on the nodes in your graph so in this case if you just say item with no arguments it's like okay you must mean the home item but if you specify a path which can also be an ID but in this case we use a path if I could type so we'll do the same query but on the site core content home item and now you can see we get you know the traditional grid that if you're a crazy site core developer like me you would recognize anywhere 110 d 5 v 9 and we got a query on that item and it has no children because it is the home item it's the default has no pages yet under it but it has a title and a text field so here's the part where it gets really fun on this item we'll go take a look at it so I'm just gonna hover over it I'm my query and I can go mouse over it and click on it and see it in the docs so if you want to browse stuff and you're not sure what something is you can just mouse over it you can search the schema in the docs it's really really powerful and really easy to get into so we went to item and there you can see all the fields that we've got on here but the really interesting part is implementations because item is an interface you can have interfaces in your graph QL types so there's a whole bunch both load of implementations of the item and you can probably guess where I'm going with this that if I search the schema for say sample item that we have a type in our graph QL API that represents the sample item and we pulled help text out that tells you exactly what it is it represents the sample item template and it itself implements an interface for all of its based templates and if we scroll down here in the fields it has all the implementations but it also has the text and the title fields that we just looked at so here's how to get ahold of that so you can do what's called a fragment you can think of it almost like cast in link or something like that if the result is of this type then I want to query it as if it was that type so if I say on sample item and again we get to telethons on this and i want to get the title as you can see now we get the title and the text but title and text are fields and so they need selection sets because a field has its own set of values so I can get the ID the name I can get the editable value I can get the raw value and I can get info about what those mean so there's actual documentation in the API of what it is and when there's something like raw versus editable there's text that's actually helpful that tells you what you should probably be using so in this case we'll just get raw value for each of these and then we'll run that and we'll get the title and text out of the homepage now the next thing you might be wondering if you've used something like an ORM before is like great you've got the strong typing but what happens when I change the field names that blow something up you know it does it run but then the value comes back as null well the answer to that is because graph QL is a type schema language the answer is it will blow up with the query so if I add a couple of fields in there it's gonna say there's no value it's also going to suggest what the field type value that you might be meaning was and it tends to be pretty good at it so it will actually blow up on the server if you make a query that's wrong so it gives you that validation and there's a whole bunch of other stuff that you can do with this unfortunately graph QL is a subject that I would love to fill your heads with for about three hours but I only have 45 minutes so I'm gonna have to scratch the surface and move on but this is where you would author your queries and the place where you would use graph QL if that's not clear to you is like if you're building a JavaScript application or something like that you would be using this to get data out of site court this is making HTTP requests to an endpoint so in that way it is very similar to rest I can actually show you that here in the network tab if I run this query again that a graph QL request you guys see that side big enough that request is just a JSON post of the query and you can have variables and you can do some other crazy stuff with multiple batches in the same query document but the upshot is that it posts the query off as JSON to the server and the response well it comes back and looks exactly the same as the response you see like we're just dumping raw JSON so it's the same JSON that you'd get if you came back from a REST API it's just structured in a way that it matches exactly the query that you sent to the graph QL API so you can predict exactly what the structure you'll get back in JSON is by just looking at the query which means the front-end developer doesn't have to go and like look at your API Docs to figure out what they're gonna get back if they see their query they can reason about what the result objects gonna look like and if you look at the schema you can also see that you can do other reasoning about it like string for example here if it has an exclamation mark after it like database for example is a string with an exclamation mark after it that means not null so it's never going to return a null for that value but if you say queried an item on a path that didn't exist you would get null back then you could reason about that in JavaScript as well or anything that parses JSON but javascript is the easiest all right if you switch back to the slides so you might be wondering what else we've got to play with and let's just note that a really perfect match of course is jss and graph QL because jss is a great way to build JavaScript apps we against site core and graph QL is great at providing data to your front-end so what can we do with that first to understand the way that we can use graph QL with jss you kind of have to understand a little bit about jss so for the people who have maybe haven't seen jss i'm gonna give you the two-minute intro to the most core piece of JSS layout service so the way that layout service works is it's a rest service that syndicates out the way that site cores layout structure works so if you've got placeholders with renderings in them that have data source items layout service is going to give you a JSON representation of placeholders components and their data and you can take that and the core aspect of JSS is to take that JSON and give you a programming model that you can easily use to allow you to basically move cyclers layouting engine to the client or to server-side rendering in JavaScript so to understand the way that we can use graphic QL with this it's important to understand the data that we're getting into jss in the first place so there's two ways that we can get graph QL data into jss an integrated graphic ul what we're doing is we're taking the field data that we get back normally that would come from the data source item in layout service and instead it becomes the result of a graph QL query so if I look back here one slide the fields you can see there a title text and body that would be replaced with the JSON result of a graph QL query executed integrally to layout service so you don't need a graph QL requests separate you could just do a layout service and the second way of doing it is more or less connected graph QL is basically the same way that any JavaScript app would use graph QL so your JavaScript app whether it's using jss or not I mean if you are using jss you probably make a layout service request you get the data back to it and then you're gonna make a graph QL request to get you know some additional data that you need to render your layout if you're not using layout service you could just cut layout service out of there J SS or your JavaScript app calls psych for graph QL API directly with HTTP your WebSockets and it's good to go so those are the two ways that you can do it let's go take a look at how we can use that stuff if you just switch back to demo please so here's layout service and I can show you a example of what's actually going on with connected graph QL or integrated graphic ul so normally we've got the home page of this is the the JSS graph QL sample app I can show you its front end this is what it looks like this one is using integrated graph QL to render this page so get the content for this title and for this text it is using integrated graph key well and then it's listing the children underneath it which is a secondary integrated graphic you lop buri so it's actually making to graph QL queries in a batch off to this API so if we look at the graph QL query that we have in our layout service so here we've got the fields coming back for the title and here we've got this data attribute and the data is always the route of a graph QL query result so normally it would say you know fields title fields text in this case it says fields data because it's the result of a graph QL query and the datasource element there at the root is because we queried a graph QL endpoint called data source which is something we introduced for JSS that does data source resolution and you can also do resolution of things like search based data sources if you want to do that so we've got this integrated graph Cabella query that replaced fields and when it renders on the client so if you notice this is a localhost build what we're doing is we're running jss and dev mode but we're running it connected to site core so it's making requests to the site core engine it's not running on site core the reason why I'm doing that is so that we can actually look at the requests that it's making because if it runs integrated to site core the layout service data is provided to it by site core because the jss app renders at the server side so there's no direct request to layout service that we could see in the network tab so that's why we're using the connected mode so we've got this request that we made to the layout service which we just looked at basically the same thing we're getting the the home item on our site and all of this rendering is going on at the client and I can show you what is that so let's take a look this is there's no studio code and we're gonna take a look at the this is a react app so if you are unfamiliar with react here's a super fast crash course so on the integrated page there's a lot of stuff on here essentially this is a function that takes what we react terms are called props it's basically a JavaScript object and it renders a result based on those props so it doesn't maintain any internal state it's basically it's a very functional programming type of thing here's your props render the result and the result should always be the same given the same props but what's special about it is that those props come from graph QL because this ends up getting rapped by the JSS system and the JSS system provides this fields object and the fields object is the result of that fields that we saw in the layout service output so normally you would be rendering your component out if it was normal JSS like this text here that's rendering out the title field normally it would be saying something like fields title but in this case because it's graph QL and there's a structure involved we say data source title jss and JSS is a little helper that lets you get the the correct stuff to pass into these jss helper components so it very much looks the same way as a regular JSF site it's just rendering off graph QL so when you need those advanced data capabilities you can take advantage of them and similarly if we look at the definition for this so in jss you can define the whole sight disconnected without a sight for instance so we've got this graph QL query file normally you'll author a graph QL query in a file that ends in dot graph QL there's a lot of really amazing things you can do with that by not creating it with dynamic variables you can do static analysis there's es lint plugins will let you validate it you can download your graph QL schema to a file and then pass it into es lint and at Build time you can have it tell you if your in your graph QL stuff has errors so you can do some really nice CI automation stuff there to ensure that you even if somebody does rename a template that's gonna make your build fail because the schema will be wrong and it won't validate your query and so basically what we do is we import that graph QL file and then we just add it onto the definition of this component so if you're familiar at all with jss there's an import process that you can define components like this run against them without a site for instance basically mocking everything about site core and then you can use an import process to say take everything i've defined and push it into site core so similarly you can take this and push it into site core and that query ends up going into a rendering item which i can show ya so in RDS s basic app we've got the integrated page rendering make things a little smaller here and unprotect this item so you can see and you scroll down on it there's a field called graph QL query and you can see that we deployed that same query into it and we can open the query in the experience browser with the variables preset I mean we can't tell you what the datasource is gonna be you'd have to go look up the datasource item yourself to render the data source with but we can basically go and quickly edit our query you do have to copy the query back out of here and throw it in the field because there's just limits to exactly how much IPC I can get this stuff to do but it does let you go and edit it so here we got the context item it was already set to the home and you can see that we're using graph QL variables here variables if I talked about having a static graph QL file variables are the way that you inject essentially the the different components into your query dynamically so in this case we've got datasource in context item those are ambient variables that you can just use in a jss app and we will set them if you're in the context of a rent jss component they'll be set to the data source item are the data source expression on the layout and they'll be set on the the context item will be set to the ID of the the page that we're rendering and then in connected mode we can go take a look at these about page the about page doesn't really look any different but the about page is making graph QL requests so we've got this request here that gets the about layout but then we've got these other requests here that are going and making graph QL queries and the first one there so here's another example of a great graph QL thing query batching normally if you had to make seven requests to a REST API for example you would have to you know queue them all up make seven HTTP requests graph QL as a protocol has support for things like batching because it's a very defined you set use passed the query and its parameters and variables in this way you get the result back as a JSON blob this way well some smart person realized that if you make if you basically queue up queries and so there's it's that's a timer for by default for 20 milliseconds and queries made within 20 milliseconds get thrown into an array and you can see the array of three queries here and all the queries go to the server at the same time one requests all the responses come back the same way and then the client which in this case we're using Apollo graph QL client which is a very commonly used graph QL client on this on the JavaScript side and it basically disambiguates the batch so you don't even know that batching is going on you just get the query back as if you'd made any other type of query request you just get the advantage of one HTTP request instead of three for pretty much nothing like you don't even have to be aware that's going on and so what you can see here this is doing persistent queries which is an advanced way but another advanced thing in graph QL that that's a bandwidth optimization essentially it's a negotiation protocol where when you make a graph QL query the server is sent it just requests the the query by hash value and sha-256 hash value and the server either comes back yeah I know about that and I executed it and here's the results or it says give me another set of data send me the actual query the advantage is that you never have to send the query more than once to the server because the server will keep track of it which means if you write you know like a six or ten kilobyte graphic you all query which is not completely unheard of you reduce its size posting over the wire to the size of an sha-256 hash which is like 75 bytes something like that instead of 10k so it's a lot of bandwidth savings there there's a lot of really great optimizations that the graph QL community has been making and just to be clear most the stuff is all graph QL community-driven that we just are taking advantage of so we got the results back for the the graph QL query that we made and you can see we have the same context item and data source if you remember seeing those from the integrated graphic UL query we're making those two queries this is the exact same query just instead of the results coming back inside of layout service they're coming back inside of the HTTP request so the last thing that I want to show you about this app is a fun little demo that we built that shows graph QL subscriptions so we built a very simple chat app it would not scale in real life although this is basically a simple echo chamber and I'll say that I'm cam and I will say hello there and I had to build robots because no one's here busy chatting with me so you know we've got Akshay I guess no one else is here because I don't remember what I was supposed to say to trigger something but I will I'll show you I'll show you that if I load up another window of the same thing and not maximize it so that we can see yeah I didn't can't type sorry Mike so you can see that it's it's working across the fields and I've now immortalized my terrible typing but essentially this is using graph QL subscriptions its main to opening a WebSocket connection to the server and so it has a real-time channel that it can push and receive messages over and there's a protocol built on top of graph QL that runs over WebSockets and lets you push real-time data back and forth now chat is not actually the most exciting thing that we can do with that although it is cool and so with that let's go back to the slides for a minute so let's put everything together with the last demo well actually the next-to-last demo we built a super unofficial prototype please do not take this as anything other than complete pie-in-the-sky example of using a graph QL powered database browser like if you're familiar with the database browser and Psyche for admin DB browser data aspx it's a like super basic way that you can interact with the content tree that is not as advanced as content editor but it's very fast and is handy for some things like it doesn't validate links before you delete so if you just want the whole tree of items gone try the DB browser if it tells you that you know the templates and use or something like that so we built a completely graph cool powered database browser you switch back to the demo please so here is our graph QL database browser this is an angular 4 app that is entirely powered by graph QL it is running separately on a different port different process powered by node from site core I am just making requests to the site core graph QL api's so is of course using cores if you're familiar with the origin restrictions and basically we just built up an app that lets us browse the content tree and we can load them and get fields data and things like that I can say you know why can't you be my friend Jeremy and say that and you can see up here at the top we got a notification that something was saved that notification was not something that I asked for on the client the notification was a graph QL subscription coming back and telling me that an item had been saved because I'm subscribed to item saved this lets us do fun things for example if I go into the content editor here and let's split these windows here so that we can see at the same time I will go to the same home item collapse the giant editor so you can see now it says why can't you be my friend Jeremy I'm gonna change this to say Akshay and save it and you can see over in the graphic you'll window now it says why can't you be my friend Akshay that's because again we're subscribed to item save we know that you haven't changed that field so why don't we just update it but what if I had changed the field why can't you be my friend Mike and say you know I want to change it back to Jeremy because he wants to be actually his friend so I'm gonna save it again and it tells me hey you changed this it knows whether the Fiat the form fields were dirty or not and if you've changed a field and somebody else changes the field tells you you have to resolve that so we'll take their changes and then we'll save it and then the field goes back to not being dirty again so this is just you know again this is nothing official don't expect this coming in the product this was just what cool things can be do with graph QL subscriptions and real time data it's way more than just chat if you need to have real time reactivity without a page refresh take a look at it you can use it to you know you can do some absolutely insane things with this type of stuff you know similarly like you know say I rename an item you know like I'll take home and rename it homes so you be updated it in the tree on the outside because we're subscribed to items being renamed and if an items renamed that we have shown in the tree well we just update the tree you know it's it's real time reactivity it brings a heck of a lot of really nice user experience so that's what I had for that can you switch back to the slides please here's the next great thing you can make your own of these this is not something that was built to be just a one-off thing this is an API framework so you can define multiple graph QL endpoints you can define graph QL endpoints that act against your data because a wonderful strength of graph QL is API aggregation how many people have worked with you know internal REST API is where there's like seven REST API is and they all have totally different schemas and frameworks and don't work very well and are slow probably just about everyone right yeah you can take those and aggregate them in the graph QL and when you aggregate them in the graph QL because the way graph QL works if you don't query a field you don't make those calls so you can have one schema that lets you call you know all that galaxy of ten back-end services that you know runs a CRM or runs anything else that you need to expose to your website expose it through one schema and if you don't call the schemas that make you do that that graph QL call it's not going to call those back-end services so it's very efficient it doesn't call anything more than it needs to it's extremely extensible there's three ways that you can primarily go and extend the graph QL API you can do schema providers and a schema provider you can think of as being a segment of a schema so if you remember seeing the the docs browser that we were looking at the had all the types in it think of being able to define a section of a graph so you can add you know when you saw item as a route query you could add customer as a route you could define types that define what the attributes are on a customer you could define other relationships that would come from a schema provider and then you define graph types types directly map up to the types that you see in the documentation each of those types is a mapping between a c-sharp class think of maybe an existing domain model for an API client you already have and a graph QL type so you can expose a little bit or a lot of it and you tell it exactly how to resolve the values that you want and the third and most crazy thing is that you can do schema extenders a schema extender basically comes after schema providers and one graph QL endpoint can run multiple schema providers and the schema extender comes after them and can mess with the schema so for example suppose you had a CRM that had say a customer ID field and you had items in Psych or that had a customer ID field and you could extend the item API to let you query a customer field on an item that would know how to take the customer ID field and query the CRM and bring you customer data back from within your item API as if it was 100% native that's the crazy stuff that you can do with graph QL so let's go take a look at that stuff could you switch it back to demo please before we hack too much time so our extenders now we're getting into c-sharp so let's take a quick look at a schema provider and I'm gonna try and go fast here because I know people probably have questions so here is a very simple schema extender it is a class that extends schema extender and then you make some queries that change your schema so in this case we are finding a graph QL type called appearance and we're changing its description to say that it was modified by an extender in the case down here we're finding the appearance graph type and knowing that it's an i complex graph type because we defined the type so we know what it implements and then we're extending the fields in this case we're setting field descriptions again here but we could be adding new fields to that type we could be changing the way that a type resolves stuff there's all sorts of things that you can do with these so as a sample of that let me show you a demo that intentionally won't work because we have no internet access here but it will demonstrate what we've got so we have this home item that we were querying on and we renamed it to homes so we're gonna fix that and we're gonna make sure this query still works and it does but in this case I had an idea let's make it so that we can query as you're cognitive services on the values of our text fields so if we take the text value here and we say text analytics so we've defined a new field on the text field type called text analytics and we've attached a graph type to it that has key phrases and sentiment and if I run this it's not gonna work because I'm not on my fight and something tells me if I tried to get on Wi-Fi it still wouldn't work but it does work and it shows you what you can do with schema extenders you could add whatever you wanted onto these item fields and have it work and I'm hoping that at times out soon because then I can show you what I really want to show you in this demo so you can see we got text analytics with key phrases in sentiment null the query still ran and we still got the data that was resolvable we still got the title and we still got the text but what we did get was errors so in graph QL when you get a response it will send you errors graph QL clients will trap if an error exists and it will usually throw an exception but if you can still use the data it's not a pass/fail it's not that an error is necessarily a termination of your request suppose that you wrote this in such a way that you caught it you text analytics was unavailable you could still keep on using your site core data so it's not just like you get a 500 error and that's it so it tells you where it was it tells you the path that tells you the messages that the exception happened so you can see that the problem is that we can't see west central us further laughs so I'm gonna actually get on Wi-Fi and we'll see if we can actually make it work if I could actually use a mouse correctly theoretically we're on so maybe it will work and maybe it won't yeah apparently not or maybe nope unauthorized so my my API key must have expired but anyway the idea of that is that you can write an extender like that that you know we created a type for text analytics we extended the item field graph type specifically the one for text fields which is the name here and we told it to add a field called text analytics which we saw in the the schema and then we created the text analytics graph type and what the text analytics graph type does and defining graph types is applicable for extenders and schema providers is it graphs it maps field and in this case field is a site core data items field just the regular old field you'd get out of the API and it Maps it on to a graph type so the graph type that we would see in the documentation you know we give it a name so we text analytics you know we give it a description that's what shows up when you see the help and we gave it the field called keyphrases and we gave it the field called results and sentiment and we gave it a resolver so when I started graphic you all resolvers or what confused me the most so let me show you resolvers what a resolver is is just a function it's a function that gets passed the parent context in the graph and the parent result which in this case is an item because we're in the context of an item and it returns the result that will be mapped into the graph type so it would return actually like the field or it would return even an item for the item resolver like you don't have to do the mapping yourself it's smart enough to map the results for you you just return your C sharp domain object and in this case we're doing some heinous stuff with making JSON the string just to make the API work really quickly because it doesn't have to be perfect and then we're basically returning the result as a string of rain we're not returning a graph QL array we're just returning an array of string and it knows because I declared the field of sentiment as or the field of keyphrases as a list graph type of string graph type that basically says I'm returning an array of strings there's also a non null graph type which is a not never returning null for this so it's I mean it's a little bit more loosely typed than you might expect as a c-sharp developer but you have to keep in mind this came from the JavaScript world and they're essentially adding a type system into your API so there's kind of where you can go and the config is all driven by site core Factory so if you want to define an endpoint this is a partial configuration for endpoint so this is not the entire config this is just patching an extender on it but the idea is that there's you know psych core API graph QL endpoints under there you define endpoints you tell it what the URL you want the route to respond with is you set up your security you can set up performance logging like you can log down to the single resolver function level how your performance is going you can read new extenders you can add new schema providers whatever you want to do and it's all very easy to extend based on the site core Factory so there's a super quick intro to that could we go back to the slides please so as I said at the beginning I could talk to you about graph QL for three hours Alok shiba here was the first one to get addicted to graph QL and then he brought me addicted to graph QL and then someone told me the other day that Nik Wesselman now won't shut up about graph QL so hopefully after this you guys will also not shut up about graph QL there's a whole lot of things that I didn't have time to cover we talked a little bit about API aggregation there's also some really awesome tools for testing draw the graph QL tools NPM package is capable of fully mocking a graph QL API so there's a there's a schema definition language for graph QL and if you go to a site core graph QL endpoint you just go to slash schema on the end of it you can download the file of it or you can HTTP it from a CI process or something and it's a file that defines the structure schema you can take that file and combine it with graph QL tools and have it create basically the lorem ipsum version of your graph QL endpoint for running tests with JavaScript no site core necessary you just write the you know you you can use default resolvers you can write your own resolvers if you want more realistic looking data you get a graph QL API that you can query for unit tests damn done you can also do static analysis with the eslint I touched on that a little bit with the same schema file and vs lint configuration you can take it have it lint all your graph QL files so if you're doing a front-end build for a react app or something like that and you're doing your graph QL query statically then you can do that that way and the last thing is for security reasons in some high level production api's you may want to whitelist what queries are allowed to be executed because the graph QL query is extremely powerful but that means you can also craft extremely expensive to execute queries there is a built in learning whitelist so if you have say a set of integration tests or something that executes severy graph QL query that your site would be doing and that does not include variables so basically you whitelist your statically analyzed queries and then you can pass whatever variables you want into them and it's basically like giving you stored procedures that you can execute and that can be done at Build time and you get a whitelist without you know having onerous stuff with your developers having to explicitly add things to the whitelist as they doubt you can just have the integration test capture the queries they got executed and that comes your whitelist so that's what I had and if you were here in 2016 and you have a question just as a reminder one does not simply address the elephant in the room and with that there's some links and resources go ahead I think just one or two quick questions okay yes and if you have any more questions I'll be up here there's a break after this so come and bug me I just wanted to know how does Graf kill handle authorization so you don't get the situation where one user can access and other uses it depends on how you want to handle authorization and how you write your resolve functions the graph QL API itself is just a static API the content API for example because it has a site core security context respects the context of the user that's being executed with you can authenticate against it by default either with cookies the site core auth cookies or by using a site core services client API key and that API key can be set to impersonate a specific low privileged user so if you want to grant access only to very specific parts of the content tree for example you can but in terms of authorization for other stuff there's a pluggable authorization function that you can authorize however you want and then it becomes a matter of how you resolve the data from your API and how you want to authorize against it like you could return an error or something from a resolver if you were not authorized any other questions well thanks a lot cam you're welcome thanks for having me [Applause] [Music] [Music]

Channel: SUGCON

Views: 974

Rating: 5 out of 5

Keywords: sitecore, sugcon

Id: B10opA67AkY

Length: 46min 31sec (2791 seconds)

Published: Fri Aug 03 2018