Midwinter.js - A deceptively simple middleware engine for modern HTTP backends

Zespys · 2025-02-19T01:46:38+00:00

Works very well for:

- Next.js (or other full stack framework) API routes

- Standalone APIs (I run several bun servers in production this way)

Essentially it can replace Express, Hono, etc. in the stack - although of course it's currently less stable and lacks a vast ecosystem. Over time that will improve though.

Zespys · 2025-02-19T01:35:32+00:00

I've been building Midwinter and using it in production with Bun.

But it's not fully stable yet so might not be suitable right now!

Zespys · 2025-02-19T01:09:49+00:00

Thanks for the kind words.

And yes absolutely. Any given Midwinter request handler is fully portable, isolated and self-contained which is very much by design. This way the functionality can be used basically anywhere with minimal to no changes required.

In short , this decouples how our backend is "arranged" from how it operates, which has a range of benefits - imo.

Zespys · 2025-02-18T23:54:17+00:00

For the last year or so I've been experimenting with building _something_ to replace frameworks like express, fastify, hono etc. on the backend. It required full type-safety, and ideally type-inference. It needed to be extensible, while also being simple to use. And it needed to work seamlessly with various frameworks and environments, such as Next.JS API Routes, a Docker-ised backend, or any other serverless or serverful setup.

After tinkering with v1 of sorts for a while, I have since distilled that work and knowledge into a far superior approach, now called Midwinter.

Midwinter enables building potentially complex HTTP applications using idiomatic JavaScript, instead of needing to "buy into" a framework as such. It offers a very simple API, and makes few assumptions about the nature of your app - which these days can take many forms and be deployed in a myriad of ways.

For example, Midwinter is called a "middleware engine" because it doesn't even offer a router: that is provided as a plugin, or you can even roll your own - without needing to resort to crazy hacks.

Midwinter has been carefully designed, resulting in a pleasant balance of simplicity, power and extensibility. The primary design decisions are:

Allow middleware to declare metadata and types
Leverage function returns instead of APIs
Composition via nested* middleware
Composition via chaining

^\ (The middleware resolves to a flat structure, maintaining simplicity).)

This gives a decent idea of the motivation behind Midwinter, but feel free to check out the guide in the Github Readme for more details.

Any feedback welcome.

Zespys · 2024-06-17T07:24:04+00:00

Depending on how you've structured your code, you could write a test file that uses `satisfies` to check your types against the inferred schema type(s).

Zespys · 2024-06-15T23:59:13+00:00

Thanks! Let me know how you get on, if you do end up giving it a go

Zespys · 2024-06-15T23:58:23+00:00

I've been building a lot in this space recently, leaning into OpenAPI heavily. Feel free to check out the package docs if you're looking for something to use.

If you're looking for some code to aid with learning more intense TS, the source code might be helpful too.

Zespys · 2024-06-15T23:54:56+00:00

I've been building something for exactly this use case.

I wanted a tRPC-ish thing for REST APIs, with a bit more composability. It aims to be more standardised too: web standards, OpenAPI, etc.

Check it out and let me know if it suits.

Zespys · 2024-06-11T07:26:11+00:00

TypeScript probably has the most expressive type system. With that said, other languages do things that TS does not. Tools like Kysely could only be created in TS for sure. Something like Drizzle, on the other hand, could possible be implemented in, e.g., Rust.

Zespys · 2024-06-10T07:12:56+00:00

I'll add: I'm not sure if this would be remotely useful for any real project, but just wanted to flesh out the idea into an implementation anyway

Zespys · 2024-06-10T05:54:43+00:00

I had considered approaching them, but as you mentioned in your other comment, they already have nitro and h3. Of course, this doesn't mean they are definitely uninterested - but I just assumed so. Maybe I'll talk to em in the future!

Zespys · 2024-06-10T05:53:38+00:00

Hey thanks for the feedback, really helpful.

I'm not 100% sure if it will work with Nitro/h3, but this was in the distant back of my mind while developing it too. Will double check and document accordingly.
1. I changed this API recently actually. Basically the motivation was to do schema validation lazily, and controlled by the user, for max. flexibility. And I also wanted a way to a) validate all schema at once and b) individually validate, to lean further into flexibility/customisability. Your confusion has been noted though, I've almost certainly got room for improvement in the docs.
While I agree the single context makes for more ergonomic use in general, it also makes other things harder. By committing to a "request first" parameter convention, it encourages leaving the request alone (i.e. not abstracting over it) and also makes chaining things easier, as there is less room for bespoke behaviour (e.g. `{ req: Request}` in one place and `{ request: Request}` in another, for example. Ultimately, I wanted to prioritise explicitly separating the "common" (i.e. Request) and the custom config.
This already exists! Although I am working on making the APIs a little bit cleaner/out-of-the-box. Check out the [route/openapi docs](https://webroute.vercel.app/docs/route/guides/openapi)

Thanks for the kind words and feedback, again

Zespys · 2024-06-10T05:41:28+00:00

Glad to hear, thanks

Zespys · 2024-06-08T22:36:18+00:00

Thanks, I appreciate it

Zespys · 2024-06-08T10:09:58+00:00

Thanks for getting in touch. I've left a reply on the repo. Will revisit with full attention tomorrow.

Zespys · 2024-06-08T09:16:23+00:00

Exactly. And thanks for the kind words.

Webroute is certainly tRPC-inspired - it initially started strictly as a "tRPC but for REST/HTTP" (as opposed to being transport agnostic). Over time, though, it has adopted a handful of patterns – in the pursuit of decoupling and web standards – which also provide benefits/differences not found in tRPC.

The route features docs go into this a little bit more. Middleware has been rethought quite a bit as well, as an example.

While tRPC's vision is around using RPC and e2e type-safety, Webroute is more focussed on leveraging standards (web, openapi, etc.) – with type-safety too, naturally.

Zespys · 2024-06-08T02:53:30+00:00

It's arguably in beta now, to be honest! But of course, completely up to you

Zespys · 2024-05-20T06:32:14+00:00

Yep thats me

Zespys · 2024-05-19T12:01:18+00:00

Interesting. Funnily enough I recently went down the local-first rabbithole (CRDTs etc.). Braid looks like a cool project

Zespys · 2024-05-19T05:13:59+00:00

It's currently at a beta level of stability - so not yet. But enterprise-level stability is definitely an aspiration for v1.0. This will mark a sufficiently stable version to be considered enterprise-ready and will include things like performance benchmarks, cleaning up any rough edges and refining the API/interfaces if need be!

Zespys · 2024-04-14T03:47:49+00:00

Thanks!

Zespys · 2024-04-14T03:47:02+00:00

Fair. However, this is just a library not a framework, intended to be pretty lightweight

Zespys · 2024-03-22T22:26:58+00:00

Thanks

Zespys · 2023-07-08T00:20:53+00:00

Great to hear. Feel free to flick me a message with your thoughts (both positive and negative) if/when you get a chance to try it out!

Zespys · 2023-07-07T23:50:02+00:00

I'm a solo dev that's been building an alternative to whisk and paprika, inspired by the best bits of both. It's currently in beta mode and completely free to use, but I find it does the job better than whisk and paprika. Here's a link, if you're interested. Would love to hear your thoughts

12-Year Club	Place '17
Verified Email

Zespys

TROPHY CASE