Build Your Web Framework From Scratch!

Hi. I'm very excited to talk at JS Nation today. My talk title is, Build Your Web Framework from Scratch. My name is Yusuke. I love building web frameworks. I work at Cloudflare as a developer advocate. I'm a creator of Hono.

This is today's agenda. Creating web frameworks is fun. Let's create a web framework. Before I talk about what is a web framework, here are a few things you should know. This framework is built with JavaScript and TypeScript. It works on Cloudflow.

Let's look at an example without a framework. This is the smallest web application you can write. You just return a response from fetch function. You can learn the same code on different runtimes. For example, Cloudflare has Deno or BAN. Just run one of these commands.

This is what you see in your browser when you're using Angular. Just go to localhost 8787 and it shows hello. It works the same on Deno or BAN, too.

But in the application, things get complex very quickly. For example, you need routing like get slash or post slash post, and you have to handle all of that yourself. Writing everything manually becomes long and hard to read due to too many conditions. Instead, think about what we need in a framework: routing, parameters, different response types, and more.

The framework needs to decide actions based on URL path and method, extract values from the URL, and handle different response types. Additionally, it must manage notepads, errors, future rights, authentication, cross-origin, and security. Using a framework like Hono results in shorter, more readable, and maintainable code. It enables quick application development, scalability, and the ability to understand the framework's internal workings by building one yourself.

Instead, let's think, what do we need in a framework? Routing, parameter, different response types and so on. Let me explain them one by one. First, the framework needs to decide what to do based on URL path and method. For example, get slash, post slash post. The framework needs to extract the values from the URL. Like parameters in the path. The framework might return text, JSON, HTML, or even do a re-write depending on the situation. The framework also needs to handle notepads and errors. And in real-world application, future rights, authentication, cross-origin, and security things are essential. This is the same example as before. But written in Hono. It's much shorter and readable and easy to maintain. This is the benefit of using a framework. So, this is the framework. It's short, easy, and very readable. With it, you can build an application really quickly and it even scales well when your application gets bigger. You can use Hono, but let's build one yourself. That way, you can see how it works inside and you can see building your own framework is really fun.

Next, let's talk about returning response. Here's our first step. Let's make a function called create app. It's just an object with a fetch method. And this method returns a response. This is the simplest structure for a framework. We call create app. And it returns an object. This object has this fetch method. So, when the request comes in, it will go to fetch and we get the response. So, now, do we return a response? It's simple. We just return the response.

And you can customize it. Set headers, set status. And you can also use static methods like response.json or response.redirect.

When we build a framework, the most basic thing is to take a request and return a response. To do this, we need a function. We call it a handler. The user can define a handler using this setter. The handler is the word internally and the fetch code.

If there is no handler, the framework returns not one. So, here's how it works in the code. This is this defined handler. And this is the setter of the handler. It stores the handler function inside.

When a request comes in, it calls the handler. If no handler is set, it returns nothing. Defining a handler using app.handler results in a new response. By default, the status is set to 200 and the content type to text/plain. To return HTML, set the content type to text/HTML. Customizing the status is possible by using methods like response.json, which returns a JSON response with the correct headers, or response.redirect for a redirect response.

Returning a response involves writing a handler that allows customization of status and headers. Additional helper methods can simplify this process. Moving on to routing, the framework currently handles a single route. In real-world applications, responses vary based on the path and method. For instance, GET / should return the main page, GET /welcome should display the welcome page, and POST /post should create a new post.

URL patterns are instrumental in this process, supporting wildcards and path parameters. The syntax is similar to path-to-regex used in Express, and patterns can be created using new URLs with specific path names. For example, setting the path name as /post/:ID allows for testing with /post, resulting in the first response.

We can customize things like status and headers and use helper methods to simplify the process. Moving on to routing, the framework currently handles only one route, but in real-world applications, different responses are needed based on paths and methods. For instance, GET / should return the homepage, GET /welcome the welcome page, and POST /post to create a new post. URL patterns with wildcards and path parameters, similar to Express's path-to-regex, offer flexibility in routing.

API works on Cloudflare, Cardino, and Node.js, allowing the use of wildcards and path parameters. Creating patterns using new URLs with specific path names, such as /post/:ID, enables testing and matching routes. The framework is ready to incorporate routing with URL patterns, defining route types with HTTP methods, URL patterns, and handler functions. Updating the create app function to include methods like on (for storing routes based on URL pattern) and fetch (to match and call handlers) completes the routing feature implementation.

This process allows for handling routing efficiently. The on method stores routes based on methods, paths, and handlers, while the fetch method matches incoming requests with defined routes. If a match is found, the corresponding handler is called, ensuring proper routing. Utilizing these features facilitates the creation of a functional web framework with the ability to handle multiple routes and responses based on specific paths and methods effectively.

It's syntax based on path to regex that is used in Express. We can create a pattern using a new URL with a path name. This sets the path name as slash post slash colon ID. When we test with slash, it returns first. But slash post slash one to three matches. So, it returns true.

