t1mmen

Really excited about trying this, great job so far!

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

Oh, fun to see my project mentioned on HN! I’m glad to see it’s useful to others :)

Thank you, I’m glad to hear it works well for others too!

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

100%, this.

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!

https://github.com/t1mmen/srtd might help here. The general idea is to define functions/policies/etc as «SQL templates», your source of truth. The templates built into Supabase migrations.

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.

You're very welcome, hope it helps you!

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)

If you’re flexible on the time tracker to use, www.timely.com tracks GitHub activity (and so much more, entirely privately).

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

I’m grateful to have the option if and when the time comes. Even before that age, QoL needs to be of a certain level or possible to improve, else I’m unsubscribing.

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

+1. Linear is a great PM tool, maybe even the best. What makes it awesome is their support team. I’ve been in touch with them a handful of times over the past ~5 years, and each time, they’ve been excellent — fast response times, with genuine and tech savvy people on the other side.

/* WIP */

Yeah, sorry, I just got caught up in your wording. Since you asked: "Nango seems to have more integrations" feels disingenuous, when you're comparing 4 to 100+. You'll likely be asked to compare yourself with Nango a lot, so it's not a bad idea to know what you're up against.

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)

I love these kinds of products, and welcome any competition in the space. But, this comparison to Nango doesn't seem accurate, so I feel inclined to comment.

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!

Really cool setup, thanks for sharing!

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.

Strong disagree.

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)

Good point, and one that counts towards ts-rest atm; If you're bringing your own OpenAPI spec, there is (not yet) an OpenAPI->Zod converter available.

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

Cool to see more of these kinds of projects, nice work OP!

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.

In reality, most people are working core hours, say 10am-3pm local time. Most are in UTC +/- 2 hours. I’m an outlier, remote from B.C, Canada.

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

Yes, everyone at my $WORKPLACE is free to adjust their work schedule to whatever best suits them; we don't care about ass-in-seat or hours of work, we care about output and impact.

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.

It’s blatantly obvious that the quote from the article isn’t talking about pushing to #main and potentially breaking production during the weekend. If a team practices true CI/CD, they surely have excellent safeguards and 1-click (if not automated) rollbacks in place.

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

Weird take. Since when does “pushing code” equal “releasing to production”?

FWIW, I love this mentality for healthy, work/life-balanced teams. It works if you structure around it. I often get the itch during the weekend to do a little work, so I go for it, because I can balance my days as I see fit. Ride the wave of creativity when it arrives, go do something else — like taking a hike, or running errands — when you can’t get shit done.

Oh, that’s unfortunate.

I’m not too keen on sponsoring an alternative when the dev doesn’t particularly care about the feature — it didn’t work out last I tried something similar. But, perhaps there’s another path: Supabase.

They are in (imo) desperate need of better migration tooling, and they sponsor several open source projects that boost their over-all offering.

AFAIK, they haven’t done much in the migration space yet (aside from their alpha db branching feature), so I expect they’ll co-opt an open source solution at some point soon. May be worth pinging them? Seems it could be a win-win there.

Thanks! I’ll give it a look (their docs are offline atm)

DrizzleKit and several others do this for table changes, but nothing I’ve found (possibly excluding Flyway and other Java options) do views/functions/etc.

I’ve looked everywhere for this in NodeJS & adjacent stacks; almost all migration tools seem to focus on tables, columns and rows. None seem to deal with views, functions, triggers.

I only got back into Postgres this year, after almost a decade away from SQL. It’s kind of bizarre to me that the migration tooling is still at the stage where a 1 line change to eg a Postgres function requires a the whole function to be dropped and re-created?

I understand this is needed at the db level, but surely a “definition” that generates the final migration is doable; it would make such a huge difference in code reviews and to understand how a function/etc changed over time.

Am I just looking in the wrong place? Does this exist? If not, how come? Is it really that hard to do?

20 years ago, Steam was the reason I stopped pirating games. Netflix et al had the same effect for TV & movies.

