[HN Gopher] Launch HN: Nango (YC W23) - Source-available unified...
___________________________________________________________________
Launch HN: Nango (YC W23) - Source-available unified API
Hey everyone, we are Bastien and Robin from Nango
(https://www.nango.dev). We take care of the annoyances of external
APIs (167 and counting) so you can quickly build custom
integrations for your SaaS, while retaining full control over how
they work. 2 min demo video:
https://www.loom.com/share/d04c67b47e284e86b91b4b99fba548ec SaaS
engineering teams face a tough choice: they can build each
integration in-house from scratch, which gives them full control
but takes a lot of time and maintenance effort. Or they can use
pre-built solutions, which are fast and easy but less flexible and
might not fulfill all customer needs. Nango combines the best of
both worlds. We let you quickly ship custom integrations without
building complex infrastructure or diving deep into the quirks of
each API. You control the business logic, data models, and
customer-specific configurations, like custom field mappings. We
handle (O)Auth and run your integrations reliably in production.
Under the hood, your integrations run as typescript "lambdas" on
Nango. A typical integration has 3-5 lambdas of 20-50 lines of code
each. These lambdas live inside your git repo, are version-
controlled with the rest of your app, and get deployed to Nango
with a CLI (https://docs.nango.dev/understand/core-concepts). Our
runtime has a built-in scheduler for continuous background syncs,
monitoring to know if your integrations run as expected, detailed
logging of everything that happens in Nango, and pre-built
infrastructure to deal with (O)auth, retries, rate-limit handling,
webhook floods, data caching, de-duplication, etc. More here:
https://docs.nango.dev/understand/architecture We have found that
ChatGPT and Copilot let you build integrations on Nango very fast
without having to learn each API's intricacies. LLMs are great at
figuring out which endpoint to use, what parameters it takes, etc.
Paired with our runtime, this lets you build complex, high-scale
integrations in hours instead of weeks. We've put a ton of effort
into dealing with API complexities, so you don't have to. Even
integrations that looked simple at first ended up forcing us to
extend our infra to deal with their quirks and gotchas. For
example, we had to figure out 100+ different OAuth implementations
(see https://www.nango.dev/blog/why-is-oauth-still-hard and
https://news.ycombinator.com/item?id=35713518). We had to deal with
a half-dozen non-standard auth methods (Github apps, Stripe apps,
Netsuite, etc.), expiring webhooks, ways to deal with data
dependencies, weird pagination methods, API keys that change with
every API call, dozens of different ways to register for webhooks,
etc. It's a constantly moving target, but it is a challenge we have
come to love, and we think the approach makes sense: we specialize
in finicky details that vary from API to API--you specialize in
making your product great and offering more integrations to your
users. Last but not least, Nango is open source
(https://github.com/NangoHQ/nango) under the ELv2 license (allows
most use cases, except for direct copy-cats). Anybody can
contribute new APIs & share their integration templates with the
community. The fastest way to see Nango in action is with our
interactive demo here (no signup required):
https://app.nango.dev/hn-demo Or take a look at our docs:
https://docs.nango.dev We would love to hear your feedback and
look forward to the comments!
Author : rguldener
Score : 138 points
Date : 2024-04-25 15:09 UTC (7 hours ago)
| nextworddev wrote:
| This is really great work, I will try it out. How do I reach out
| if I have questions?
| rguldener wrote:
| We are very active on the Slack community:
| https://nango.dev/slack
| icy wrote:
| Obligatory mention of ELv2 _not_ being open source (not OSI
| approved!).
| brap wrote:
| I spent about 5 minutes (incl watching the demo) and I still
| don't quite understand what this does.
|
| I'm probably not in your target audience, so maybe the issue is
| with me. But I think you should consider clarifying the use-case
| and value a bit.
|
| It's one of those things that should probably be immediately
| obvious to anyone working on SaaS. I was curious so I spent some
| time on it, potential customers may not be as forgiving and might
| give you just 10-20 seconds.
| stuartjohnson12 wrote:
| I'm in the target audience and still don't fully understand,
| although I do think the market needs more tools like this.
|
| Generally speaking, the value prop for tools in this space
| tends to be that they map similar data concepts from lots of
| providers into one API so that it's faster to build
| interoperability. For example, if you're shipping a project
| management tools integration, every tool has the equivalent of
| a ticket and a project and a label regardless of what they call
| it.
|
| What I /think/ this tool does is go one layer further and
| provide cloud-based orchestration for chained integration calls
| with appropriate failover and observability hooks built in
| automatically. Which is a sensible tool I think the market is
| hurting for.
|
| But I could be wrong, and that's concerning.
| conqrr wrote:
| Their front page is quite clear. Haven't seen the demo though.
| Its a unified API for all Integrations that your Saas can have.
| Typical Saas has integrations with a lot of other Saas and its
| like a web of complexity that you have to build from scratch.
| With Unified API you integrate with one API and it can give you
| things like auth, data, syncing from Github, twitter, Google,
| etc
| spxneo wrote:
| Doesn't that already exist? I'm also not sure what the
| edge/value proposition is.
|
| If I need API integration done, there are already MIT
| licensed programmatic solutions that I can self host on AWS
| mdaniel wrote:
| > open source ... under the ELv2 license
|
| I would think a Launch HN would know better than to use "open
| source" with a non open source license. It is source available,
| sure, and it's your software so you can license it as you wish,
| but don't call it open source as that continues to pollute the
| very idea of the software freedoms that actual open source
| licenses are designed to provide
| dang wrote:
| I don't think it's in anybody's interest to rehash this again,
| so have put "source-available" in the title above.
| andy99 wrote:
| I actually clicked to commend them on being open that it's
| "source available" but I see now that was an edit. Seems like a
| good strategy is just to embrace the source available label,
| people either don't see the distinction or they're like you and
| me that will come and complain if someone uses "open source"
| incorrectly.
| toomuchtodo wrote:
| Do you leverage Gorilla (https://gorilla.cs.berkeley.edu/) at
| all? If not, perhaps consider if it would solve some pain for
| you.
|
| https://news.ycombinator.com/item?id=36073241
| swyx wrote:
| you mean add pain by introducing a nondeterministic LLM in the
| loop where none is needed?
| toomuchtodo wrote:
| Unreasonable pessimism considering state of the art velocity.
| Determinism, while a challenge to solve for, is not entirely
| impossible. There is value even if you're using an LLM to
| code assist with integration builds (using OpenAPI specs) or
| breakage when an API changes suddenly.
|
| https://news.ycombinator.com/item?id=35631555
|
| (contributed for several years at a low code/no code prodcut
| org, familiar with integration maintenance and what
| integrating with APIs at scale looks like)
| spxneo wrote:
| I don't think parent is being unreasonable if my perception
| of Gorilla is correct here but
|
| Lot of mission critical apps cannot risk even 0.01% chance
| of hallucination or some blackbox process
|
| Like I don't think a direct LLM-2-API is feasible for even
| enterprise clients unless LLM generates that 2-API code
| layer that can be audited but right away that negates the
| need for Gorilla
|
| Seems like "just trust this blackbox because everybody is
| writing wrappers around it" is similar to "throwing redux
| because facebook said so" 7 years ago. Definitely seeing
| some parallels with technological pollyannaism with
| blockchain.
| toomuchtodo wrote:
| I agree you cannot trust unsupervised LLM output for
| mission critical M2M use cases, but (imho) it will help
| you move faster to create and maintain integrations with
| human supervision (code->SVN->test harness part of
| CICD->human review [1] and editing + proposed fixes for
| failure detection via Sentry [2] or similar). My
| apologies I did not make that more clear further up
| subthread.
|
| To determine if this creates a positive value creation
| trajectory, some implementation and caretaking of the
| code generation pipeline is necessary.
|
| [1] https://medium.com/@rgranadosd/using-ai-to-build-our-
| apis-wi...
|
| [2] https://docs.sentry.io/product/issues/issue-
| details/ai-sugge...
| jasonjmcghee wrote:
| I'd call it realistic. It's one thing to have an LLM
| developer facing and suggesting improvements etc _maybe_
| "something went wrong? Try auto fix"
|
| But LLM in a hotspot is asking for trouble in present LLM
| sota
| Trufa wrote:
| This looks very interesting, but I have two questions.
|
| 1) Did I understand this correctly, oversimplifying, instead of
| going api.slack.com/users I go nango.com/slack/users
|
| If I did it leads to question 2) since I assume this won't have
| feature parity 100% of the times, what's my escape hatch when I
| need a feature that's available in an api and not in your
| service, if worse comes to worse, can I still easily access the
| original api easily?
| bastienbeurier wrote:
| 1) That's right!
|
| 2) You can write your own integration scripts, in code,
| consuming any endpoint from the external API, so you are not
| limited to what Nango pre-builds (details:
| https://docs.nango.dev/understand/concepts/scripts).
|
| But you can also access the original API through the proxy,
| which will inject credentials, log requests, help you with
| pagination (details:
| https://docs.nango.dev/understand/concepts/proxy).
| jonahx wrote:
| Nice idea.
|
| So to recap:
|
| 1) Nango supplies easier-use-to-use wrappers over a host of
| common APIs, making the most common operations simpler. Nango
| generally handles auth, logging, pagination.
|
| 2) Nango is extensible through custom scripts when your use
| case falls outside the common ones.
|
| Question 1) Nango provides some consistency to the APIs in
| its wrapper so, to some extent, you are learning the "nango
| way" vs hundreds of bespoke ways?
|
| Question 2) How do you handle API churn with hundreds of APIs
| supported? On any given day, there's got to be a decent
| chance of something changing that breaks you?
| harrylucas wrote:
| Wanted to check if this actually provides a unified api? E.g.
| each category of integration will return the exact same data
| shape? From the looks of the video I'm still making a call to
| slack's API `users.list` and have to write the code to paginate
| slacks api (e.g. the next cursor).
| alalani1 wrote:
| I think its easier to market "unified API". In practice, it is
| more like an API to call another API with some niceties like
| Auth handled + retries
| bastienbeurier wrote:
| It does!
|
| Because Nango lets you define input & output models of
| integrations, it's easy to standardize them across APIs.
|
| So, when syncing users from Slack/Discord/Teams, you define a
| standard User model, and all 3 integrations map to this model.
|
| You then consume User objects from a unified endpoint,
| regardless of where they come from.
| infrawhispers wrote:
| ELv2 is not an open source license. Why are so many companies
| using "open source" to scaffold on traction and interest? This
| framing is disingenuous.
| JonAtkinson wrote:
| This is not open source.
| frozenmaestro wrote:
| Good work! But ELv2 != open source. Clickbait destroys trust.
| dang wrote:
| We changed the title:
| https://news.ycombinator.com/item?id=40159204
| rahimnathwani wrote:
| I read your entire post, and couldn't understand what you do.
|
| After watching the video, I _think_ you make it easy for SaaS
| creators to give their customers the ability to integrate with
| other SaaS /API products. Is that right?
|
| So e.g. if I make a SaaS tool for plumbers, and some of those
| plumbers use Xero for accounting, then I could use Nango to allow
| those plumbers to set up some data flow between my SaaS and Xero.
| Right?
| rguldener wrote:
| Yes, this is correct!
| rahimnathwani wrote:
| So you're basically trying to remove the need for Zapier as a
| bridge between different SaaS products?
| rguldener wrote:
| I think there will always be a use case for Zapier to cover
| the very long tail of integrations.
|
| But we want to make it easier for engineers to offer their
| customers the native integrations they need.
|
| Usually, these cover the most important and most valuable
| use cases. But they are often also the most complex to
| build (e.g. reliable 2-way data syncs)
| rahimnathwani wrote:
| I think there will always be a use case for Zapier to
| cover the very long tail of integrations. But we want to
| make it easier for engineers to offer their customers the
| native integrations they need.
|
| This is a better description of your product than what
| you wrote in your original post. Maybe worth iterating to
| see what resonates with your target audience.
| e.g. reliable 2-way data syncs
|
| I'm curious about this. Can you give a real-life example
| of a 2-way data sync you or your users have set up?
| rguldener wrote:
| Can you give a real-life example of a 2-way data sync you
| or your users have set up?
|
| Sure:
|
| - A support SaaS uses Nango to sync contacts & companies
| with CRMs (Salesforce, HubSpot, etc.)
|
| - A billing SaaS uses Nango to sync invoices, customers,
| etc. with accounting systems (Quickbooks, Netsuite, etc.)
|
| - A security-focused SaaS uses Nango to create issues in
| Jira, Linear, etc., and then syncs the status & other
| properties between these apps and its own product
|
| I hope this helps!
| alalani1 wrote:
| If Zapier is your mental model, the use case there is
| trigger/action workflows which is a different from 2-way
| sync which I'd say Nango does well. For the former you
| might want to check out this open-source project I work on:
| https://github.com/RolloutHQ/rollout
| rahimnathwani wrote:
| Consider putting a screenshot at the top of the README.
| Even one you already have, like this one:
|
| https://docs.rollout.com/overview/what-does-rollout-
| provide
| alalani1 wrote:
| Thanks for the feedback - just added one!
| spxneo wrote:
| im also not clear/sold on the value proposition or perhaps im
| misunderstanding things but
|
| How does Nango differ from existing solutions? Seems like
| everybody is working on on programmatic "Zapier" (if thats what
| this is?) with OpenAI wrapper thrown over it.
| rahimnathwani wrote:
| I think the point is that your customers don't need to use
| Zapier, as you can give them something that's simpler to use,
| right inside your product.
|
| I might be wrong. I have the same info you do!
| dominicwhyte wrote:
| Nango is awesome. I've used it across several projects and it's
| sped up our "time to live integration" significantly + reduced
| maintenance costs. Congrats Bastien, Robin and team!
| alertify wrote:
| At https://bot9.ai (most advanced AI based Customer service
| engine) we are currently building integrations for CRMs,
| Ticketing tools, Chat softwares, Ecommerce platforms etc which
| the bot connects to.
|
| For example the bot connects to freshdesk or intercom and handles
| the tickets / chats just like a normal agent, and handsover to a
| human if it can't solve or a customer asks, without the company
| having to change their chat or ticket tools.
|
| Or connects to shopify to help customers answer any pre-sales
| questions or help them make a purchase decision.
|
| I see the pain in building these integration one by one and
| currently exploring a few SaaS that will help me have lot more
| integrations without us having to build & test one by one
| (Months).
|
| Paragon , hotglue for example.
|
| There are generally two approaches to do this, each with their
| pros and cons.
|
| A few go with a unified api approach. The benefit is that you can
| integrate one Unified CRM API and then use all CRM softwares
| directly. While this does give a lot of headstart, the downside
| is that all CRM or ticket softwars may not have the same
| terminology and you may get into problems.
|
| For example, intercom does not really have a ticket type system
| but still people use it for ticketing. Whlie freshdesk or Zendesk
| is a proper ticket system with lots of variables that can be
| mapped to a ticket. With a unified API you kind of lose out on
| max potential of the platform you are integrating with, at the
| cost of faster integration.
|
| Then there are direct APIs which still allow faster integration
| by handling auth, logging, debugging and some kind of unification
| but you have to still integrate them one by one in your SaaS. So
| you gain lot more control, at the expense of time to implement.
|
| By looking at the docs, I see they are trying to go with a hybrid
| model where they give a direct integration option but i can map
| the models myself which kind of covers both cases ? Someone from
| the team can comment. But Interesting.
|
| This is definitely an interesting space which has been mostly
| covered by zapier. but zaps are ugly, a glue and very expensive
| for anything serios and mostly used by individuals who just want
| to connect a few systems together.
|
| In this AI era where everyone is building something with AI and
| finding out that building the MVP is pretty easy but then gets
| stuck on expanding because customers wants things to work inside
| the tools they already use, there is definitely a market for
| this.
|
| I have sent a meeting request, happy to connect and see if this
| helps us.
| bastienbeurier wrote:
| Thank you for the insights and looking forward to chatting!
| nip wrote:
| Congrats on the launch Bastien and Robin!
|
| This launch couldn't be more timely for us:
|
| We're currently planning on integrating with many oauth-based
| apps where our end goal is to provide always valid access tokens
| to end customers (developers), abstracting away the complex
| refresh mechanism that we take care of.
|
| Is it something we could do with Nando?
|
| The simplified flow looks as follows:
|
| 1. Customer logins via oauth in a dedicated portal
|
| 2. We have a way to retrieve the access token at any time from
| Nando via an API
|
| 3. We handover that access token to our user for their own calls
| to the oauth-authenticated APIs
| bastienbeurier wrote:
| Yes, this works, and it's a feature we offer for free!
| nip wrote:
| Beautiful! Thanks for taking the time to reply!
|
| We will be looking to self-host: I'll start going through
| your docs, thanks again!
| lordofmoria wrote:
| Congrats! We've been using Nango for about a year, mostly to
| handle oauth flows for us to about 7-8 integrations (Dropbox,
| google drive, etc) that our users can self-service connect in our
| app.
|
| Very stable, the team is respnsibe to handling the weird corner
| cases (which their value prop is all about), and they seem to be
| able to build new integrations and functionality quickly.
|
| I'll be taking a closer look at their sync functionality, since
| our users want email in app (CRM style).
| anonzzzies wrote:
| What is the effect of the license in this case? I find the
| Elastic license hard to parse to be honest.
| lpellis wrote:
| I'm struggling a bit to figure out the pricing here. If I have
| lets say 50 users that sync Trello, does that count as 50 synced
| connections?
| bastienbeurier wrote:
| Some integrations are connected at the org level (one account
| for the entire company), and others at the user level (many
| accounts per company). For the latter case, the pricing per
| connection is lower.
| angryasian wrote:
| I'm a little confused. Doesn't the user still have to sign into
| each oauth service individually still ?
|
| 1. So is this managing tokens ?
|
| 2. These templates are used instead of api's ?
| baetylus wrote:
| Love this idea - a huge pain point for many teams. I've had this
| issue, and am looking forward to trying this out.
|
| I know there are a couple competitors too. How do you distinguish
| yourself from something like Merge.dev?
| bastienbeurier wrote:
| The main difference is that Merge pre-builds all integrations,
| with limited customization capabilities, while Nango gives you
| full control over the code of the integrations.
| msukmanowsky wrote:
| Not trying to be snarky, but I'm not sure why this matters?
| Isn't the main value prop of a service like nango or Merge
| just the unified API and features around it (e.g. unified
| webhooks for events etc)? Can you help me understand why this
| is important?
| bastienbeurier wrote:
| Standard pre-built integrations are ok to get started. But
| rapidly customers ask for more integration capabilities,
| which are not supported by standard integrations. At this
| point, SaaS companies need to build custom integrations
| that fit exactly what they customers want.
| muttantt wrote:
| This is https://cloud-elements.com/ all over again
| exolab wrote:
| How does the "scale plan" work and how much is it?
| rumad wrote:
| Good luck with the launch! Looks awesome. I will take a deep look
| into integrations to use on my SaaS.
| xgb84j wrote:
| One challenge I encountered in the past was syncing data between
| a SaaS software I built and customers' ERP systems. Building
| these integrations was an absolute pain because there often is no
| publicly available documentation. This means you need to pay an
| SAP consultant 300 dollars per hour to tell you all the things
| normal apis have in their public documentation. Is this something
| you plan to address? Or are you just making already usable apis
| even easier to use?
|
| Btw great product! Just really curious about a personal pain
| point of mine!
| ensemblehq wrote:
| Would be great if the Nango team can address it but my
| experience as that "300 dollars per hour" consultant (although
| I never got to see anywhere close to that) is that most ERP
| systems are heavily customized that it would be hard to auto-
| generate endpoints/documentation off of it.
|
| Have you had a chance to go through your customers' ERP
| systems?
| bastienbeurier wrote:
| We've noticed the same pain point and we are providing
| increasingly better support for ERPs. Realistically, it takes
| time to build expertise on each of them, but we'll get there!
| prakhar897 wrote:
| Quite similar to make.com and similar products right? Any
| differentiators from them?
| callmeed wrote:
| It's interesting, seems like a popular space lately (even within
| YC). Off the top of my head, there's merge.dev, Terra, Kombo,
| Workato.
|
| Aside from the obvious question of "how are you
| different/better?" I'm most curious to know why you're going so
| broad initially. You've got everything from legal to devtools to
| gaming. Seems like the opposite of a wedge/beachhead approach.
| Why?
| dominicwhyte wrote:
| We evaluated most of these (minus Workato) and landed on Nango.
| Was by far the most flexible and having the source code
| available was a big plus (vs. the closed-source alternatives).
| The team is also reactive to feedback in their Slack community,
| they even added a few new endpoints for us in < 24 hours
| bastienbeurier wrote:
| The players you mentioned pre-build standard integrations, in
| specific categories (e.g. HRIS). We build a platform that lets
| developers build custom integrations, for any API.
|
| We do offer integration "templates", but it's only a way to get
| started and templates are meant to be extended.
|
| That's also why our catalog of APIs is extensive. Anybody can
| rapidly add support for any new API and start building custom
| integrations for it, and share templates with the community.
| digitcatphd wrote:
| This is going to be crucial infrastructure for the next
| generation of LLM applications
| Vishnu3014 wrote:
| As the LLM's need to talk to various API's ?
| sqs wrote:
| Very cool idea! I got rejected from Y Combinator in 2006 for a
| similar idea. Still surprised nobody has done this. Congrats on
| the launch!
| duggan wrote:
| Love the source available API proxy, that's a useful component on
| its own! A little disappointed to see that most of the really
| good stuff is not available for self-hosting, but an
| IPaaS/Unified API is a not the kind of project one tinkers away
| at on the weekends for the joy of it. It's hard work, deserves
| congratulations, and bills gotta get paid.
|
| I remain ever hopeful for an open source IPaaS some day (had a
| chat with my cofounders about it this morning actually) but I
| just don't see the incentives aligning. 1.) It's hard to do, 2.)
| I don't see a megacorp sponsoring a CNCF project, 3.) some amount
| of the work is in mapping concepts to your own platform, 4.)
| there is a gauntlet of legal agreements, branding guidelines,
| security reviews, etc., to go through with third parties
| regardless.
|
| All that said, I'll be taking a closer look at Nango, because
| this is an evergreen problem, and I'm interested in finding the
| best solution.
___________________________________________________________________
(page generated 2024-04-25 23:00 UTC)