Building Apps

webroute only concerns itself with routes and endpoints. It agnostic to how you might actually build, run or deploy an app.

In many cases this is sufficient, for example when developing serverless functions. However sometimes we require greater orchestration, or integration with other runtimes and frameworks.

Here we will explore some ways our webroutes can be connected to these existing runtimes and frameworks.

To learn more about how webroute differs to these tools, visit the Comparisons page.

Full Stack Frameworks

In full stack frameworks, filesystem routers typically handle routing for us, and work with webroutes simply and idiomatically.

Next.js et al.

webroute works natively with nextjs and similar filesystem routers. Simply export each route in it's designated file.

posts/route.ts

export const GET = myRoute

Bear in mind nextjs file routing determines the HTTP method and path, so specifying a webroute path or method is redundant and will have no effect.

Web Frameworks and Runtimes

The below assumes you have some root handler for requests, which may or may not perform routing.

example-root-handler.ts

const handleRequest = (req: Request): Response => {
	// ...
}

For more detailed advice on how to implement routing, please visit the Routing docs.

Node

While Node has supported the web standard Request and Response classes from v21, it does not provide a standard way to access an incoming HTTP Request.

Until node provides a built-in WinterCG-compliant server, one should use @hono/node-server which converts the traditional node Request/Responses to the web-standard counterpart, on the fly.

import { serve } from '@hono/node-server'
 
serve({ fetch: handleRequest }) // <- Provides us with `Request` and `Response` in node.

Bun

Bun.serve({ fetch: handleRequest })

Deno

Deno.serve(handleRequest)

Cloudflare Workers

The workerd runtime that Cloudflare Workers utilise expects a default export with a fetch property.

export default {
	fetch: handleRequest
}