API Routes

[00:00:00]
>> Yap, API Routes, okay. So, back to routing, check this out. So, if you want to have an API for your app, you don't have to go make a whole another server or use a background as a language, or do any of that stuff, you get basically service routing for free.

[00:00:18]
All you have to do is just make a route, and now you have an API, it's pretty simple. So inside of our app folder, we need to make another special folder inside of here called API. And then within this folder, it's equivalent to the rest of the folders, you just make another folder that represents a segment, and you need a special file in there.

[00:00:42]
In the case of pages, the special file is called page, in the case of an API, the special file is called route. So if I go into the API folder and let's say our todo app is also friendly for developers who want to integrate with their todos. We're gonna make some routes for them to pull and do crud on their own todos.

[00:01:00]
So let's make a new folder for api/todos, or let's say /todo. And then for that I want a route.ts not TSX, it's not a JSX file, it's it's a regular JavaScript file, so route.ts. And then inside of here, all I have to do is export different HTTP verbs that I want to run when the matching one is requested.

[00:01:27]
So in this case, let's say I want to allow someone to do a get request to /api/todo, I would export a function called get. If I want them to do a post request, I would export a function called post, this is a little different than next day as 12.

[00:01:40]
If you've ever seen it before next day as 12, you just exported a function that had a request and a response, and you had to handle that logic internally on whatever verb they sent. You had to look at the rec, dot method to determine if it was a post or put a get, and then do the routing yourself.

[00:01:56]
Whereas with here, you just export the function with the appropriate verb name and that's handled for you, so you don't have to think about it. The other difference is like, you didn't have to just like pages, you didn't have a route that js or ts? You just named the file, whatever the route you wanted, but now it has to be route inside the folder.

[00:02:18]
And the function kind of looks like this, as long as you export it, you're good, so let's check it out. So let's just say I want someone to be able to do a get request to /api/ todo, no problem. I can say export const, get like this. And yeah, now we can do whatever we want here.

[00:02:40]
So you're gonna get access to a request object, which is a requests standard object from the Fetch API. This is web standard request object, this isn't something next Jas had which in the previous version actually has this request object was like something that they made. And you had to look it up and it was kind of like to express but it wasn't and it was very it confused me a lot because it didn't, It was trying to be like everything else, but it also was very different.

[00:03:07]
This is just a standard request object straight from MDN, I mean, if we go look at this, this has nothing to do with next js, it's just a request object, which I think is cool. So if you ever start like writing code on the edge, like a edge run time, you'll be using this a lot, but it's basically the same request that you might have if you were using fetch, if you did it that way.

[00:03:28]
So I like that you might not have done it this way, you might have explicitly made a request, but the fact that this is a standard, I think that's really cool. Because I'd rather work with standards than framework specific things. So I do like next.js direction of like, let's move towards standard specific APIs which is really cool, and I think they kind of really had to since node.js or next.js has many different run times now.

[00:03:50]
We didn't talk about it, but you can run on a server, you can also run on the edge. If you don't know what an edge is, a CDN is a group of computers dispersed all across the world, and when I make a request to yourwebsite.com. If you have a CDN, my request gets routed to the computer closest to me, so that means your website is copied across many different computers.

[00:04:14]
Traditionally, you could have only put read-only data on those computers, like files that were already compiled and you could read it. Now you can compute on those computers, so you can run functions on those computers and do dynamic things, which is really powerful. So if your origin server is over here, and you have all these nodes around the world and someone from Oregon is trying to hit your server, they get redirected to the computer in Oregon.

[00:04:35]
In which you can do some preliminary logic there, maybe you check for off, maybe you do some routing. Maybe you look at their IP address and look it up to see and see that there are Coca Cola so then you rewrite to the landing page to say hi from Coca Cola, you can do whatever you want, right?

[00:04:49]
You can do that now and it's really interesting, so next year is allows you to do that too. So you can just change the runtime of things for basically free, depending on where you deploy it to. And in that runtime, you have to use something like request. You have to use something like the the built-in standards because those runtimes are so light that they don't support full of node.js environments, so they very specific things like this.

