+TITLE: Talk #+ROAM_ALIAS:

• tags::

• Hook

• Intro For someone like me, who started their development career with monolithic, database backed web applications like Drupal and Django, moving to React was a little disconcerting.

React has amazing patterns and practices around state and re-rendering and all the browser based operations - but the wrangling of the data, before it hits out app, is left largely up to us as developers.

Building a tool like Johns Hopkins Covid Dashboard relies on fetching and processing a lot of data points.

We need to query the data - possibly from multiple sources, parse the data - to make it readable, exclude unnecessary information, get it in the right form, carry out heavy calculations, cache the data - so we don't overload our data centers unnecessarily and only then do we render the data and update it based on user interactions.

Doing this all in the browser has an impact on the experience of our users and so we offload the grunt work to servers.

There are other reasons custom servers are useful. Creating and maintaining connections to databases, contacting APIs and keeping our details safe from our web browsing client and maintaining data security are all high on the list.

You can build your custom server in any language you'd like - but, with Next API routes, do you even need this anymore?

I'm going to look at 3 specific use cases of an Express custom server and map those to Next API routes.

• What are Next API routes? You're here because you use or have heard of Next. I think Next is great - from file-based routing to server side rendering - there are lots of things I love about Next - but I think my favourite is API routes.

Any JS file that is in your /pages/api directory will be transformed into an API route on deployment. Each route will be served by a serverless function which receives requests and delivers responses.

If you've ever worked with Express, then the style of handler will be very familar to you:

// /pages/api/hello.js
export default function handler(req, res) {
  return res.send("Hello!")
}
```

We export the handler as our default function which takes the request and the response object. Our handler will call out to other services, interpret and verify our request, while building and finally delivering our response.

The response object has helper functions that are also familiar from Express:

- res.status(code) - set the HTTP status code of the response.
- res.json(json) - Send a JSON response.
- res.send(body) - Sends the HTTP response. The body can be a string, an object or a Buffer.
- res.redirect([status,] path) - Redirects to a specified path or URL. The status must be a valid HTTP status code. If not specified, status defaults to "307" "Found".

  And the file based routing means we can use the URL path to extract parameters. Like in normal page routes, square brackets are used to represent dynamic routes.

``` javascript
// /pages/hello/[name].js
export default function handler(req, res) {
  const name = req.query.name || "there";
  return res.send(`Hello ${name}!`)
}
```

Getting these API routes deployed with Vercel is as straightforward as running vercel or vercel --prod if it's not a new project.

Let's see how to migrate one class of use cases from our Express custom server to our Next API routes.
* Keeping secrets


* Maintaining database connections


* Authentication


* Conclusion