I'm curious as to what they used to do this. It's been a major pain point for me for five-odd years that Elixir Phoenix (don't know if Brex used Phoenix for this) doesn't have an OpenAPI autogenerator, and, now, this is my third job where I'm building an OpenAPI API in Elixir, so I got permission to open source our solution later this year.
Would have been nice to collaborate, but I guess Brex is leaving Elixir, so, there's that. They kind of had a bit of a reputation for not contributing much code back to the ecosystem =(
I'm the author of the post and we built the API on Kotlin and some of them are our earliest Kotlin services. We're using Micronaut OpenAPI to generate specs.
You're right in that it's hard to do many of these things in Elixir and it was a big factor in us moving away from Elixir. I wrote a bit about it here https://medium.com/brexeng/building-backend-services-with-ko...
I think OpenAPI is losing out the sexiness battle against graphQL, but I will say this: There's a way in which OpenAPI inherently makes you reflect on distributed systems errors. What are you going to do if a request 500's and you need to maintain consistency between two data systems?
The bearer token can be a JWT, but can also be a different format of bearer token as long as it conforms to the requirements in the spec (ie, only certain characters are allowed).
A “bearer” token means whoever has the token has authorization to perform the action. (Section 1.2 of the RFC goes into more details.)
Most APIs just have you set a key in the "Authorization" header. I don't get what value the "Bearer " prefix adds.
That RFC is strange and seems it can be summarized in one line:
Include header "Authorization: Bearer [API key]" for authenticating API calls.
For authentication & authorization, the caller sends a bearer token. The format of the token is known to both parties and the server knows how to validate it.
It's better than username password combos because (1) not every "account" has a password, (2) tokens can and generally do expire, (3) it's not tied to the password if the password changes the tokens continue to be valid, (4) the user can invalidate the tokens of their choice, (5) you can grant restricted permissions to a token. You can do more or less things with tokens based on the needs of the application but it decoupling it from password gives you additional security and flexibility.
If you signed up for Mercury today, you’d look at Brex and think, “Eugh, I should have signed up for Brex”.
A sweeping generalization is that Mercury and Brex are the same thing, but Brex is further ahead in terms of basic features to manage a small SaaS business. Mercury will hopefully deploy their capital to build out these features.
The Mercury sign-up process was opaque. We fulfilled all their requests and eventually they went dark on us. Turns out that they were waiting on us for something (that we didn't know they were waiting on). But we had no way to see the progress, that they were waiting on information for us, or what they thought was outstanding. Inquiries to customer support took way too long to answer (several days for a response). That support also (as I recall) was conducted through regular email, we decided that the operations didn't inspire trust and we ceased trying to engage.
After our experience with Mercury, some time later we tried Brex. The sign-up process was simple. We provided everything they asked for and our application was approved quickly and efficiently. A day or two after approval, I went to begin the process of funding the new account and was greeted with a message that the account had been suspended. As is common, no reason was given nor would their support assist in resolving the issue. A week or so later the account was terminated without explanation. Weeks after that I continued to get various account maintenance emails for the account they closed (finally had to blacklist to the spam folder, probably still getting them). Luckily we had no transactions and no open balances. I hesitate to think how screwed we'd be had we actually started transacting business.
Both of these companies offered compelling services that we were interested in and matched our needs well. Both of these companies had execution that felt completely fly by night and wasted a lot of time with no result. I get it... start-ups... move fast, break things... but with our money and ability to conduct business on the line, I was left very put out.
Satchel a SaaS buying-guide (kinda like Wirecutter for startups) wrote an in-depth guide here https://satchel.com/store-of-money/#recommendations and recommends Brex Cash.
> Building and maintaining internal libraries to support Elixir as our primary backend language became time consuming, and few other users in the ecosystem seemed to share enough use cases to make OSS collaboration mutually beneficial.
The whole point of giving things, and contributing code, is to do it without the expectation of a return or that anyone will even use it. It’s the mystery and the surprise of the way in which others benefit that makes our entire ecosystem work. When companies ride on the volunteer labor of others to become worth billions, and then come up with all sorts of excuses for why they can’t give back... I guess the success of AWS demonstrates that nobody will care.
1: https://medium.com/brexeng/building-backend-services-with-ko...
But that also doesn't mean we never evaluate what makes most sense for us as we continue growing ourselves. We have >400 engineers at Brex, so many things internally have had to evolve over the years, including our decision to build things in different languages (we now additionally support Go, Kotlin, Python & TypeScript, each for specific domains).
Even as we write more backend services in Kotlin, Elixir will continue existing for a long time, and we're continuing to work close with the broader community.
