Third Party(3P) API Boundaries ft. Clean Code

A Lakshaman Rekha to Use 3P API 😛😛😛😛😛

Clean Code….Naam to suna hi hoga (Famous SRK dialogue). A book which is followed by many engineers to write perfect code. Today we will cover Chapter 8 : Boundaries. The purpose of this post is to make a summary of the chapter so that you can revisit it quickly. I strongly recommend to read the chapter entirely, this is just for revision purposes. So let’s begin.

Using 3P API:

1. We want to use 3P APIs much as possible so as to get the shit done quickly and not bothering about writing something which is already there.
2. 3P APIs tries to keep their endpoints as generic as possible so that multiple clients can use them.
3. Whereas clients wants 3P API to behave as per their need and hence there is a tension between the API behaviour and client’s need.

Boundary of 3P API:

1. 3P APIs have some return types of the end points. Basically as a client we need to deal the object types of 3P API.
2. Using this return type object throughout our application might lead to pain in the future versions of 3P API as the return object structure might change and hence we will need to change everywhere we used it.
3. Specifying boundary usage for 3P API objects (both IP and OP) will make our job easy to handle any such upgrade in the API versions.
4. A practice that I prefer is not to use 3P API objects in application and restrict their usage with a Boundary. I prefer to have a corresponding object in my application. It gives one a centralise control over how to react to any change in 3P API.

EXPLORING AND LEARNING BOUNDARIES:

1. When you need to learn new API, it’s behaviour, you will spend some time learning it. Testing it.
2. Can we store this Testing effort?
3. Answer is : Yes.
4. A good practice is to write Tests and then try to learn API behaviour.
5. It gives you the following advantages:

You document your testing, so you know which all cases you know about API behaviour.

You can run this tests when API upgrades its version, so that you know which all behaviour is changed.

To summaries, we should have a Boundary where we interact with 3P API code, any change beyond this boundary should not affect our application code(in best case scenario). Best code is the one which can handle such changes with minimal changes.

Hope you liked it,

If you have any feedback, please feel free to comment or reply to the email.

If you like this and want to read more, please share this and subscribe Newsletter .

Find me @darshan_kadu

Cheers. See you again.