Lob is an API company. That means that not only are our external product offerings all APIs, but that all of the internal tools we build are also APIs. We believe that an API-first approach to development improves the quality of our code and empowers our developers to be more productive.
What is API-First Development?
API-first development is the idea that whenever you are developing a piece of shared functionality for your organization it should be exposed as a RESTful HTTP API to all of your other developers. Rather than creating a library or module that needs to be added to all code bases requiring the functionality, developers can consume all the necessary functionality through the API. Having developers consume all functionality through an API enforces separation of concerns and hides internal complexity.
Enforcing Separation of Concerns
One of the most basic examples of using API-first development to enforce separation of concerns is to decouple the front and back ends of a web application. In this case an API is created to house the business logic and data access (the back end) which is only responsible for communicating through a RESTful interface with the front end. This makes it much easier for developers to create a front-end website, native mobile apps, and consumer facing APIs using the same back end.
At Lob, we believe taking this separation even further makes it easier for our developers to quickly create high quality applications. The example below demonstrates how the internal functionality for billing, accounts, and shipping have been moved to independent APIs that can be accessed over a RESTful interface.
This means whenever our team needs to add a new product offering which involves billing, shipping, or accounts there is a well documented interface with which to work.
Providing internal functionality through a RESTful API allows developers to abstract the complexity of that functionality away from the developers consuming the API. Consuming developers only need to know about endpoints, responses, and errors which can all easily be handled with quality documentation.
If I am the developer in charge of the billing functionality, here is just a sampling of the features I need to worry about:
- Multiple payment platforms (Stripe, Balanced, BrainTree, BitCoin, etc.)
- Payment Cycles (recurring subscriptions, one time charges, etc.)
- Issuing refunds and tracking credits
- Following up on unpaid bills and expired credit cards
However, if I am the developer in charge of a new product endpoint I am only concerned about things such as charge customer A $50 on June 12 or bill customer B $200 at the beginning of each month for the next year. I'm not concerned about which payment provider is used to charge the customer, whether the customer has credits on file, or following up with a customer to obtain a valid credit card. Internal functionality through RESTful APIs allows developers to focus their energy on the complexities of their product rather than everyone else's.
At Lob, we believe that APIs are the future for how businesses will communicate with one another. Enforcing this type of communication between our internal teams allows us to develop more efficiently and to learn what works and what doesn't when developing APIs. This has been a great learning experience for the team thus far. We have learned what tools allow us to be the most efficient and which ones hinder efficiency (we have since dropped CoffeeScript). The biggest challenges we have faced so far have been identifying how to efficiently and comprehensively test API endpoints and how to version breaking changes in an API.
If you have any thoughts on the use of RESTful APIs for internal functionality, the biggest challenges when developing APIs, or tools/techniques that you rely on for API development, we would love to hear about them!