Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/joeltg/next-rest
Typesafe REST APIs for Next.js
https://github.com/joeltg/next-rest
api nextjs rest typescript
Last synced: 5 days ago
JSON representation
Typesafe REST APIs for Next.js
- Host: GitHub
- URL: https://github.com/joeltg/next-rest
- Owner: joeltg
- License: mit
- Created: 2020-10-31T15:06:42.000Z (about 4 years ago)
- Default Branch: main
- Last Pushed: 2023-03-19T00:54:27.000Z (over 1 year ago)
- Last Synced: 2024-11-02T23:33:25.079Z (13 days ago)
- Topics: api, nextjs, rest, typescript
- Language: JavaScript
- Homepage:
- Size: 4.05 MB
- Stars: 19
- Watchers: 4
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# next-rest
[](https://github.com/RichardLitt/standard-readme) [](https://opensource.org/licenses/MIT) [](https://www.npmjs.com/package/next-rest) 
Typesafe REST APIs for Next.js.
## Table of Contents
- [Background](#background)
- [Install](#install)
- [Usage](#usage)
- [Defining runtime types](#defining-runtime-types)
- [Augmenting the API module](#augmenting-the-api-module)
- [Exporting the route handler](#exporting-the-route-handler)
- [Using the API client](#using-the-api-client)
- [Error handling](#error-handling)
- [Contributing](#contributing)
- [License](#license)
## Background
This library is a framework for writing **end-to-end** typesafe JSON REST APIs for Next.js in TypeScript.
Features:
- **Modularity**. Instead of making you define all of your route types in one place, next-rest uses module augmentation so that you can declare each route's type in their own respective file. All of the logic for an API route `/api/foo/bar` is contained in the `/pages/api/foo/bar.ts` page.
- **Minimalism**. The client API is 100 lines and just calls `fetch` like you'd expect. next-rest has one non-dev dependency on [http-status-codes](https://www.npmjs.com/package/http-status-codes). All validation happens on the server; using next-rest won't cause your validation library to get bundled into the client.
- **Safety**: next-rest lets you write APIs where the URL parameters, request headers, request body, response headers, and response body are all (!!) strongly typed for each combination of route and method. All of your API calls get typechecked at compile-time by TypeScript _and_ validated at runtime on the server.
Limitations:
- **JSON-only**. next-rest is JSON-only.
- **Internal use only**. next-rest is designed for implementing and calling REST APIs **within** a single Next.js application. You can't export your API types, or import a different project's API types. If _that's_ what you're after, you probably want something like [restyped](https://github.com/rawrmaan/restyped/).
- Requires TypeScript 4.4+, Next.js 12+, and React 17+
## Install
```
npm i next-rest
```
## Usage
There are four basic steps. Most of the work happens inside the API route pages - once you've set those up right, you can just `import api from "next-rest/client"` from any client page or component and things will work like magic.
### Defining runtime types
next-rest is designed to be used in conjunction with a validation library like [io-ts](https://github.com/gcanti/io-ts), [runtypes](https://github.com/pelotom/runtypes), or [zod](https://github.com/vriad/zod). Anything that supports a) static type inference and b) gives you [type predicates](https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards) for your types will work. The code samples here use io-ts.
Let's write a route `/api/widgets/[id]` that supports `GET` and `DELETE` methods. The first thing we have to do is make io-ts codecs for our request headers and response bodies. For methods that don't accept content in the request body, we'll use `t.void`.
```ts
// pages/api/widget/[id].ts
import * as t from "io-ts"
const getRequestHeaders = t.type({ accept: t.literal("application/json") })
const getRequestBody = t.void
const deleteRequestHeaders = t.type({ "if-unmodified-since": t.string })
const deleteRequestBody = t.void
```
These serve as "runtime representations" of types. We also need type-level versions of those types, which we can get with the `t.TypeOf` utility type.
```ts
// pages/api/widget/[id].ts
type GetRequestHeaders = t.TypeOf
type GetRequestBody = t.TypeOf
type DeleteRequestHeaders = t.TypeOf
type DeleteRequestBody = t.TypeOf
```
Lastly, we need types for our response headers and response bodies. These don't need to be validated at runtime (since it's the server that sends them), so we can just write them as normal TypeScript types.
```ts
// pages/api/widget/[id].ts
type GetResponseHeaders = {
"content-type": "application/json"
"last-modified": string
}
type GetResponseBody = {
id: string
isGizmo: boolean
}
type DeleteResponseHeaders = {}
type DeleteResponseBody = void
```
### Augmenting the API module
The central problem in designing a end-to-end typesafe API is finding a way to share types between server and client code without sharing anything else (ie without accidentally bundling actual server code into the client). We do this with next-rest by augmenting the `API` type in the `next-rest` module inside every API route page. These augmentations get merged and the client code in `next-rest/client` is able to access the merged API type by also importing `next-rest`.
```ts
// pages/api/widget/[id].ts
declare module "next-rest" {
interface API {
"/api/widgets/[id]": Route<{
GET: {
request: {
headers: GetRequestHeaders
body: GetRequestBody
}
response: {
headers: GetResponseHeaders
body: GetResponseBody
}
}
DELETE: {
request: {
headers: DeleteRequestHeaders
body: DeleteRequestBody
}
response: {
headers: DeleteResponseHeaders
body: DeleteResponseBody
}
}
}>
}
}
```
Notice that the each entry is wrapped in a `Route<...>`. The `Route` type is just defined as `Route = T` and is just used to typecheck the method implementation. You don't have to `import` or `export` the `API` or `Route` types inside the `declare module "next-rest" { ... }` block; they're already in the module scope.
### Exporting the route handler
The last thing to do in each server-side API route page is export the actual API handler. Next.js expects the default export to be a function `(req: NextApiRequest, res: NextApiResponse) => void` which we create by calling the `makeHandler` method exported frun `next-rest/server`.
`makeHandler` takes a string API route as its first argument. The second argument is a configuration object that contains - for each method supported by the route - [custom type predicates](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates) for the request headers and bodies, and an `exec` method implementing the actual handler for that method at that route.
You should be able to get custom type predicates from your runtime validation library. For io-ts, they're the `.is` property of the codec, like `getRequestHeaders.is: (value: unknown) => value is { accept: "application/json" })`.
Implementing the exec method is where the magic starts kicking in: it takes a single `{ params, headers, body }` argument, but you don't have to declare any types. TypeScript knows to infer `params` from the route path parametrizing `makeHandler` (!!) and to infer `headers` and `body` from the augmented API module.
The exec method must return a Promise resolving to an object `{ headers, body }`. TypeScript will already know to expect the correct response headers and response body types and will complain if you don't provide them.
```ts
// pages/api/widget/[id].ts
import { makeHandler } from "next-rest/server"
export default makeHandler("/api/widgets/[id]", {
GET: {
headers: getRequestHeaders.is,
body: getRequestBody.is,
exec: async ({ params, headers, body }) => {
// TypeScript knows the types for all of these!
// - var params: { id: string }
// - var headers: { accept: "application/json" }
// - var body: void
// ... do implementation stuff
const { isGizmo, updatedAt } = await prisma.widgets.findUnique({
where: { id: params.id },
select: { isGizmo: true, updatedAt },
})
return {
headers: {
"content-type": "application/json",
"last-modified": new Date(updatedAt).toUTCString(),
},
body: { id: params.id, isGizmo },
}
},
},
DELETE: {
headers: deleteRequestHeaders.is,
body: deleteRequestBody.is,
exec: async ({ params, headers, body }) => {
// TypeScript knows the types for all of these too!
// - var params: { id: string }
// - var headers: { "if-unmodified-since": string }
// - var body: void
// ... do implementation stuff
const updatedAt = new Date(headers["if-unmodified-since"]).toISOString()
const { count } = await prisma.widgets.deleteMany({
where: { id: params.id, updatedAt: { lte: updatedAt } },
})
return { headers: {}, body: undefined }
},
},
})
```
Putting it all together, our complete sample API route page `pages/api/widget/[id].ts` looks like this:
```ts
import * as t from "io-ts"
import { makeHandler } from "next-rest/server"
const getRequestHeaders = t.type({ accept: t.literal("application/json") })
const getRequestBody = t.void
const deleteRequestHeaders = t.type({ "if-unmodified-since": t.string })
const deleteRequestBody = t.void
type GetRequestHeaders = t.TypeOf
type GetRequestBody = t.TypeOf
type GetResponseHeaders = {
"content-type": "application/json"
"last-modified": string
}
type GetResponseBody = { id: string; isGizmo: boolean }
type DeleteRequestHeaders = t.TypeOf
type DeleteRequestBody = t.TypeOf
type DeleteResponseHeaders = {}
type DeleteResponseBody = void
declare module "next-rest" {
interface API {
"/api/widgets/[id]": Route<{
GET: {
request: {
headers: GetRequestHeaders
body: GetRequestBody
}
response: {
headers: GetResponseHeaders
body: GetResponseBody
}
}
DELETE: {
request: {
headers: DeleteRequestHeaders
body: DeleteRequestBody
}
response: {
headers: DeleteResponseHeaders
body: DeleteResponseBody
}
}
}>
}
}
export default makeHandler("/api/widgets/[id]", {
GET: {
headers: getRequestHeaders.is,
body: getRequestBody.is,
exec: async ({ params, headers, body }) => {
// ... method implementation
return {
headers: { "content-type": "application/json" },
body: { id: params.id, isGizmo: false },
}
},
},
DELETE: {
headers: deleteRequestHeaders.is,
body: deleteRequestBody.is,
exec: async ({ params, headers, body }) => {
// ... method implementation
return { headers: {}, body: undefined }
},
},
})
```
### Using the API client
Now that we've implemented our route on the server and augmented the `next-rest` module, we can start using the client API!
The client api is the default export of `next-rest/client`, and it's an object of functions for every HTTP method. This means you invoke the api like this:
```ts
import api from "next-rest/client"
api.get("/api/widgets/[id]", { params: { id }, headers, body })
api.delete("/api/widgets/[id]", { params: { id }, headers, body })
```
The first argument to the method function is the API route **without** any dynamic route parameters - e.g. `/api/widgets/[id]`, not `/api/widgets/81903281`. The second argument is an object with `params`, `headers`, and `body` properties. The `params` object is where you provide values for the dynamic route (`{ id: "81903281" }`).
Here's an example component page at `components/widget.ts` that renders a widget and has a button that lets the user refresh the widget's `.isGizmo` property.
```tsx
// components/widget.ts
import React, { useCallback } from "react"
import api from "next-rest/client"
interface WidgetProps {
id: string
isGizmo: boolean
}
export function Widget(props: WidgetProps) {
const [isGizmo, setIsGizmo] = useState(props.isGizmo)
const [isChecking, setIsChecking] = useState(false)
const checkGizmoStatus = useCallback(() => {
setIsChecking(true)
api
.get("/api/widgets/[id]", {
params: { id: params.id },
headers: { accept: "application/json" },
body: undefined,
})
.then(({ headers, body }) => {
// TypeScript knows these types!
// - var headers: { "content-type": "application/json" }
// - var body: { id: string; isGizmo: boolean }
setIsGizmo(body.isGizmo)
})
.catch(() => alert("could not check gizmo status"))
.finally(() => setIsChecking(false))
}, [])
return (
i'm a widget!
and i {isGizmo ? "am" : "am NOT"} a gizmo
)
}
```
Notice the total lack of type annotation around the API call! In fact, as soon as you start typing `api.get`, you'll see something like this:
TypeScript knows which API routes support GET requests - in this case there's just one - so it'll offer to autocomplete them for you. And once you select one, TypeScript will parametrize the rest of the API call with the types for that specific method:
... and when we get our result, TypeScript knows what's inside our response headers and body as well:
### Error handling
If you throw an error from inside a method implementation on the server (ie inside one of your `exec` functions), next-rest will by default respond to the request with status code 500. If you want to control this, you can import `ServerError` from `next-rest/server` and throw one of those instead:
```ts
declare class ServerError extends Error {
readonly status: number
constructor(status: number, message: string)
}
```
For example, we could modify our DELETE implementation to return a more informative status code in cases where the `if-unmodified-since` condition fails:
```ts
// pages/api/widget/[id].ts
import { StatusCodes } from "http-status-codes"
import { makeHandler, ServerError } from "next-rest/server"
export default makeHandler("/api/widgets/[id]", {
// ...
DELETE: {
headers: deleteRequestHeaders.is,
body: deleteRequestBody.is,
exec: async ({ params, headers, body }) => {
const updatedAt = new Date(headers["if-unmodified-since"]).toISOString()
const { count } = await prisma.widgets.deleteMany({
where: { id: params.id, updatedAt: { lte: updatedAt } },
})
if (count === 0) {
// This will cause next-rest to set the response status code to 412
throw new ServerError(
StatusCodes.PRECONDITION_FAILED,
"you've got stale data, man!!"
)
}
return { headers: {}, body: undefined }
},
},
})
```
There is a symmetric class `ClientError` exported from `next-rest/client` that we can use to handle this on the client as well.
```ts
class ClientError extends Error {
readonly status: number
constructor(status: number, message: string)
}
```
If the client receives any response other than 200, it will throw an instance of `ClientError` containing the status code and the response body as text.
```ts
import { StatusCodes } from "http-status-codes"
import api, { ClientError } from "next-rest/client"
function deleteWidget(id: string, updatedAt: string) {
api
.delete("/api/widgets/[id]", {
params: { id },
headers: { "if-unmodified-since": new Date(updatedAt).toUTCString() },
body: undefined,
})
.then(({ headers, body }) => alert("widget deleted successfully"))
.catch((err) => {
if (
err instanceof ClientError &&
err.status === StatusCodes.PRECONDITION_FAILED
) {
console.error(err.message) // "you've got stale data, man!!"
alert(
"could not delete widget because the request was made with stale data"
)
} else {
alert("unknown error while deleting widget")
}
})
}
```
## Contributing
If you find a bug or have a suggestion, feel free to open an issue to discuss it!
## License
MIT © 2020 Joel Gustafson