* This is an automated transcript. Please excuse inaccuracies.
Hey there, so in a previous video we talked about how 8base will create for you and manage all of the Graph QL resources or schemas that you need, to perform crud actions on any table through your API endpoint. Know though that is a type of functionality that's totally extensible through the use of Resolvers which are a type of custom function 8base offers. And we're going to jump in right now and take a look at the basics of how a resolver works and how you can deploy a custom one yourself, so that you can add any type of functionality that you really need to your API endpoint by developing these functions.
Okay so two quick things to go over before we get started: First off is that I am working in a workspace that was created using the QuickStart app that you can find on our documentation. So, if you go to Docs.APS.com and click on “click start” right here on the left side you can go through the first five steps of this and get that directory on your computer locally, as well as deploy it and have some data records populated in there. The next thing that I’d just like to say is, as we go over custom functions, know that you can always dive in the documentation as well and look at the documentation for custom functions. So, this will help you understand which arguments are getting passed to your resolver function or any other type of custom function; that we'll go over in subsequent videos as well; as you can look directly at Resolvers here to get a better idea of what's going on.
So, let's jump right in to our text editor sublime to where like I said, I have the QuickStart app here locally and I'm in the server directory. So, inside of the server directory, we have an 8base.EMU file and this is a really important file because it is what declares all the resources that will be deployed to your project when you run 8base deploy from the command line. So, this is really how you provision a workspace with custom functions and with any other type of resource that you are provisioning through code right.
So, when we have a resolve or a function and remember this function extends the Graph QL API, first we have to give it a unique name, then we declare its type which is resolver, we have to give it a schema and a handler. So, if you've ever written serverless functions you know let's say using, Lambda you'll probably pretty familiar with what a handler function is, however, the schema function might be something new to you.
So, let's just go quickly into that path which is source, mutations, listing, share, schema, doc Graph QL and we're going to look at this file right here. So, what you're seeing here is when this is okay well extend type mutation. Mutations are 8base type for our API or for our Graph QL API. And we're creating a custom mutation type here called listing share which needs an ID and email and it returns a success response. So, the success response would just turn a Boolean value of success true or false. So, if we wanted to, we could excuse me, we could type our response meaning that so if we gave it a type of custom result and in there we wanted to say, “Okay well we have a key called ‘status’ which is a string.” Let's just leave it at that. We could make that custom type declaration and use that here right. So, this is completely up to you to configure to be the function input and the function output as you want. And this is what's going to be then used by the Graph QL- if we go into the API Explorer, this is what we'll be using the API Explorer, so that you can look kind of be introspective into the function you created and so it gives you all the information. I'm just going to return this to the state that it was in… cool.
So, now if we go over to our handler.JS right there's that this function is the one that you'll get in the Quick Start app, but let's just walk through it really quickly to understand what's going on all right. So, first off in our schema.Graph QL file, we declare that okay the listing share function, we get passed an ID and an email they're both required arguments. Well then in here, on the event arguments has passed if we were to go into event.data, that is where we could find both ID and email that's where those at information gets passed. So, what's happening remember this function right here is to being deployed to your server- it becomes a server-side function. So, if you were to make a Graph QL call to listing share and pass the ID and email, it would populate into here it would then create an API request on your server right. So, it makes the listing query which is defined here passing the ID that you gave it and so it brings back all those listings- there that specific listing- excuse me. If it doesn't get that it would return a false status and the reason why it's returning success false is because and this is important, that is the type of response that we said this function has to return; so, it's a typed response.
So, let's say that that wasn't a base type offered by a base what you'd be expected to do here is, have success response is success, Boolean acquired. And so, that is what you can expect coming back from the API true or false whether or not that it was successful. Jumping back in here, we even see the okay if we get the response successfully it will then from that response or we then from that response pull out the listing and the property. We are then going to send an email because this is a listing share, it invites someone to come check out a listing. We're then going to send an email using this send mail module, which is not important right now to the email that was specified and then adding just some title and email body information. And then once again, we give the declared type back whether it's false or because the email wasn't sent, or true because everything ran correctly right.
So, one thing I'm just going to point out here is that let's go into our 8base workspace, I'm in the API Explorer and let's say I was going to try to run EMU mutation. And I was going to say, “Listing share”, but we can see that listing share isn't here because we haven't deployed it yet. So, now what I'm going to do is, I'm going to go to my command line, clear this up and where am I… PD- cool. I'm in the server project. So, I'm just going to make sure that this is saved. Save this, save this, now let's run 8base deploy. 8base deploy. All right this might take a minute, so once it's uploaded, we'll be right back.
Okay cool so that didn't take that long at all and now what we're going to do is jump into our workspace to see or validate necessarily, how that function was deployed, how it can be used through the API as well as just some other things that we can do to check out and kind of have some good oversight of it. So, first off if we go over to our 8base work space and we reload the API Explorer- I'm going to delete this comment. And then, we can see that unlike earlier when we looked for that listing share mutation, now let's team share is right there. And just like we declared if we want to give it an ID and an email- let me just throw in a fake ID here. ID and email, cool. I'm going to throw in a fake email address Hi@Co.com. All right just let me declare, success is the response type right. Okay so just for fun I'm going to execute this and we'll probably get a false back exactly because it couldn't find the ID. And if it did find the ID, maybe it couldn't find the email.
Another important thing to notice here is that already our Documentation Explorer if we'd go into mutation which you say listing share, we already have that documentation in here of what available right. So, a super cool and powerful way to extend our API endpoint and you can get really creative obviously and pretty much do anything that you need to do on the Graph QL side.
And one thing that's worth mentioning too is, right here we're playing with this in our API Explorer but this is a function that you just created that would be used client-side right. So, you'd be able to pass in to Graph QL tag variables like, ID and email and then have this function run.
So, the last thing I just want to show is that if we go over to logic which is here on the left-hand side, we can see that the custom resolver function was deployed as one of our custom functions which we right here. And if we want to just look at the logs a bit being run, we could just jump in and see those. So, right here that we can see that it was invoked twice. And so yeah this is ready and good to go.
All right, thank you so much for taking the time to watch this. We're going to go into writing more advanced Resolvers really soon, as well as all the other different types of custom functions for 8base offers. So, have a great rest of your day and looking forward to seeing you in future videos. Take care.
We're excited about helping you achieve amazing results.
