Developers who maintain many external API integrations, how do you maintain them?

Looking for people who maintain MANY (10+) external APIs.
My questions are:

1. Name some 3rd party API tools you use to manage your stack
2. What's your biggest pain point dealing w APIs?
3. What solution have you hacked together to solve that pain point?
4. What is your ideal solution?

Thanks for sharing! Here's one of my favorite gifs for the road.

Comments

[Anton Frattaroli]

More details would help. What kind of APIs?

I mean, for every JS front end, I make an API backend. So every website I make is an external API. And then those API backends also call data APIs, some of which are my responsibility, and are used by other internal teams (same effect as an external user).

For web backends, I have the JS client call an endpoint that returns a version, and then at a set interval, checks to see that the version hasn't changed. When a new version of the application (front end and back end) is deployed, the user gets a notification that the application has been updated, and they need to refresh the page. Each JS/CSS file bundle is versioned and placed in the cache when deployed, and the initial page load includes a manifest, and script loaders reference the manifest rather than the source filepaths.

Data API references tend to break clients when changed. So in that case, each version gets it's own application folder (I host on IIS), with the application folder specified in custom TFS build arguments - source is branched appropriately. Those get deployed, and then clients can start consuming the new version. When the old versions no longer get any traffic, change management occurs to decommission them. If we had external customers using the APIs, we would send out a communication rather than using change management.

None of the APIs I maintain have a daily call limit or are terribly complex. There's a variety of different technologies (SOAP/XML, JSON, OData v3-v4) and different firewalls and auth protocols. I couldn't tell you anything about hosting a complex one like Google's Analytics API (although I've consumed it, and bravo to them for making it at all usable).

I'm not a fan of BizTalk (lack of innovation), haven't used MuleSoft - tried AppFabric but it didn't go so well. Once .net core gets more established, I'd like to rewrite them all and host them on a docker swarm with windows server nano images.

[Ben Halpern]

I've built apps that relied heavily on third party APIs for data gathering (price comparison) and at other times for app features/infrastructure (CDN, hosted search, etc.)

I'd love to hear about what other people do, because it's an area where I constantly feel like I might be missing the big picture and doing it wrong.

1. For dev.to the needs trend more towards the app features/infrastructure realm as opposed to data ingestion. We use Fastly for CDN, Cloudinary for image CDN/manipulation, S3 for hosting static assets, Keen for storing event data, Sendgrid for emails, Algolia for hosted search. Some are sort of configure-and-forget with an abstraction library, and some we integrate with the API itself more.
2. Big painpoints are managing the services across different development environments. Everything self-contained within our application's logic can be easily spun up for different people, but when we add services, it introduces complications and differences across environments that are hard to deal with. We're doing fine now, but this makes scaling the team harder. We also plan to open source the app in the future, and I'm not sure how that will work. Being a monolith that interacts with a few services here and there as opposed to being service-oriented from the ground up contributes to this, but this works fine for now, and breaking out would introduce its own headaches.
3. I wouldn't say we have a good overall solution, except just trying to encapsulate the behavior so that the implementations can be substituted more easily.
4. I'm not sure about ideal scenario, but I'd love to hear more.

I'm not sure if these sort of APIs are the sorts of things you're looking for. The data-oriented APIs are a more straightforward, of trying to build build/make use of libraries that wrap the APIs and trying to build out a mocking framework for testing earlier, rather than waiting until it gets too hairy.

[Elizabeth]

Thanks Ben! I'll let you know what consensus is :)