"You should have thought about that before"
How a simple API call turned into a days-long delay
Let’s say you want to implement a new feature in your backend. You have to call the API of another team. It’s only a small lookup — e.g., you provide the address of a user and you get back the username.
Simple task, right? Let’s start by adding an endpoint to the backend. Implement a service class in a best-practice TDD way. Of course, for best-practice unit tests, you have to mock the API of the other team. But that’s the way to go, right?
You create a PR and ask for a review. Your product owner asks you how long it will take. Surely, you just have to wait for the review — but you promise it will be done by the end of business.
Finally, after a few back-and-forth cycles with the reviewer, you get the approval. Just merge it and wait a few minutes for the CI to do its work.
After it is finally deployed, you call your backend’s API for the first time. Just this final integration test and you can call it a day.
But nothing happens…
Why?!?
After 5 seconds, Postman runs into a timeout.
The next day, the product owner expects your feature to work. But it doesn’t.
“The other team’s API is in a different AWS account. Have you requested a firewall change to make it accessible from our account?”
Oh no! This is the missing piece! Why didn’t you think about this in advance? Wasn’t it obvious that this needed to be done as the very first item?
The process of changing a firewall takes days, and the only way to finish your feature on time would have been to wait for the changes while implementing the feature — and not afterwards.
Could you have done something better?
Afterwards, everyone is always an expert stock trader. But the question is not whether the choice was right in retrospect (a posteriori), but from the point of view at the time the choice was made.
The question is: If you are a backend developer for applications in AWS, is there a list of things you have to check before starting implementation, to avoid long waiting times and external dependencies after the implementation is done?
I don’t know the answer — because by definition, I don’t know the unknown unknowns. But let me try to give you some points:
Are there external dependencies?
Can you access the external API from a network point of view?
Do you have the credentials to access the external API?
How many requests per second will your backend handle? Does the external API allow this rate, or will you run into a rate limit?
And so on.
Now the question is: If there is such a list, how long is it? If it’s too long, it might be less work to just fix the issues with the integration afterwards than to always go through a long checklist.
What do you think? Can most of the problems in the integration of components be avoided by going through a determined list of known stumbling blocks?