> One of the best decisions we made was to auto generate the OpenAPI specs from our code.
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.
I wouldn't say it's hard to do it in Elixir; I did it as an elixir NOOB, junior dev 4 years ago: https://github.com/ityonemo/exaggerate -- if you look at the code history it was completed in about 3 weeks (but there's a reason this isn't on hex.pm; surely a company with many seniors has the bandwidth to do something like this right and share it with the community)
OpenAPI seems weirdly under-used and under-appreciated. OAS 3.1 has full JSONSchema compatibility and is generally (in my opinion) an excellent tool. But pretty much nothing supports it, not even the Swagger.io products. It's like people want to keep doing things the old hard way.
this is a huge pain point OAS 3.1 is "basically perfect" and I wish so much we could transition to it, but we expose our API via Swagger.io, so we can't transition yet.
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?
thanks for the insight. either way, would be nice of them to either open source their solution (or if they are using someone else's point us to which one they picked)
This is really cool to see. At the start of my YC batch, when I was still dabbling with building general accounting ledger systems as a service, I discovered that the GraphQL API Brex itself was using was, actually, pretty usable. Schema introspection worked. I was able to write scripts with it. Looks like they went with REST for the truly public one, but it's good to see it at all frankly.
I was wondering why Brex left Elixir, and what happened to all of the tooling they created to work in the language. From their blog[1]:
> 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.
Brex CTO here. I completely agree with you, the issue isn't that we expect something in return. When you invest in a new language community, it's not about expecting something in return, you're investing in its growth. We've sponsored several core language projects and maintainers, and have open sourced many libraries, and we did it so that the ecosystem gets more fuel to develop and grow.
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.
I appreciate the reply. I think you have good intentions. If you’re going to leave the Elixir world, it would be good to open source whatever you can on the way out.
I'm seeing a lot more APIs adding the "Bearer " prefix which I don't really understand. What's the point of it? This particular one doesn't even look like a "conventional" bearer token in the JWT sense.
The “bearer” prefix indicates the token is a “bearer” type token, as defined in RFC6750. As opposed to, for example, a “mac” token type.
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.)
Bearer tokens precede JWT and it's part of the Authorization header.
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.
Is there? If it's a custom token type, the serverside will never break with it. The client generally wants the caller to provide the "Bearer" string as well; can it break without it?
Another thing Mercury is missing is basic expense management like attaching receipts to transactions.
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.
They're both good and much better than old-school banks like SVB / FRB etc. Brex also offers charge cards which Mercury doesn't (not sure if they have debit cards) so Brex has a broader set of things to offer.
Readit News
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?
> 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.
Deleted Comment
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.
https://ramp.com/ramp-vs-brex
https://getdivvy.com/divvy-vs-brex/