Universal middleware

[cyco130]

Previous discussion was here: honojs/hono#443

[mindplay-dk]

So just to reboot the conversation: I'd like to devise something that relies on dependency injection (a proper platform abstraction) which would simplify both testing and bootstrapping in general.

So here's my current thinking:

// Platform features (file IO etc) is made available to Handlers:

type Platform = {
  glob: (pattern: string) => FileInfo[];
  open: (path: string) => ReadableStream;
  // ...
}

interface FileInfo {
  path: string;
  // ...
}

// Context provides Request-specific dependencies, communication between handlers:

type Context = Record<symbol, unknown>;

// Handlers bootstrap with the Platform, then process Requests and produce Responses:

type Handler = (platform: Platform) => (request: Request, context: Request) => Response;

Thoughts?

[cyco130]

I think a full platform standardization might be out of reach today. But there is a proposed web standard for a filesystem API. I'm not very familiar with it but it might be a starting point.

[mindplay-dk]

No, I don't envision building a complete platform standard - just enough to support interesting and useful middleware, such as a static file server, a disk-based cache or proxy, and so on.

You don't need a ton of things to support those, I don't think?

• glob(path, pattern): string[] to enumerate files in a logical, local file-system
• openRead(path): ReadableStream
• openWrite(path): WritableStream
• fetch for basic network IO
• something for de/compression of streams

We're already basing these new frameworks on the Request and Response models from fetch anyway, and the streams API lives in the same neck of the woods.

Adding support for the FileSystem API might not be totally out of reach though - there's a ponyfill with support for Node and Deno.

I mean, I suppose you could argue the individual handler or middleware could just ship with a factory function, and inject the functions they need - so for example, a static file server might need to be bootstrapped with glob and open functions, and a set of implementations for whatever platforms it currently supports.

But do you think there's enough value in having a standard for handlers then? Most complex middleware would be platform dependent anyway. If effectively all we're standardizing is (Request) => Awaitable<Response> then, as you said previously, that's already a de-facto standard for some projects. If a static file server has to ship with it's own platform-dependent abstractions anyway, what value does this standard provide?

Just a set of framework adapters for (Request) => Awaitable<Response>?

That might have some merit, but it doesn't really seem to be where most of the work (problems) lie for most complex middleware?

[cyco130]

OK, I think a set of minimal filesystem API adapters might be a good starting point before thinking about how to inject the API. It would be a generally useful utility not tied to HatTip or Hono anyway. Obvious candidates for starters:

• Memory (useful for testing but maybe also for serving small, frequently requested files like favicons)
• Node fs
• Deno std/fs
• Cloudflare Workers KV

And for later:

• S3 (or compatible, like Cloudflare R2)
• Redis and similar KV stores
• Browser FileSystem and/or Indexed DB (maybe useful for service workers)

[masx200]

Can we design an adapter from Koa middleware to Hattip middleware?

[magne4000]

I'm currently really interested in solving this issue about universal middlewares (or at least request handlers).

I'm working on Bati which is Vike's new pick-and-choose scaffolder. In Bati, you can choose between multiple server libs, and currently each middleware need to be written manually for each server as there is no common way to represent them.
As you can guess, it's hard to scale and to maintain such architecture, so I'm willing to tackle this issue.

@mindplay-dk I liked the idea of universal handlers, and I think that solving this issue first reduces the scope of maintainability quite drastically in Bati's case.

With universal handlers out of the way, writing custom middlewares for each frameworks could be solved by a lib that creates the right middleware for you (like unplugin does for builders).

I'll soon try to create an "any server middleware" to "generic handler + context" (and vice-versa) as some kind of POC within Bati's codebase a dedicated repo and link it here so that we can discuss real practical implementations, be aware and list all limitations that we can think of, and try to solve them one by one.

NB: Here are the current servers implementations in Bati:

• Hono
• HatTip
• h3
• express

[brillout]

👍

The most widespread term right now in the whole ecosystem is Middleware

Same thought and unfortunately unmiddleware/unimiddleware is a bit (too?) long.

The thing I like about unhandler is that it's clear yet not too long, and there is something appealing to it. Or maybe even unihandler, that's even clearer but I find it a bit less appealing. I also like unimid although it isn't clear on its own.

Anyways, all these options are available as npm pkg & org, so I guess we can go with any of these options.

[brillout]

I would be more in favor of unimid, and I like the sound of it.

I also find that pronoucing unimid out loud sounds nice.

unhandler [...] there is something appealing to it.

More precisely: visually appealing.

[brillout]

Actually, maybe universal-middleware could be an option.

// server.js

import vike from 'vike/universal-middleware'
import telefunc from 'vike/universal-middleware'
import universalMiddleware from 'universal-middleware/express'

app.use(universalMiddleware([vike, telefunc]))

Annoying to type, but crystal clear.

Versus:

// server.js

import vike from 'vike/unimid'
import telefunc from 'vike/unimid'
import unimid from 'unimid/express'

app.use(unimid([vike, telefunc]))

I'd say let's go with what you feel like.

[mindplay-dk]

@brillout I like it! there's enough obscure branding in the JS ecosystem already.

universal-middleware is as clear and unfancy as it can be. 😄

[mindplay-dk]

universal-handler (what @magne4000 is going with) is equally fine btw 🙂👍

[magne4000]

I created a repository to compile some ideas and some code. Feel free to open discussions are create PRs for specific topics.
https://github.com/magne4000/universal-handler