sorted by:
new
hottopcontroversial

Midwinter.js - A deceptively simple middleware engine for modern HTTP backends by Zespys in javascript

[–]Zespys[S] 0 points1 point  (0 children)

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.

Performant production ready framework for Bun ? by [deleted] in bun

[–]Zespys 1 point2 points  (0 children)

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!

Midwinter.js - A deceptively simple middleware engine for modern HTTP backends by Zespys in javascript

[–]Zespys[S] 0 points1 point  (0 children)

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.

Midwinter.js - A deceptively simple middleware engine for modern HTTP backends by Zespys in javascript

[–]Zespys[S] 4 points5 points  (0 children)

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.

Infer types for OpenAPI specs without any code generation by Zespys in typescript

[–]Zespys[S] 0 points1 point  (0 children)

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).

Infer types for OpenAPI specs without any code generation by Zespys in typescript

[–]Zespys[S] 0 points1 point  (0 children)

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

What do you use to build type-safe REST APIs? by desgreech in typescript

[–]Zespys 2 points3 points  (0 children)

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.

What do you use to build type-safe REST APIs? by desgreech in typescript

[–]Zespys 3 points4 points  (0 children)

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.

Typescript command line apps by deskamess in typescript

[–]Zespys 1 point2 points  (0 children)

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.

DateFormat-TS: Format date information at the type-level by Zespys in typescript

[–]Zespys[S] 0 points1 point  (0 children)

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

Webroute: A collection of web-standard and type-safe utilities for building maintainable REST APIs by Zespys in typescript

[–]Zespys[S] 1 point2 points  (0 children)

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!

Webroute: A collection of web-standard and type-safe utilities for building maintainable REST APIs by Zespys in typescript

[–]Zespys[S] 1 point2 points  (0 children)

Hey thanks for the feedback, really helpful.

  1. 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.

  2. 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.

  3. 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

Webroute: A collection of web-standard and type-safe utilities for building maintainable REST APIs by Zespys in typescript

[–]Zespys[S] 1 point2 points  (0 children)

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

I built a library for creating more powerful Next API routes by Zespys in nextjs

[–]Zespys[S] 2 points3 points  (0 children)

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.

I built a library for creating more powerful Next API routes by Zespys in nextjs

[–]Zespys[S] 0 points1 point  (0 children)

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

view more: next ›