Peko

🪶 Featherweight server toolkit for the modern stateless web 🦕

  Routing     Events     Request handling     Response caching  

API DOCS

Philosophy

• First-class frontend - Server-side render and client-side hydrate with the same code, no enforced tooling.
• Production-ready backend - TypeScript, Response caching (+ more soon).
• Software minimalism - Sleek runtime with no build step. Uses only the Deno std library.
• Ease of adoption - Intuitive API, lots of examples and no fixed project structure.

Read on, please star/fork/clone, and any feature suggestions or code reviews are very welcome!

Get started

Build and launch a secure and scalable webapp from one file 🧑‍💻🌠

Try the example apps:

1. Deno is sick. Install it.

2. $ git clone https://github.com/sebringrose/peko.git
3. $ cd peko
4. $ deno run --allow-net --allow-env --allow-read --watch examples/preact/app.ts

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

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

Deployment

This project aims to be ready for production soon but it is not complete with extensive testing yet! Use at your own risk.

Routing

Requests are matched to a mutable array of Routes. Routes can be added or removed at runtime via the addRoute and removeRoute exports.

Events

Realtime apps can be built with Events. Events are created by Emitters via the .emit method. Emitters can be subscribed to manually Emitter.subscribe or given to the sseHandler to stream Event data to connected clients (see examples/sse).

Request handling

The included staticHandler, ssrHandler and sseHandler serve static assets, render JavaScript apps and stream server-sent events respectively. There are also premade addStaticRoute, addSSRRoute and addSSERoute exports that implement their respective handlers. Of course, you can also create your own handlers plug them into a basic Route (see examples/custom-handler).

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 createResponseCache utility export to create caches and memoize functions to them. The addSSRRoute export does this with the ssrHandler so that Requests can be served from the cache and not unecessarily rerendered (Response cache is indexed by serialized RequestContext).

Tip: Caching Responses from external data services helps keep your app fast and reduce network overhead in serving Requests!

Note: addSSRRoute only caches Responses when config.devMode === false (which is the default config). It is recommended to use the setConfig export to set devMode from an environment variable (see examples/config.ts).

This is cool…

Because it provides all of the SEO and UX benefits of SSR without any JavaScript transpilation or bundling required - the server and browser can use the exact same code. This completely eliminates part of the traditional JavaScript SSR toolchain, increasing project maintainability and simplicity.

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

Peko is 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.

Differences between Next.js, etc.

Peko is built with one radical design decision: no build-step (i.e. no Webpack, no Babel). That means frontend modules must run in the server and browser as source if you want to utilize server-side rendering. You can still use component libraries and other node packages if you import their compiled module distributions. This is all a deliberate step away from the inflated state that many web applications find themselves in… it’s 2022.

This project started in 2020 out of excitement for the elegancy of Deno and the freedom it would bring to the JavaScript community. At time of writing all code has been written and maintained by me. If you are interested in contributing please get in contact.