[HN Gopher] Show HN: Nango - Open unified API for product integr...
___________________________________________________________________
Show HN: Nango - Open unified API for product integrations
Today customers expect every SaaS product to integrate with the
other tools they use. Nango is a tool for engineers at SaaS
companies to help them ship integrations fast, without compromising
on the integration's depth and quality. It supports more than 100
APIs out of the box. Other integration companies have focused on
building a lot of pre-built integrations. These are fast to ship
and low maintenance, but they limit how deeply you can integrate
with the external APIs. We take a different approach: we make it
easier for developers to build and maintain product integrations in
code. This lets you create exactly the integration your customers
need without compromising on speed and maintainability, and without
having to build complex infrastructure (OAuth, retries, rate-limit
handling, change detection, monitoring & logging, alerting, etc.).
Our platform has two layers: (1) An API-agnostic infrastructure
built with Temporal and Postgres, and (2) lambda function-like
integrations written in typescript by any developer. Integrations
are rarely more than 50 lines of code (here is an example:
https://bit.ly/nango-example), thanks to the developer tooling
we've built in: authentication, pagination, retries, change
detection, rate-limit handling, monitoring, Slack alerts, etc. We
have pre-built integration templates you can clone and extend--or
you can build entirely custom integrations. Your integrations live
in your repo and are tested and deployed to Nango with a CLI. In
your product, you use a single API to interact with all your
integrations. This lets you easily grow the available integrations
with minimal code changes in your product. As a community-driven
project, anybody can contribute integration templates and APIs to
the platform. In fact, more than 30% of the APIs we support today
have been contributed by our community. Nango grew out of a
"universal OAuth" project called Pizzly and powers the integrations
of 100+ SaaS products today. We have an active community of 800+
developers (https://nango.dev/slack). All auth-related features
are free forever, and we monetize with sync-related features. The
entire code base and all integrations are source-available:
https://github.com/NangoHQ/nango. We hope Nango can help connect
all SaaS products together and look forward to your feedback!
Author : rguldener
Score : 68 points
Date : 2023-11-09 16:17 UTC (6 hours ago)
(HTM) web link (www.nango.dev)
(TXT) w3m dump (www.nango.dev)
| marban wrote:
| I never understood the raison d'etre of such pipe-connecting
| services for B2Bs. If some data flow is business-critical, why
| would I want to outsource (and route) an already fragile
| interconnection to yet another party? Since you're addressing
| developers, I assume they should know how to plug into an API.
| esafak wrote:
| Wouldn't it be easier to share the work of updating the
| integration code when the API evolves?
| kspacewalk2 wrote:
| Use it as a starting point, don't blindly update, fork if
| necessary, periodically reconcile with upstream in order to
| keep up with API changes.
| btown wrote:
| If you have a stable global long-term API key for a global API
| that you use without regards to your users' tenancy on that
| platform, then absolutely - just put it in your 12-factor env
| or other secret storage, and start developing!
|
| But if, for every integrated service, you need to build out a
| custom URL to receive OAuth tokens after an authorization flow,
| and a database to securely store them, and a reliable
| background task to periodically refresh them... then you're
| doing a ton of work before you can even access a Salesforce or
| Quickbooks object on behalf of your clients. Having a service
| that can orchestrate all of this can make it as easy to work
| with as a stable API key, and then you just need to do the
| work.
| bastienbeurier wrote:
| (Nango co-founder here) We help teams who don't have the
| resources or expertise to build & maintain integrations.
| Sometimes, they need to build a lot, complex or scalable ones,
| or they want to invest their energy elsewhere.
|
| Building integrations comes with specific challenges (security,
| ETL, etc.), which are usually not the core competency of SaaS
| teams.
|
| We often see that problems related to building integrations are
| underestimated and can spiral in terms of engineering costs.
| Authorization in itself is complex, data synchronization even
| more so!
| throwawaysleep wrote:
| Speed to market.
|
| Things don't need to work that well to be sold. One of my
| employers has entire integrations that don't work and we still
| sell them to the business types successfully. They then file a
| bug ticket and wait months until we get to it, them paying fees
| all the way.
| alxmng wrote:
| Enterprise sales is essentially just promising more and more
| features that don't exist until they sign a contract, then
| developing the crappiest least-effort implementation to not
| lose the contract.
| dyeje wrote:
| You want to outsource so you can focus on building your product
| instead of integrations which are costly to build and maintain.
| Also it's not easy to come up with these universal mappings,
| why reinvent the wheel? It's unlikely that your integrations
| are differentiating but it is likely they enable you to close
| deals.
| harrisonjackson wrote:
| Nice yall - love the updates
|
| You have built a really great product that is easy to use. I've
| tested out the self-hosted option on render.com with neon
| postgres and the cloud version. Both are super easy to get up and
| running.
|
| Now, it is no exaggeration to say that the most annoying part of
| adding a new integration is just navigating the API provider's
| portal to get the app outh creds.
| bastienbeurier wrote:
| Thank you!
|
| I agree that getting approved to have an OAuth app is a major
| pain point (for some APIs). We help customers navigate this and
| would like to do more in the future (partner with API
| providers, offer sandbox accounts without approval, and even
| manage the approvals for customers when possible).
| CharlesW wrote:
| After spending a reasonable amount of time looking for an answer
| on the site: Assuming I have a SaaS with some third-party
| integrations that don't need Nango, why am I taking on the
| business/technology risk of this external dependency to do
| "custom" integrations?
| bastienbeurier wrote:
| (Nango co-founder here) Because there will be a lot less that
| you need to build. You will write less code & ship faster. You
| will get reporting, monitoring, alerting, a management
| dashboard & APIs. You will also have an integration
| architecture that scales to many complex integrations as your
| company grows!
| CharlesW wrote:
| Can you share an example?
| bastienbeurier wrote:
| For example, if you want to synchronize a specific object
| type, you would get: the authorization for the API, a
| helper for paginating requests, easy data deduplication,
| resilient background syncing, rate-limits handled, and a
| way to get the data that's unified across APIs and use-
| case: `nango.getRecords('zendesk', 'user123', 'ticket')`.
| And you benefit from the tooling around: all sync runs are
| logged, you get alerted on Slack on errors, you can inspect
| your integration activity per end-user, etc.
| TekMol wrote:
| I'm scratching my head. Why I would want to put an API in front
| of an API which I want to use?
|
| So instead of requests.get(
| 'https://some_api/some_endpoint?some_params',
| headers=some_headers )
|
| I have to do requests.get( 'https:/
| /some_other_api/i_want_something_from_some_api/some_other_endpoin
| t?some_other_params', headers=some_other_headers
| )
|
| ?
|
| What is the benefit of doing this?
| ne8il wrote:
| If it's like https://www.merge.dev/ (another "Unified API")
| then the idea is they provide an abstraction layer to the other
| API. You build against one generic spec for a given entity
| ("Person", "Company", "Ticket", etc), hook up to the API, and
| whatever platform-specific model is squished into that generic
| model. You end up with only one integration to cover all
| instances of "CRM systems" or whatnot. Obviously you also have
| some vendor lock-in, but it is less work than building multiple
| integrations for each new $product on the market.
| TekMol wrote:
| I don't understand what you mean.
|
| Say the API is
| https://getweather.com/api?city=berlin
|
| What benefit do I get from calling
| https://universalapi.com/getweather_com/api?city=berlin
|
| instead?
|
| Can you show in code, what you mean?
| mbesto wrote:
| We use Merge for an app I built so I can elaborate.
|
| Using your example, let's say I want to get the weather for
| Berlin today from NOAA, Foreca, and DarSky. I would have to
| do: noaa.com/api?city=berlin
| foreca.com/api?city=berlin
| darksky.com/api?city=berlin
|
| return each results and store them.
|
| As opposed to sending the call once:
| getweather.com/api?city=berlin
|
| Now let's say I want to add a new source (Wunderground). I
| login to Merge/Nango and just check "Wunderground" and just
| change my API call to store the new source.
|
| Now let's say Foreca changes it's API to
| foreca.com/v2/api?city=berlin I don't have to monitor this
| at all. Merge/Nango would do this for me.
| TekMol wrote:
| Regarding your first point, combining 3 API calls into
| one: Well, it is just one line of code on your server.
| But you have put the rest of the logic into the
| Merge/Nango server. Maybe via some point and click
| interface. But it is still there. So your complexity went
| up, not down.
|
| Regarding your second point, APIs don't change just nilly
| willy from /v1/ to /v2/ and let you "fix" it by swapping
| "1" with "2". Usually you get changes like /v1/weather
| does not exist anymore and now you got /v2/exact_weather
| and /v2/broad_weather. Both different to /v1/weather.
| exact_weather only accepts city names of cities with a
| population over 1 million, is now a paid service and
| returns weekly weather instead of daily. And
| /v2/broad_weather does not accept city names anymore but
| only coordinates, is still free but locks you out after
| 10k monthly requests and returns daily weather but
| without rainfall info.
|
| So a "in between API" won't save you from dabbling with
| the change from v1 to v2.
|
| And on top of that, now you have two APIs that will
| change from time to time. The weather API and the
| Merge/Nango API.
| buremba wrote:
| Looks like a cool product with the front-end integration but
| looking at the license, I can't understand how I'm supposed to
| use it when you use an Elastic license.
|
| While I understand Elastic's goal of preventing other companies
| from just rebranding Elasticsearch and selling it as it is, I
| would probably use Nango as it is and build a front-end layer on
| top of it for my side projects as I thought this is the main use-
| case. Can you elaborate more on the license?
| bastienbeurier wrote:
| (Nango co-founder here) We use the Elastic license precisely
| for the reason you mention: to prevent companies from
| rebranding Nango and selling it as it is. For all other use
| cases, it should be accessible.
| buremba wrote:
| So let's say I want to build a service that lets people
| access all their libraries from multiple streaming services.
| Can't I automate all the backend with Nango and just build a
| front-end around it? If yes, wouldn't it be just rebranding
| Nango? If not, it would be nice to clarify in the docs.
|
| My point is that if there is no clear boundary, it's too
| risky for me to try this product even if it's open-core. For
| Elastic, their boundary is "database as a service" but I
| don't see anything similar in your license.
| bastienbeurier wrote:
| Ok I see. Indeed, it would be worth specifying what the
| boundary is in our case. Thank you for the feedback!
| 101008 wrote:
| How do you compete with Codat.io?
| bastienbeurier wrote:
| (Nango co-founder here) Codat is focused on financial
| integrations, and Nango is transversal, so you can have all
| your integrations on one platform.
| jedberg wrote:
| Any time I see a "unified API" where multiple interfaces are
| abstracted to a single interface, my first concern is the lowest
| common denominator problem.
|
| What I mean by that is your unified API can only support features
| that all of the APIs it is abstracting also support. Otherwise
| the users of that API will make calls and not know if they will
| work because it will depend on the backend.
|
| The classic example of this was when people tried to create
| unified APIs for AWS, GCE, and Azure. They had to only support
| features all three had, otherwise the API would break if you used
| the wrong cloud provider, in which case it was easier to just
| interface directly with said cloud provider.
|
| Which is a lot of words to say, how will you support multiple
| APIs with different feature sets without breaking your API?
| bastienbeurier wrote:
| (Nango co-founder here) That's a great point. You highlight a
| key limitation of traditional unified APIs and one of the
| reasons why we started Nango.
|
| There's a lot of subjectivity that goes into unifying
| functionalities across APIs. Traditional unified APIs must make
| these subjective decisions for all their customers in a one-
| size-fits-all manner.
|
| Nango lets you customize integrations & schemas, so you can
| make these subjective decisions for yourself. The result is a
| unified API that truly fits your business use case.
|
| Still, some radically diverging API functionalities cannot be
| unified, which requires some additional API-specific logic to
| handle. This can be abstracted in our integration scripts,
| supported by our tooling, instead of living in your main code-
| base.
| sgammon wrote:
| This looks great, and we're in the market for it, but we use JVM
| tech and would need a client :(
|
| I'd be happy to join the Slack and chat.
| bastienbeurier wrote:
| (Nango co-founder here) Great. The client is just a thin
| wrapper around our REST API, which can be called from any
| language. But we plan to release SDKs for all main languages
| this quarter (including Java). Happy to chat on the community!
| dominicwhyte wrote:
| We use Nango for https://fillout.com and it's been a great
| addition to our tech stack. Has made it much faster to add new
| integrations without having to navigate OAuth docs each time
| ssddanbrown wrote:
| Back in August I queried [1] your usage of "open source" while
| not being an open source project (ELv2 licensed). It looks like
| you're no longer describing yourself as "100% Open Source" which
| is good but you still label yourself as open source in the repo
| readme and still refer to yourself as open source on the website.
| Do you intend to keep labelling yourself as open source or is
| that something you're moving away from?
|
| [1] https://github.com/NangoHQ/nango/issues/900
| bastienbeurier wrote:
| (Nango co-founder here) I'll update the repo readme and other
| mentions of being open source. Thank you for reporting this. We
| are not set on the license yet. We want to promote permissive
| usage, particularly for the auth-related features & contributed
| integration templates, but we are being mindful of the
| competitive environment.
| ssddanbrown wrote:
| Sure, I understand and respect the desire to protect your
| efforts. Thanks for responding and being receptive!
___________________________________________________________________
(page generated 2023-11-09 23:00 UTC)