3 ms·

If it's like https://www.merge.dev/ https://www.merge.dev/ (another "Unified API") then the idea is they provide an abstraction layer to the other API. You buil

by ne8il 3y ago

If it's like https://www.merge.dev/ 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 3y ago
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 3y ago
  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 3y ago
    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.
    - eightysixfour 3y ago
      For services Nango supports, they manage all of the things you are talking about - upgrading the APIs, etc. You call weather, you get weather from the APIs you have enabled. They’re selling the management of the complexity you’re talking about.

by ne8il 3y ago

TekMol 3y ago

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 3y ago
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 3y ago
  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.
  - eightysixfour 3y ago
    For services Nango supports, they manage all of the things you are talking about - upgrading the APIs, etc. You call weather, you get weather from the APIs you have enabled. They’re selling the management of the complexity you’re talking about.