What Best in Class DX Looks Like

Introduction

Bloom’s mission is to modernize the tools for developers and innovators to compliantly expand access to affordable credit, which includes creating a best-in-class developer experience (DX) for engineers working with our API.

In order to deliver on this, we have to define exactly what “developer experience” entails, and then put a stake in the ground for what we believe not just a good, but best-in-class version looks like.

“It’s like user experience, but for developers” is a common answer. Albert Calvacante, Product Delivery Director at Semantix breaks DX down (https://medium.com/swlh/what-is-dx-developer-experience-401a0e44a9d9) into four pillars:

• Function
• Stability
• Ease of Use
• Clarity

This way of thinking about the problem space makes sense to us at Bloom, and we’ve sketched our product’s DX vision using this framework.

Function

The Bloom Credit API exists to provide a unified and modern interface both for getting data out of credit bureaus and furnishing accurate data back to bureaus. Everything we do – both for data access and furnishment – must be designed as a multi-bureau / bureau-agnostic solution.

For data access clients, we must provide direct access to normalized versions of all key attributes – in both summarized and elaborated formats – used to support extension of credit, account monitoring, and credit building use cases. It is imperative that attribute normalization and summarization calculations be performed correctly.

Likewise, for furnishment clients, accuracy is paramount. Calculated fields provided to bureaus must be correct. Data sanitization must be consistent and aligned to bureau requirements. The Bloom API’s input validation must be comprehensive to prevent errors as far upstream as possible. We must be able to support and generate all Metro2 segments, as well as data used by newer offerings, such as BNPL files.

Stability

The baseline reliability and availability of our systems must be at least as good as the bureaus. We will aspire to 99.975% availability [WIP: SLOs], with resilience to withstand the failure of a single AWS region.

Ease of Use

By leveraging the industry standard for RESTful services and GraphQL queries, the Bloom API reduces the barriers for entry for a new developer to adopt and leverage the services. There should be consistency in the interaction patterns; creating, updating, or deleting a record, placing or updating an order, initiating a furnishment job, etc are all RESTful in nature. Bureau attributes will be read through GraphQL. When building RESTful services, we adhere to the semantic definitions of the HTTP verbs.

The Bloom API should avoid making clients have to repeat themselves. Commonalities across the data-access and furnishment domains – eg consumer registration – shall be extracted, unified, and made into shared services.

We understand that the extension of credit decisioning use case is time sensitive and seek to optimize the number of calls across the wire a client needs to make.

The Bloom API is a multi-bureau solution, so functionality and data must be abstracted or normalized to a bureau-agnostic process / format. Underlying complexity should be hidden from our clients.

In addition to the API, Bloom will provide SDKs for Python, Go, Ruby, and Java to reduce integration effort for clients and reduce impact to clients of any API changes.

Clarity

Clarity starts with the design of the Bloom APIs themselves. Our APIs adhere to the industry standards of REST and GraphQL. Request parameters will have meaningful names that follow a consistent convention. Responses must provide meaningful diagnostic information.

SDKs provided by Bloom will adhere to widely accepted conventions of the language that they are written in, and avoid using language features in their APIs that would impede a proficient developer in that language from implementing a solution using our SDK.

When writing documentation, Bloom will take their cues from Mason Eggers’s PyCon 2022 talk on the subject (https://thenewstack.io/an-engineers-best-tips-for-writing-documentation-devs-love/) and aspire to:

• Solve real world problems
• Get to the point using plain and inclusive language
• Provide code examples, and in more than one language
• Define acronyms at first use