API routes
Edit this pageWhile Server Functions can be a good way to write server-side code for data needed by your UI, sometimes you need to expose API routes. Some reasons for wanting API Routes include:
- There are additional clients that want to share this logic.
- Exposing a GraphQL or tRPC endpoint.
- Exposing a public facing REST API.
- Writing webhooks or auth callback handlers for OAuth.
- Having URLs not serving HTML, but other kinds of documents like PDFs or images.
For these use cases, SolidStart provides a way to write these routes in a way that is easy to understand and maintain. API routes are just similar to other routes and follow the same filename conventions as UI Routes.
The difference between API routes and UI routes is in what you should export from the file. UI routes export a default Solid component, while API Routes do not. Rather, they export functions that are named after the HTTP method that they handle.
API routes are prioritized over page route alternatives.
If you want to have them overlap at the same path remember to use Accept
headers.
Returning without a response in a GET
route will fallback to page route handling.
Writing an API route
To write an API route, you can create a file in a directory.
While you can name this directory anything, it is common to name it api
to indicate that the routes in this directory are for handling API requests:
API routes get passed an APIEvent
object as their first argument.
This object contains:
request
:Request
object representing the request sent by the client.params
: Object that contains the dynamic route parameters. For example, if the route is/api/users/:id
, and the request is made to/api/users/123
, thenparams
will be{ id: 123 }
.fetch
: An internalfetch
function that can be used to make requests to other API routes without worrying about theorigin
of the URL.
An API route is expected to return JSON or a Response
object.
An example of an API route that returns products from a certain category and brand is shown below:
Session management
Since HTTP is a stateless protocol, you need to manage the state of the session on the server. For example, if you want to know who the user is, the most secure way of doing this is through the use of HTTP-only cookies. Cookies are a way to store data in the user's browser that persist in the browser between requests.
The user's request is exposed through the Request
object.
Through parsing the Cookie
header, the cookies can be accessed and any helpers from vinxi/http
can be used to make that a bit easier.
In this example, you can see that the userId
is read from the cookie and then used to look up the user in the store.
For more information on how to use cookies for secure session management, read the session documentation.
Exposing a GraphQL API
SolidStart makes it easy to implement a GraphQL API. GraphQL is a query language for APIs and a runtime for executing those queries by using a type system you define for your data.
To implement a GraphQL API, you need to define a schema and resolvers.
The graphql
function takes a GraphQL schema and returns a function that can be used as an API route handler.
First, to implement a GraphQL API, install the graphql
library.
Following that, you can implement your schema and resolvers in a file and then export a handler function that will be used as the API route:
Exposing a tRPC server route
tRPC is a modern TypeScript-first API framework that is designed to be easy to use and understand.
To expose a tRPC server route, you need to write your router. Once you have written your router, you can put it in a separate file so that you can export the type for your client.
An example of a simple client that you can use to fetch data from your tRPC server is shown below:
Finally, you can use the fetch
adapter to write an API route that acts as the tRPC server.
To learn more about tRPC, you can read the tRPC documentation.