Show HN: Ductape – Build back end integrations once, reuse them anywhere | Hacker News Reader

Show HN: Ductape – Build back end integrations once, reuse them anywhere

ductape.app

29 pointsIfedayo_s19 comments

Hey HN, We built Ductape to make backend integrations reusable and environment-agnostic.

You define the logic once (e.g. payments, auth, notifications) and externalize provider-specific stuff like API keys, endpoints, and retries into a config.

That logic can then be reused across services, projects, and environments without rewriting code.

It’s like decoupling your service logic from your infrastructure. You can even switch providers by changing config, not code.

We’re using it to save time, reduce bugs, and simplify service expansion. Curious what you think.

We’ve been building quietly and are now coming out of stealth with our public beta. We’d love your feedback

You can try it at www.ductape.app

Join our Discord — https://discord.gg/JHXxQ6MAwb We’re there to chat, answer questions.

Happy to answer anything below..

Open articleView on HN

I also don't understand what your product actually does. What would help me: an example + diagram of a solution before and after the use of Ductape. How does this change things? The more detailed, the better (less marketing language, more example code / diagrams).

So say you have multiple services that often need to process payments. For example, you have a billing service, a subscription service, and a checkout service, each responsible for handling different parts of the payment flow. Typically, these services integrate directly with a payment provider such as Adyen, Stripe, or Braintree. You have to duplicate logic across these services.

They all have to handle authentication, retries, error handling, and webhook processing separately. You have to manually configure and update and test across envs.

So if you want to make a change, you'll have to go into each service and rework the integration logic.

With Ductape, instead of embedding provider-specific logic in every service, you write it once and configuration files handle the differences between environments and providers. So you can use same logic across your billing, subscription, and checkout services without duplication.

If you want to switch providers, you don’t touch the logic at all. You just update the configuration.

The concept of what you describe is interesting and useful. I struggle to make the same conclusion from the website, it feels like it is written as too abstract to allow the reader to grasp exactly what you will get. Was the text improved by an LLM?

It would be great to have a simple example or a scenario or a hello world for someone to say “Aha! I get what it is and how it can help me”

Oh thank you. The website was made much earlier. I had to get a frontend person to build it and I'm not really good at frontend design so I have to get another person to rework it. Thank you very much for this feedback.

Your explanation in this post makes a lot more to me than your site.

I will rework the website. Thank you so much for the feedback. It's should have used the link for the docs instead.

To the folks who are confused what this does, a very similar product with clearer positioning is https://nango.dev (also a cool product and team I'd recommend)

Nango also seems to be source available, that sold it for me

Its under the elastic license...

can you please tell me if this license bad or good in terms of open sourced-ness and where does it really fall on the spectrum.

So this is like a bunch of patterns + implementation library of those patterns + PaaS runtime for that library? It is very hard to read this, but it seems it is similar to the library we use internally in our company to do this. Ours is very opinionated (this looks like this also) so we never thought of making it a product as it wouldn't fit in other companies, or so we figured.

Maybe I didn't see it and it is there (there is a Lot of text), but I think having the npm and Frontpage should link to a directory of actual, full examples would be good.

There's a use cases page.

https://www.ductape.app/use-cases

Can you explain what you mean by opinionated? We've tried to make this as flexible as possible

I read a bunch of docs and still didn't understand what this does...

So what it does is it lets you write your integration logic (like payments, auth, or KYC) once and reuse it across all your backend services, environments, and providers without duplicating code.

For example instead of putting Braintree or stripe code in every service, you write one chargeCustomer() function in Ductape and call it from anywhere. If you want to switch to another provider, you just change a config file, not your code.

All these integration/workflow products (Nango, Ductape, n8n, Camunda, etc) reminds me of SnapLogic, which have been there for years and years.

Just my 2 cents.

Still trying to understand what this does… I think you need a demo vid front and center.

Thank you! I'll keep that in mind. In case you want to see a demo, for now you can check out this link here: https://vimeo.com/1082963222/e6d52b9b31

Is there support for a backend that isn’t defined by a Postman or Swagger API? That’s the hard part…

Initially we support just Postman and Swagger but we plan on expanding to new services as we grow. We also work on allowing people define their endpoints (although we think that might be even more stressful)

Website does not work. Can't click on any menu items on safari.

Pls can you try again? It should work now.

Reply on news.ycombinator.com