 This one, I think the organizers real quick, before I get into this, my third guru, guru-co and my first time speaking here, so it's really great and bittersweet to be speaking, even though it's the last one. So about me, I'm Rachea McBean. I'm a software engineer. I write a lot of JavaScript and Ruby code. Currently, I'm an engineer at Kickstarter, a crowdfunding platform that brings creative projects to life. As Luke mentioned, I'm an organizer of ManhattanJS, a monthly meetup happening in different startups across the city. We were recently at Newzella. And we're also part of a family of meetups, if you've been to either BrooklynJS, QueenJS, or JerseyScript. And you can find me on the internet at Twitter or Instagram at CopaceticKid if you'd like to keep in touch. So today, I'll be speaking about building efficient APIs with JSON APIs spec. And APIs, most of us interact with them on a daily basis, whether it's consuming API that you've written inside your application. That's going to be consumed on the client or you're interacting with a third-party one like Google Maps. We also build them too internally or for our clients or for mobile apps. And we typically spend a lot of time designing what one might look like and trying to figure out what is the best way to design that. And sometimes that doesn't turn out so well for the end users who are consuming that because it isn't really clear how to interact with that, what was the thought going into that and how it should be documented. And as developers, we really strive for productivity when we code, especially when it comes to interacting with an API. And that's where the JSON API spec comes in. It's for delineating how clients should request or edit data from a server and how that server should respond to those requests. Its main goal is to optimize HTTP requests, mostly the number of requests you're making and the size of the data that's coming back. And one of the ways to start doing that is by using this content type so the server knows that what it's getting is this JSON API content header. And those request documents will know that. And then the document structure is essentially a JSON object is going to be at every root of what you're sending or receiving. Inside that is containing the keyword data. And then from there, you get your top level items that you'll be interacting with and consuming. And with that, you get data, errors, and meta, not always coming back at the same time. This is an example of that structure. And here, this is a request that you might have gotten. So everything will come back into data. The type here is specifying the model, that resource, and then IDs, and attributes, and so on. I'll get further into what those look like and mean. So resource objects typically have the ID and type, like I have just showed you in that example, where I used an article and then ID with this to number. And those typically contain the following attributes that represent each field, like columns in your table. Relationships, any relational data that can come back. It'll provide, depending on how you request for that, it'll usually just come back with links so you can make those requests either in the same request or later. Links for that related resource. And then metadata, which is usually like non-standard data that you just want to send along, denoting anything important about that request. And then in compound documents, you'll also have, within that top level, you'll have the related data. When requested, it will come back side-loaded, and it includes that. Usually looks like this down below at the bottom if you can see that. And that would side-load any relational data that was coming back along for it. And then you have the key to go look for it and what it belongs to. And then information that I mentioned, which was just like the non-standard information. The links usually look like this. On the top is just an example of what looks like when you requested data, and this is just a link back to what you did request. So the top example is just requesting all of the posts from a page. And then the bottom is an example of getting links of relational data for an article if you wanted the comments back. And then at the bottom is an example of the meta, which is just letting you, knowing the count here that's coming back is just 10 comments in that particular request. So when it comes to fetching data, it looks pretty similar to something that's standardly restful. At the top, you have just getting back a collection of them. The second one is getting a specific resource. The first one. And the third is how you would look up getting the author of that first article. And it'll return that relational data. And then if you wanted to, you can also independently look up the relationships for just get relationships on its own and the data. And you can do that doing this. And this comment example here, comments is what we want back. And we have a straight link to that, knowing we only want the comments associated with the first article. And then sparse fieldsets. If you use GraphQL, this is what you would find in there, too, allowing you to only query for specific fields that you wanted from a particular model and allowing you to customize that looking like this with a query param that includes that. And then the fields here that I only want back are from an article or the title body. And then you can do the same thing with associations. I only want the name of the people related to that. And then you can also sort that as well. Most people don't really do that. They usually tend to save sorting on the client side for what they're doing. And then you have to interact with your typical crowd actions. You can create resources using post requests that generally look like this here. I'm creating just a new photo. And at the same time, I can assign what that relationship looks like as well for the person who took the photo in that singular request. And then updating relationships just are packed requests. You don't have to. When you implement this, you can just pass along what you need. Doing wholesale updates is generally encouraged in a destructive action that you'll be doing. And the same thing with updating relationships. You can use that same similar link that I showed you earlier to just update the relationship independently of bringing back the parent object as well. And then deleting is just using the typical delete request as well. And then when it comes to errors, the spec allows for that as well. Gives you an object that comes back, usually for anything that's a 400 or 500. And typically, in that error's object, you have these items not necessarily all come back at the same time. Typically, it's just the ID or the title detail and source to let you know what field on the type of the model failed and giving you some information that you can display back to the user of why it failed. So this spec has been around since 2015, version one of it. It's implemented in various languages, including Ruby and Ruby on Rails. You can use it in plain Ruby if you wanted to use it for Ruby on Rails. I've been using the JSON API resources, which is a framework that lets you do a lot out of the box of adding to your controllers so it can respond to these requests. But there's also a lot of room to customize this if you have logic that does more than a simple like show me a record or update it. You can override that and then return back the serializer that you need for that request. So with all of this in mind, what about GraphQL? Why not just use that instead? Well, you get all the same benefits from the JSON API spec without sending all those multiple resources in the similar request. But it's also less of an infrastructure cost upfront if you've already been doing a traditional JSON API spec and just need some more improvements around that for the productivity around your team and get that generalized tooling together. But while the spec does have some similarities to GraphQL, they're also in the stage of tracking from where they are missing and where they can catch up with that. And right now there's an open issue if you go to the JSON API spec repo. They're talking about ways of how they can catch up to some of the features that you'll find in GraphQL that they're missing, such as a deep querying and having a better way to build, describe types and schemas out of the box right now that's something that the community is doing of implementing that. The spec itself doesn't give you that right now. So if your team has just been thinking about how they can write their endpoints in a better useful way, I would consider using JSON API. It's less of an infrastructure cost of moving over and shifting the team and more getting them aligned around certain conventions and making that any nested or wrangled serializers they have more cohesive by knowing what's gonna get returned and how to access that data. So you can, if you have any more questions, feel free to tweet at me or I'm gonna be around. But thank you.