t1mmen

While developing, srtd can hot/live reload your templates into the local db when changed.

I built this to scratch my own itch, and it’s been working VERY well for us. Huge DX benefits, and it’s made code reviews a LOT easier, since the reviewer can focus on what’s actually changed.

Much preferred to, say, ættestup: https://youtu.be/DwD7f5ZWhAk?si=WjwnN7cZC1h7TcJU

After buying in to OpenAPI as the fundamental source of truth (generated via https://www.ts-rest.com contracts in my case), I have radically changed how I think about web development.

At this point, it's frankly absurd to me how many people out there make it so hard for themselves by manually building/typing/validating both client & server-side responsibilities in most typical REST setups. I get it -- I spent >2 decades in that reality, but no more. I will die on this hill.

I am likely understating the impact when I say I'm 2x as productive whenever I touch API related functionality/validation on client or server-side.

MSW, Zod, react-hook-form+ZodResolver and several other tools in the OpenAPI ecosystem are simply incredible for productivity. The project I'm on now is certainly the most fun I've ever built because of these amazing tools.

I personally love Zod->OpenAPI, via https://ts-rest.com which uses https://www.npmjs.com/package/@anatine/zod-openapi. https://github.com/asteasolutions/zod-to-openapi is another alternative for Zod.

> The big bonus of the human documentation approaches today is that time is somewhat combined with building the client.

This is wild to me; human documentation is absurdly error-prone and it's almost always and immediately out of date. (Zod or other DSL) -> OpenAPI -> generated docs (and types! and clients! and mocks!) are always going to be better; always accurate, and faster. The upfront cost is slightly higher, but the ROI is _significant_.

OpenAPI specs lend themselves to excellent docs, ala Mintify or Docusaurus. Even interactive ones, like Swagger UI. The vast majority of API browsers & tooling understands OAPI, so why re-create (an often incomplete) version of the truth when using those tools?

> Whatever is overall fastest and gets me on to the problems I'm really trying to solve.

You may start (slightly) faster, but you'll incur significant cost when you move past the "trivial implementation" stage.

For instance:

- Do you do request & response validation on the server? That'll often need duplication on the client (e.g, error messages, and once out of sync, client-side validation mismatches server-side response)

- Typescript on client & server? Then you're already doing the manual work (often more than once) that oAPI->types would get you for free.

- Implementing client-side XHR calls manually, and getting typing right, is a pretty significant undertaking. Multiply that by the number of client-side stacks the API will be consumed by. Or, just generate them via OAPI (or real-time infer via something like ts-rest)

- TS on client, but another BE stack? OpenAPI, when used right, ensures the "contract" is 1:1. When BE changes, client needs changing -- or it breaks. You want this safety.

- Manually mocking API responses is wasteful; write good oAPI specs and auto-generate mocks (e.g, MSW).

- Do you test the real API implementation? OpenAPI specs can help you do that automatically.

At this stage of my career, I would turn down a job offer from a company/team that wasn't willing to use OpenAPI or equivalent single-source-of-truth (*unless I'm in a truly desperate situation)