I was remembering some application code I refactored.

This isn’t an interview so I’m going to use the analogy of a school to keep the work details abstract.

I was fixing a logic bug in an endpoint, and my tech lead asked why it was calling a downstream API about a dozen times.

I didn’t know so I had to go look up the documentation for the service we were requesting.

So why did the implementation make all those calls?

As usual, constraints.

We had to see if a student submitted their assignment. But the downstream endpoint returned a list of assignments and their status, but it abstracted the student name by only referencing their id.

The application code’s config only had access to the student’s names, because dev, qa, and prod had different ids for them.

The downstream endpoint did however let you pass in a student name as a parameter that would pre-filter the response.

Piecing it together. Loop through the student names and make a request for each of them.

The original developer masterfully worked around the limitation.

But.

Ten payloads sent over the tubes. Ten JSON chunks had to be sent back.

We can do better.

Amazing what reading docs tells you.

Turns out there’s another endpoint in the API that lets you just get a list of every student with their id.

So.

One call to get all the students.

Get just the info we need.

Second call to get all the assignments.

Check the status for the ids we want.

Tradeoff, we’re requesting a lot more data than we need and using our own compute to parse it.

I find that a valid tradeoff to getting snippets each time.

About a dozen requests adds latency. We have more than enough compute to parse JSON. If your page doesn’t load in 3 seconds, you’ve lost your potential sale. In business, that matters more.

I git blamed the developer.

Of course it was yinz truly.

Unfortunately no story points for bug-fixes.