Comment by zicon35 | Hacker News Reader

Comment by zicon35 | Hacker News Reader

Hi HN! Allen & Jatin here, co-founders of Revert.dev

Integrations require a lot more engineering time, resources, and ongoing maintenance than you would first expect.

When building your own integrations you have to deal with challenges, such as: - unreliable third party integration endpoints, which fail or hang more often than you think; - monitoring and reliability of the integration code; dealing with different schemas, gotchas, rate-limits of the various APIs you integrate with. - You need to do this all alongside maintaining your own code base.

This is what we’re solving for at Revert.

With Revert you can ship a reliable product integration in under 2 days, and we take care of all of the above and more.

- We current support CRMs such as Salesforce, Hubspot, ZohoCRM & Pipedrive through our APIs.

- We also support Slack (in beta) alongside Discord that will be supported this week. Our roadmap is public — https://github.com/revertinc/revert/issues?q=is%3Aissue+is%3...

- We’re open-source (https://github.com/revertinc/revert) and want to build the project with the community in the open. If you’d like an integration you can add one & welcome contributions!

Would love to get the community’s feedback.

Nice! We could be in the market for something like this soon.

What’s your quick pitch for why someone should use Revert vs competitors like Merge.dev and Nango?

* vs Nango - we think they have great support for OAuth management and do support more APIs than ours on the surface (atleast at the moment).

Nango is based on Pizzly an existing OSS project which they built on top of. We're building it from the ground up.

Even though they seem to have more integrations, 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).

A few prospects of ours tried out Nango for this use-case and then came to us eventually.

* vs Merge - we'd be able to fly past the number of integrations offered by them being an OSS product especially because of community contributed integrations. Being a developer first product, open-source is the way to build the best product in this category.

Integrations inevitably have edge cases that you would run into and you as a customer might require Merge to behave in a certain way. The typical response at a closed-source SaaS company would be that its on "their roadmap", never to get back again. This holds you tightly with their roadmap velocity and you're locked into a vendor.

Being an open-source product you, the engineer, will be able to fix or add integrations right away in the worst case if nothing else. This way of operating is very powerful we think.

Also, we don't cost you an arm and a leg :)

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!

Hi! Thanks for your comment.

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

https://www.nango.dev founder here.

I think the biggest difference is that Nango lets you customize & extend the unified APIs on the platform.

Usually unified APIs mitigate their limited catalog with passthrough/proxy requests. But this is a partial solution, since you go back to having a lot of integration logic in your code base.

With Nango these customizations live in the unified API itself and benefit from all the infrastructure available there (OAuth, rate-limit handling, pagination, de-duplication of records, etc.). You can also build entirely custom integrations in Nango.

That being said, I think open-source unified APIs have a ton of promise! It is great to see the ecosystem grow :)

We agree on the promise for sure! :)

Do you have any resources for the planning/architecting phase of developing a unified API like this?

I work in a similar space, but for physical hardware, and one challenge we've frequently encountered is the somewhat massive variety of how our vendors handle certain tasks behaviorally within their platform.

Not sure about your use-case but I'm happy to help and share the learnings we've had so far in the technical aspects of building Revert.

Maybe just a book a time with us or DM us Twitter and we can take it from there?

I live deep in the enterprise world. A quick search shows no outstanding/pending integrations with Concur, Ariba, Successfactors, SAP BTP etc.

Hello! The platform we're building is quite generic to support these integrations.

Happy to take issues here and we could prioritise them based on the interest of our current customers/prospects: https://github.com/revertinc/revert/issues

Looks interesting, out of curiosity - what made you decide to go open source?

The pricing page (https://www.revert.dev/#pricing) doesn't even mention it ("self-hosted" or "community" or something like that). Or is that intentional to cater different audience?

Hi, open-source/community edition is free and you can just host it via docker compose in your own infra. We're adding that to the pricing page as well very soon.

We believe an open source unified API enables us to cover the long tail of third party APIs while empowering engineers to customise the integration code we offer out of the box.

This way engineers can use us over building an integration from scratch. Even if that means that they use the self-hosted version and not the hosted version that we have.

The other aspect of this is that our community is helping us build integrations much faster.

Our customers (i.e, developers) can also help us build a better product. This way it helps everyone in the long run and developers are not repeating this work again and again!

Reply on news.ycombinator.com