[00:05:17]
Cool okay, so we wanna do that we have a request, and then from here I mean you could pretty much do whatever you want in the request. In this case, actually, let's send something back, so lemme show you an example, so let's say I want to send back a response.

[00:05:32]
So what you can do is you can just say return, then you have this thing called next response like this. So this is actually just a wrapper around the response objects from the MDM standard, so if I look for this, there's also a response here. The next response is just a wrapper around that, and I think they did that because there was some TypeScript issues, I think it was specifically for TypeScript.

[00:06:00]
So you can do the next response like this, and then you can respond back whatever you want, I'm gonna respond back with some json, and be like message hello, so I can do that, right? Do a get request, I'm not even gonna use this. So now I'm able to go to /api/todo do a get request, you go to the browser and do that, that's a git request, so let's try that.

[00:06:23]
I'm 3001, you might be something else, so todo or todo todo, so we'll do that. And I get back a response message hello, and that was it, I just made a server as made API route. So if you've ever had to set up API route before you just like, wow, this is a lot, well, okay, you get it for free now, you just make a file, and a verb and you have API now, which is pretty cool.

[00:06:49]
So when you deploy this, this is gonna be in a serverless environment. It's such a misleading name, it's definitely a server there, all it does is you don't have anything running constantly, you just have a function that when a certain route/ in this case, verb. As well and this can actually just really route when a certain route gets triggered, that function gets read into memory and then execute it responds back and then shuts down.

[00:07:16]
For the most part, there are like some performance techniques around keeping functions warm, because reading the file is a cold start and that causes performance issues. So is basically just an infrastructure around, trying to make it to where you don't need to worry about scaling issues. So if you ever had to deploy a server, and then scale it cuz you got all these requests, what if you didn't have to do that?

[00:07:39]
What if everybody had their own instance of a function that was running, you'd have to worry about scaling and it was just infinitely scalable? And that's the promise of serverless but the funny thing is,yeah, go ahead.
>> So that kind of like a lambda, a function that runs when you call it?

[00:07:52]
>> Yeah, 100, a lambda is literally the first serverless function, that's what AWS calls their serverless function, lambdas. So they invented serverless functions, and then everyone has their own version of that these days, but at the end of the day, they're called serverless functions. But the funny story is like, forgot what division of Amazon just came out and said some some division of Amazon was a customer of AWS.

[00:08:16]
Which I think is already funny how their customers are their own company. But like, yeah, we used Amazon, we use serverless, we use lambdas for a while, but then we switched to just a traditional monolith server and we saved 90% of our cost. And I was like, damn, [LAUGH] I thought service was supposed to be cheap.

[00:08:31]
But then I looked at their architecture, and I'm like, well, okay, yeah, their architecture was insane, they were doing service for one job, it was like a million function calls running. Not that much, but a lot to where it's like, yeah, you guys should probably just use a monolith server, this isn't really meant for you guys.

[00:08:46]
So, it was pretty funny that that happened, and then that they would publish that, they're like, yeah, serverless sucks, we didn't use it, sorry. But we did use this other thing from Amazon, so I guess it worked out. So yeah, you get that for free, let's say we wanna do a post request, we can do that, right?

[00:09:04]
So I can say, yeah, let me post something there, if you want to get the data from the post request, typically, you do like rec.body or something like that in express. Now, this is a request object, so you don't do that, so you'll get the data, and that will be on requests.json, you have to await it, then you can get the data, and that's the equivalent of getting the data off the body.

[00:09:25]
So you don't have to set up middleware here, no body parser, none of that stuff, you just write a function and it's free, which is really cool. So you can get that data, and I guess I'll just echo that data back like this, you do whatever you want, so now if you wanna post this, I'm just gonna open up my thunder client here.

[00:09:42]
Make a new request to, http//localhost 3001/api/todo, make sure that's a post, add in some json here, and I'll just call this, Hello there, then I can post that, and you can see back, I get back exactly what I posted. Hello there, hello where? I'll get back that. Hello where, right?

[00:10:15]
So post request works, pretty simple, I mean, there are some limits in service environments, but you probably don't need to know about them right now, and if you needed to. If you ran into that problem, you can look it up, it also depends on where you deploy it.

[00:10:29]
But for the most part, that is how you would make service functions in next yes, it's actually quite simple.