Milkman@eBay
An extensible alternative to Postman for API development
At eBay, we live in a service-oriented environment. Internally, we have to orchestrate around 3,500 services, all of which offer an interface of some kind providing data or functionality to (several) other services.
When working with those services, a developer often has to manually send requests to those interfaces, maybe to look up some data or to test an assumption. When developing/modifying a service, developers send requests to this service to test the outcome of their changes locally.
Over time, a lot of those requests accumulate and the need arises for a tool to organize, quickly draft and execute those requests. We are used to Postman to test our services, and it is our daily bread. There are other alternatives that can be used, for example Insomnia, but these are less common.
Milkman
Milkman is a newly developed alternative to Postman that was designed from the ground up with extensibility in mind. Everything in Milkman is a plugin, for example, a database query plugin for making SQL queries in the same manner as you work with HTTP requests in Postman. There is also a team-sync plugin for synchronizing your workspaces using a Git repository. The application is open source and freely available.
It was written in Java using JavaFx, which provides a better usage of resources than some Electron applications. Due to its skinnability via CSS, different themes are available and can be added as plugins as well.
Why another tool?
Having an off-the-shelf application ready to use is a good thing, but because these are general-purpose tools, they can never be as useful as a tool customized to the actual requirements at eBay and maybe also at other companies.
All kinds of requests can be set up in tools like this, but making things more easily accessible, faster and more customized helps to streamline the developer experience. This helps new developers get ready to go faster and maybe spreads knowledge about lesser-known information sources in the available environment. It gets rid of recurring tasks and helps experienced developers find the right information faster.
eBay requirements
With 3,500 services, we need some kind of service registry and processes for properly documenting service APIs. At eBay, we use an internal service registry, which contains information about all existing services and documentation about the interfaces they provide using a format similar to OpenAPI. This well-known place allows developers to look up services they want to send requests to and set up a corresponding request in their tool of choice.
We developed several extensions to Milkman that allow the user to import new requests from this registry by just typing the name of the service. Everything else will be handled by the new importer and the service registry.
Similar to a central registry of services, there are similar directories of available databases to connect to.
Another plugin allows developers to import all database connection strings so that they can use the “logical” name of a database directly.
Also, due to the way eBay-internal infrastructure is set up, we always have to configure a specific proxy and although this is a small task, it can be set up right from the get-go, so developers do not have to worry about this anymore.
A fresh installation of Milkman with the eBay extensions allows for a one-click setup of the proxy details and an exclusion list tailored to eBay infrastructure. No need to figure out the proxy details or ask colleagues.
eBay-internal communication between services adheres to some standards. There are well-defined headers that have to be populated with the right values in the right encoding. For security reasons, OAuth tokens have to be supplied to authorize every call. When creating a new request manually, it is tedious to set up those headers. Also, an OAuth token, which expires after some time, has to be retrieved first from some other service so that the actual call can be made.
We created a plugin that provides a nice UI for setting up those headers, looking up of user IDs or minting tokens. No context switching is necessary anymore to look up some details on a different tool, and solving this task is now a matter of seconds.
Additionally, a response from a service also contains information in specific headers that can be used to debug what actually happened. Examples of such details are an ID that can be used to look up the logs in our centralized logging system. Other details contain information about downstream calls or tracing information using OpenTracing headers. To actually access the information, developers have to know where to actually go to make use of these IDs.
Similar to extending the UI for request headers, a customized UI for analyzing the provided information is directly available inside Milkman. Using this, you can jump directly to the right logs or analyze downstream calls made. This saves time and may also teach developers a new trick in analyzing response information.
Bottom line
Having a customized tool to test services helps all kinds of developers within a company.
- New developers don’t have to learn about special headers, some obscure service registries or such to get started and try their first requests.
- Existing developers might learn new functionality such as a diagnostic tool that helps them analyze call traces because it is now surfaced in their day-to-day tool
- Experienced developers speed up their workflow by saving time. They don’t have to switch contexts, go to that website or look up this ID in that tool, because it’s just a built-in one-click action now.
