its still in the cards! it will be more like a pretty printer instead of a formatter though. Meaning we will prettify valid code only. but its a bigger effort, and we want to focus on a stable basis first.
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!
Thank you all for showing interest in this project. You described exactly what motivated me to create this language – support for OpenAPI specs. I just wanted to have a language where I could import an OpenAPI spec and leverage the intelligence, because, like you, in all my projects the specs were autogenerated.
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.
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)
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.
+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.
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.
> Even though [Nango] seem to have more integrations
We agree Nango has more integrations and we love OSS software so I'm with you on this. Credit where credit is due and we don't want to make false claims at all. We never claimed to have more integrations than them. I'm not sure how what I posted came off as dishonest.
> but seemingly only for picking out response key if they're strings, not any "pick from object", or "compute based on multiple properties"?)
I'd say we support this perhaps in a different way.
I have not used Nango myself to comment on specific ways it handles data vs how we handle it.
Its great that you're liking Nango and we want OSS/better product to win regardless.
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 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?)