Now we are ready to add routing with URL patterns. Let's make a framework with routing. We define the route type that includes the HTTP method and URL pattern and the handler function. Now, we update the create app function. It returns an app object that has two methods, on and fetch. We define the on method. It takes the method, path, handler, and stores them as a route using the URL pattern.

The fetch method goes through all routes, checks if the method and URL match the route, and calls the handler if there's a match. If not a match, it returns 'not found.' This is how you use the routing feature we just built. You define the method, path, and handler using the on method. We built response handling and routing. Now, let's make sure they work as expected. Let's write some tests. To test our application, we can create a request and pass it to app.fetch. The application returns a response object, so we can check its contents like status or body.

Let's write some tests. To test our application, we can create request and pass it to app.fetch. The application returns a response object. So, we can check its contents, like status or body. Here's a basic test. We register the routes, then create a request, and pass it to app.fetch. We get a response. We can check the status and body.

What's interesting is you don't need to run the server on localhost; it's just a regular function call. For example, you can test it. By the way, Hono has over 20,000 lines of test code, and most of them follow the same pattern. We now have routing in our framework. We define routes using on, match them with the URL pattern, and handle them in fetch, and we can test it.

Next, let's get data from the request. When we handle a request, we often need to get information from the URL, like path or query strings. We can use the request object to get the URL. Just pass the URL property into the URL constructor to access it. We can access the path name property. We use URL pattern.exec to get the match result. Then, we retrieve the path parameter ID, 123, from match.passname groups. We use URL search params to get query parameters, like page 4, 5, 6.

Then we get the pass parameter ID, 123, from match.passname groups. We use URL search params to get query params, like page 4, 5, 6. We want to pass things like request and match info to the handler. Instead of passing them separately, we wrap them into a single object. This object is called context, and it's easy to extend later. Here's how we define context type. It includes request and match result. Then we use that as the input for the handler function.

In fetch, we find the route that matches URL and method. We create context and pass it to the handler. Here's how we use the context in DR handler. Inside of the context, we have match result from this is URL pattern result, using that, we can get the pass parameter and query parameter. I'll summarize this section. We can get data from requests by running URL.exec. From this match result, we can get both pass and query parameters. We then pass them to the handler inside the context.

Now let's make our framework more powerful by adding middleware. Middleware learns before and after the handler. It can change the request or the response, and you can reuse it across routes. Here are some examples of middleware. These are from Hono, and they show how powerful and reusable middleware can be. From authentication to validation to caching, middleware can do a lot. Sometimes middleware needs to store some values or change the response before returning it. So, let's extend the context to make that possible. We add two more fields to the context. This lets us modify the response before returning. And this bars is a place to store values across middleware. We pass the both lists into the context. We define lists before the loop so that handler can update. And we return the response after the loop.

Here's how we use lists and bar in practice. The first middleware starts values in bars. The main handler creates the response using stored value. This, the last middleware, modifies the response before returning it. Middleware is a function that learns before and after the handler. It can be used to modify requests, the response, or add useful values. And we designed the context object to hold the key data that the handler needs, like requests, the response object, and customized values.

Let's add the helper feature to our framework. A helper is a reusable function that provides useful logic, like rendering HTML. It receives context so it can access things like requests or response. These are examples from Hono. You can see it has many built-in helpers, like cookies, Jot, HTML, and more. Let's define helpers in our framework. We extend the context type with helper object. The application will have maps of helpers. Each helper is a function that gets context and helper's parameters.

Then in fetch, we pass the helper to the context. Now, instantly in Handler, you can access it as C.helper. Here's how to define a helper called HTML. And this is how to use in Handler. You can call C.helper or HTML to return a new response with HTML contents. If you set the types property, TypeScript will give you autocomplete for your helpers. It's a small feature, but it improves DX a lot. Let's summarize the helper feature. A helper is a reusable function that receives context. You define them in our create app and access them using C.helper. Inside your Handler, if you define the types correctly, you get autocomplete and types safely. Let's look at some practical examples using our framework. Here, we get the path parameter ID and the query parameter page. Then we return JSON response using response.json.

Here, we turn the parameter logic into helpers. Inside the results, we just call C.helper params or C.helper search params. This makes the Handler cleaner and the helper logic reusable. This example combines multiple features. We define HTML helper and set values in middleware and then use both in Handler. After that, another middleware modifies response helpers. This shows how helpers, contexts, and middleware work together.

This is very interesting. This helper lets do server-side rendering with React. It uses render to read a stream and return HTML response. Now, you can use JSX directly in your Handler. We've now completed all the steps. So, you've built the basics, but there are more you could do. You can improve middleware and helpers or even integrate with real projects like Hono.

Let's wrap up. You built your web framework. The application with your framework can return responses, define routes, get data from requests, and even use middleware and helpers. You just reinvented the wheel, but building your web framework is actually really fun. That's all. Thank you so much.