Apis for internal eng teams

As a Principal Engineer, how would you provide APIs for existing functions to other dev teams in your company? (5 minutes read)

Fun Fact: This is based on a true story 🙂

> TL;DR:

Create an API layer.

DETAILS:

The requirements are as follows:

• Your product currently has 30 - 40 internal functions, each offering some form of functionality - small, medium, or large.

• However, these functions are not exposed as APIs. This means developers from other engineering teams cannot call them directly.

• Now, your team has been tasked with providing these other engineering teams a set of APIs that expose key business functionalities.

Depending on how your company operates, this initiative may be driven by the Engineering Manager or by a senior individual contributor (like a Principal or Staff Engineer), with the EM providing support in various ways.

Initial Thoughts:

This requirement might seem easy at first. You might think,

“Oh, the code is already there as a function—just cut it out, wrap it in an API, and we’re done.”

If that’s your initial thought, you’re not alone 🙂.

But in reality, this project is far more complex than it appears. There are layers of design, security, testing, and coordination involved. Let’s break it down...

A] Deep dive on things to do

• Suppose there are around 30 functions invoked when a user performs specific actions in the app. For example, when a user purchases an item, the addToCart function is called internally – and so on.

• Prioritisation of business functionalities

  • The first step is to discuss with the Product Managers, other Engineering teams, Executives – and identify what are the most important business use cases that they want the APIs to provide

  • Depending on the timeline provided, prioritise how many of them are possible. 

  • If all are not possible, then go iterative way – in the first version, provide say 50%, next iteration 25%, and finally 25%

  • However, to estimate the effort required to convert a function into a (company-internal) public API, we need to understand all the necessary steps – covered in the next section.

B] Steps to convert a function to a public API

1. Set up a new API server

2. Refactor function into API (GET, POST, etc.)

3. Add authentication & rate limiting

4. Write tests (unit & integration) – for the new API

5. Perform penetration testing

6. Redirect existing calls to the new API (for reuse)

7. Update existing tests (for the existing function) as needed

8. Create a new folder for API code in the repo

9. Update or create CI/CD pipeline

10. Deploy to development, pre-prod, and production environments

11. Secure endpoints (e.g., with WAF)

12. Add Logging and Observability

C] Going back to prioritization

• Now that you have a better understanding of what’s needed, you can calculate time required to do all these steps.

• Note that some of these steps are one-time effort and don’t need to be redone with newer APIs. For example, you don’t need a new environment with every new API.

• Now, depending on the timeline, you check how many functions can be converted to APIs. More often than not you’ll see that the timeline approved for the project is much lesser than required.

• Not every time you can offer what has been asked for. In those cases, you can explore below few things with the stakeholders:

D] Exploring options when in time-crunch

1. Can the scope (no of APIs) be reduced while timeline remains the same

2. Can the timeline be increased while number of APIs remain the same or with an increased number of APIs

3. Can you let go of some of the steps and take those later on?

   1. This is what is called introducing “Technical Debt”

   2. This is a sensitive call. Be aware of the trade-offs you’re doing here. For example, can you let go of writing tests or doing pen testing/security testing initially and take those later? What are the consequences here?

E] Open-Close Principle

• While designing or coding, always remember to support “Open-Close Principle”

• Simply put, your code or design should be open for extension and close for modification

• What this means is that your solution should be easy to extend without any (or very minimal) changes to the existing structure

• So, how to apply this principle here?

• Well, while designing and planning this, think about what if your new users change from internal engineering teams to the whole world? Meaning, what if you decide to make these APIs accessible by anyone in the world publicly? 

• That shouldn’t take you another 2 months to do! 

• That’s OC principle at work 🙂

Hope this was fun and informative to read. Working in real-world is sometimes fun like this. Happy Building 👍