I think formatting/prettier-type functionality was mentioned as a possibility of this project, is that still in the cards?

(I can’t seem to find a formatter that understands stored procedure; does it even exist?)

If you come across issues or can think of anything that would improve it, please let me know :)

Im a bit flabbergasted I haven’t yet found a HTTP/API client that simply runs off an oAPI spec. Sure, most support «import of..», but do any support oAPI’s as continuously evolving source of truth?

Our oAPI spec is auto-generated (based off ts-rest.com contracts), and I’d love one that understands this, including auto-refreshing/importing of spec when it changes on disk.

If anyone knows of this magical piece of software, please share!

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.

I considered Atlas as well, but I didn't like the idea of using HCL to define SQL; The srtd approach is just SQL, so aside from setup, there's nothing new to learn.

The downside of srtd vs Atlas is that Atlas (seemingly) can do your whole schema, including tables, indexes, etc. srtd only works well for idempotent operations (aka can re-run multiple times without producing a different result)

1. The iteration cycle for database functions was needlessly complex. Some variation of this workflow was common:

  - Find existing function/view/policy/etc in past migrations
  - Copy to SQL editor
  - Make changes 
  - Test
  - Copy back to migration file
  - Repeat

I have searched for tools/workflows to address this, but have came up short. (https://news.ycombinator.com/item?id=36007640, https://news.ycombinator.com/item?id=37755076)

So, over the holidays I paired with Claude to make SRTD (Supabase Repeatable Template Definitions), addressing these issues with a template-based workflow:

    # Make a template with safely repeatable SQL
    echo "-- some idempotent sql" >> supabase/migrations-templates/my_function.sql
    
    # Edit your SQL templates, changes auto-apply to local DB
    npx @t1mmen/srtd watch
    
    # Generate standard Supabase migrations when ready
    npx @t1mmen/srtd build

   * Live-reload for SQL templates (great for functions, policies, views, etc)
   * Single source of truth for database objects, with history/functional git blame.
   * Standard (Supabase) migrations as output
   * Safe iteration with WIP templates that never generate migrations (.wip.sql)

Happy to accept PR or issues for other migration file formats (or even DBs).

Project: https://github.com/t1mmen/srtd

Would love to hear your thoughts, feedback, and ideas for improvement!

Comments URL: https://news.ycombinator.com/item?id=42643628

Points: 1

# Comments: 3

It works great for eliminating the «what did I actually work on X days ago?» problem (that used to be the bane of my existence)

Disclaimer: I work at Timely

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

In any case, I wish you the best of luck with the "one model per resource type" concept you're trying. It's a tricky one, since you're usually stuck with the lower common denominator.

I expect many, if not most users will need additional custom mapping (so if "field A" -> "field B" mapping is the only option for now, expect to run into lots of feature requests that need to pick from objects/compute multiple values into one field. DX around this will be important)

Please correct me if I'm wrong, but you say...

> Even though [Nango] seem to have more integrations

Nango has north of 100 integrations, Revert seems to have 4 atm?

> our integration support is better than them in terms of the depth of use-cases allowed (more standard objects supported, custom properties, field mapping support, custom objects (soon) etc).

How so?

Nango Sync gets you easy access to the raw API responses from the 3rd party service, and lets you map that to whatever shape/model you, as the implementer, want to end up with.

Revert seems to return standardized/normalized objects per data model (e.g, company, contact, task) across the 4 different integrations currently mentioned. It also seems to support "custom mapping" past the "lowest common denominator" schema, by adding `sourceFieldName` -> `targetFieldName` mappings (but seemingly only for picking out response key if they're strings, not any "pick from object", or "compute based on multiple properties"?)

Please don't take this as discouragement -- it's a great space to play in, and there's a lot of room for improvement. But, as a _very_ happy user of Nango over the past 10+ months, I feel you should compare yourself honestly at the very least.

Good luck!

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.

The barrier you presume is that OpenAPI specs are hard to write. Raw oAPI in yaml is indeed a pain, but there are good DSL's out there.

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)

The great thing about OAPI is there's _so much tooling_ available, but it can be daunting and very frustrating to find the "right one". I spent more hours than I'd care to count wading through the ecosystem,

Perhaps it'd be a good idea to promote a few tools via your project? I suspect many potential users would fall off early because they (imo wrongly) believe the upfront cost of writing the OAPI spec is too much to ask. I do understand the reaction if they don't know of good DSLs, though.

IMO, https://openapistack.co/docs/examples/building-apis/#writing... would be a good place to add that.

PS: ts-rest's video on the front page is what immediately convinced me to try it out. Your current interactive example is nice, _but_ it doesn't product type errors for me so the value isn't as immediately obvious (I'm assuming watch doesn't work in the sandbox?).

I'm a huge fan of this general concept, so you're definitely on the right path imo. That said, two things are jumping out at me:

- Users would still be writing OpenAPI specs/JSON Schema by hand, an incredibly annoying and tedious process (unless using a nicer DSL)

- Generation/build steps are annoying (but likely unavoidable here)

As pointed out by many other comments, an unfortunate amount of teams aren't writing OAPI specs. I personally feel this is a major mistake for anyone building an API, but that's a discussion for another day.

I've been using https://www.ts-rest.com, a similar project, for a few months now. Instead of relying on OpenAPI specs as the source, you define the "contracts" using Zod. These contracts are essentially OpenAPI specs, but Zod makes for a MUCH better DSL. I really like that...

- Real-time type checking without generator steps, both server & client-side. XHR clients like `fetch`, `react-query`, etc clients are inferred from the contract.

- The Zod contracts _can_ generate/output OpenAPI specs and Mock Service Worker mocks for testing (as needed, not required)

- (Optional) Automatic request & response validation based on Zod contract definitions, no additional code needed.

- (Node) Backend agnostic (partially, anyway: NextJS, Express, Nest and Fastify supported atm)

- Works very well with `react-hook-form` & `ZodResolver`, so e.g an invalid value on client-side shows the same error as the API would have if request were fired.

- Zod types can be used as typescript (z.infer), a wonderful way to re-use e.g model types in client-side components.

This ts-rest experience has fundamentally solidified a belief in me: One single source of truth, propagating through the system, is _the_ best way to build safely and efficiently.

I am almost ashamed to look back on the many, many projects I've worked on where APIs and client-side did not share truth. Duplication of (hand-rolled) types, error messages, etc is horrific in retrospect.

I don't want to think about the amount of bugs I've come across due to this dual (at best) truth approach.

It’s usually best to stick with a “normal schedule” for family/socializing reasons, anyway.

But, it’s incredibly freeing, being able to work when the mood strikes. I used to be a night-owl, often getting super creative in the evenings. I could force myself to bed, sure, but a 3-4 hour stint in the evening would regularly produced outsized returns. 8-9am+ couldn’t remotely compete, creativity-wise, so why force it? Build a culture around trust and impact, it works out a lot better than anything else I’ve seen in practice.

I rarely do late nights anymore, having transitioned to 6-7am starts, an hour or two hiking around lunch with the dogs, and a small handful of hours of wrapping up & planning for tomorrow. But that was all my choice :)

This isn't just lip-service, either. May be hard to believe from a US perspective, but for a Norwegian based company, it can be taken at face value. It's the best place I've worked in my 22+ years.

Minor asterisk; we do have a few hours every week where you should be present (check-ins, meetings, all-hands, etc), but it's <5h/week for most people.

I imagine the only people who would think otherwise have some pretty dysfunctional repo setups and/or policies.