Today, I subscribe to 5 different streaming services, and occasionally do a month of various “channels” in those apps.

I want to pay for content, but the camels back is about to break. I truly don’t want to set sails again, but the bullshit has been adding up for a while. Ads is where I draw the line.

I've got all of 30 minutes of experience with https://www.cursor.sh, but this appears to be another major upgrade to my workflow. In-context editing by AI, without any of the copy/paste annoyances.

The PR I'm currently working on has about 1K diffs – I've literally touched NONE of that code directly. Freakin' wild!

I suppose I have adapted quite a bit, but it’s just a different path to the same style of code/modularity I’ve found most effective/productive.

I was primarily FE for a while, and used to agonize over the smallest details when building eg React components. After a few years, I concluded that the innards don’t really matter most of the time, at least not early on, so I limited my obsessions to the “public interface” (naming, types and prop design) and libraries of well abstracted, composable, low-level building blocks. If and when things needed to be rewritten or optimized, replace the internals.

ChatGPT just gets me there faster, and more often than not, gives me acceptable production-level innards while I get to stay focused on perfecting the exterior and cohesiveness of the overall solution.

I’ve found this approach usually pays dividend when reworking parts of the system, too — GPT picks up on the flow of everything much better when the code is “self documenting”. Same appears true if humans need to get directly involved.

Still blows my mind on a daily that we’re here already. I’m glad I’m not early in my career, I’d be very worried if I had another 40 years to go.

Oh sweet! I was in a bit of a hurry and must’ve missed it, thanks for clarifying. This will be super helpful for us, very excited play with it!

This looks really cool, congrats on the launch!

I haven’t had time to dig in proper, but this seems like something that would fit perfectly for “local dev” logging as well. I struggled to find a good solution for this, ending up Winston -> JSON, with a simpler “dump to terminal” script running.

(The app I’m building does a ton of “in the background” work, and I wanted to present both “user interactions” and “background worker” logs in context)

I don’t see Winston being supported as a transport, but presumably easy to add/contribute.

Good luck!

I agree, but purists can be their own worst enemy. Prompting is still a bit of an art, but I’m sure it’ll get better. Still, seems silly to not leverage one of the greatest tool upgrades we’ve seen in decades. There’s plenty of interesting problems to solve, why waste time on the boring parts anymore?

Don’t get me wrong — I think this’ll be the end of MANY jobs within almost every field in the next decades, ours included. But I sure as shit can’t beat it, so may as well join it and get something out of it before I become just a commodity.

I use both Copilot and chat with GPT4. For now, it’s mostly copy/pasting large blocks of pre-existing code, types, etc. I have a pre-defined prompt set up to explain how to behave, languages I know, libraries in use, naming conventions, how to respond, etc.

I talk GPT as if it’s a skilled colleague who’s got memory issues. When it forgets, I remind it with stuff like “this is our current code now, remember X, Y, Z”

I’ve become an even bigger fan of small, compostable functions that do one thing very well. GTP excels at that, both writing and testing them.

I don’t involve it much for architecture and high-level design atm (mostly because I got that part solved on my current project). I tend to have a design in mind, give GPT the overview of how it fits together with mock code, and ask it to review with me, propose other paths we could take, etc before proceeding to implement.

One function at the time, with tests. When refactoring happens, it’s usually isolated to a few hundred lines at most. When tests fail, directly or indirectly, I give it the full output and ask it to debug and fix. I find this helps GPT remember the code’s responsibilities when it gets lost/forgets. It also helps me avoid regressions when GPT returns functions that miss use cases we had covered before.

I keep long running chat threads — weeks at times, hundreds or even thousands of messages. The longer we go, the better it tends to perform (web app performance, even on an M2 Studio, does suffer after a while though)

At worst, GPT is a fantastic rubber duck. At best, it’ll help me see superior approaches and solutions I wouldn’t have considered, AND give me perfect code in seconds.

Once tooling gets really good, and AI can understand the whole code base/database/infra… we’ll probably be in real trouble.