Peko

  Server     Routing     Request handling     Response caching  

API DOCS

Philosophy

• Client-edge synergy - Share modules for server rendering, consistent data and easy maintenance.

• Production-ready backend - Cascading middlware, auth utils and more, all tested.

• Software minimalism - Built with native JS APIs and Deno std library only.

• Ease of adoption - Intuitive “Express-like” API with no file-system routing.

Any feature suggestions or code reviews are very welcome!

Get started

A secure and scalable webapp in one file 🧑‍💻🌠

Try the examples:

1. Deno is sick. Install it.

2. $ git clone https://github.com/sebringrose/peko.git

3. $ deno task start:dev

Note: Lit-html VS Code plugin recommended if using HTM & Preact.

Import to your project:

import * as Peko from "https://deno.land/x/peko/mod.ts"

and if you don’t want unnecessary utitlies:

import { Server } from "https://deno.land/x/peko/server.ts"

Deployment

Instantly deploy from GitHub with Deno Deploy (fork and deploy the examples if you fancy 💖).

Overview

Server

The Server is the main class of Peko. It wraps Deno’s std/serve and holds all route and middleware data for request handling. Server.use can be used to add global middleware like the popular Express and Koa frameworks. The server.logging function can also be overwritten for remote logging.

Routing

Requests are matched to a mutable array of Routes. Routes are added and configured with their own middleware and handlers via the addRoute, addRoutes, removeRoute or removeRoutes server methods.

Request handling

Each route must have a handler function that generates a Response. The server.requestHandler will execute global middleware in the order they were added first, then route middleware (in order) and then the route handler. If a Response is returned by any middleware along the way it will be sent the client and no subsequent middleware/handler will run.

After responding the server will cascade the RequestContext back through any middleware that implement await next(). If no matching route is found for a request an empty 404 response is sent. If an error occurs in handling a request an empty 500 response is sent. Both of these behaviours can be overwritten with the following middleware:

app.use(ctx => {
    if (!ctx.server.routes.includes(new URL(ctx.request.url).pathname) return new Response("...", { status: 404 })
})

app.use(async (ctx, next) => {
    try {
        await next()
    } catch(e) {
        ctx.server.log(e)
        return new Response("...", { status: 500 })
    }
})

The included staticHandler, ssrHandler and sseHandler handlers can be plugged straight into routes and reduce boilerplate code for serving static assets, rendering client-side apps and streaming CustomEvents for server-sent events respectively (see /examples for implementations). There are also authentication, logging and caching middleware. Of course, you can also create your own middleware or handlers and plug them into your routes!

Response caching

In stateless computing, memory should only be used for source code and disposable cache data. Response caching ensures that we only store data that can be regenerated or refetched. Peko provides a ResponseCache utility for this with configurable item lifespan. The cacher middleware wraps it and provides drop in handler memoization and response caching for your routes.

The modern edge is cool because…

The client-server gap practically disappears. We can have all of the SEO and UX benefits of SSR without any JavaScript transpilation or bundling. We can use modules and classes in the browser until users decide they want cloud compute. If we want TS source we can emit JS versions of code. This completely eliminates part of the traditional JavaScript toolchain, increasing project maintainability and simplicity, all while making our software even faster.

Better yet, Peko is not build for any specific frontend framework or library. You can use barebones HTML, React, Preact, Vue… you name it (if you do set up a React or Vue project please consider opening a PR to the examples). Simply plug your app-rendering logic into the Render function of an ssrHandler.

This is all made possible by powerful new JavaScript tools. Deno is built to the ECMAScript specification. This makes it compatible with browser JavaScript which elimates the need to generate separate client and server JavaScript bundles (the support for URL imports is the secret sauce). UI libraries like Preact combined with htm offer lightning fast client-side hydration with a browser-friendly markup syntax. On top of this Deno has native TypeScript support, a rich runtime API and loads of community tools for your back-end needs.

This project started out of excitement for the elegancy of Deno and the freedom it would bring to the JavaScript community. If you are interested in contributing please submit a PR or get in contact :D