7 ms·

Building the Brex API

105 points by hdubugras 5y ago

deleted 5y ago
[deleted]
pbreit 5y ago
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.
- aaronbrager 5y ago
  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.)
  - pbreit 5y ago
    Isn't that just fancy phrasing for a username/password? 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.
    - jorams 5y ago
      The specified (rfc7235) syntax of the Authorization header is that it starts with an authentication scheme, followed by the parameters for that scheme. "Bearer" is one of those schemes. "Basic" and "Digest" are others.
    - dreyfan 5y ago
      > Isn't that just fancy phrasing for a username/password? Not quite. username/password authenticate who or what something is; bearer tokens permit what actions can be taken by the holder of that token, and tend to be short-lived in nature and ideally for very specific actions.
- HeavenFox 5y ago
  It's part of the HTTP standard for `Authorization` header, and there is the possibility of some HTTP client / server breaking if you don't add it.
  - tptacek 5y ago
    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?
- umurkontaci 5y ago
  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.
ianhawes 5y ago
How does Brex compare to Mercury?
- _pr0ton 5y ago
  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. Satchel a SaaS buying-guide (kinda like Wirecutter for startups) wrote an in-depth guide here https://satchel.com/store-of-money/#recommendations https://satchel.com/store-of-money/#recommendations and recommends Brex Cash.
  - bootcat 5y ago
    what do you guys think about ramp or divvy ? https://ramp.com/ramp-vs-brex https://ramp.com/ramp-vs-brex https://getdivvy.com/divvy-vs-brex/ https://getdivvy.com/divvy-vs-brex/
  - bradgessler 5y ago
    Mercury has physical and virtual debit cards. No credit card products yet.
- bradgessler 5y ago
  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.
- sbuttgereit 5y ago
  I ended up disliking both. 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.
alevy1511 5y ago
Love this!!!
dnautics 5y ago
> 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 =(
- MediumD 5y ago
  I no longer work at Brex, but I believe they did this using Kotlin rather than Elixir.
  - dnautics 5y ago
    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)
- pratikel 5y ago
  Hey, 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-kotlin-7c8410795e4b https://medium.com/brexeng/building-backend-services-with-ko...
  - dnautics 5y ago
    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 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)
joshuakelly 5y ago
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.
numair 5y ago
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. 1: https://medium.com/brexeng/building-backend-services-with-kotlin-7c8410795e4b https://medium.com/brexeng/building-backend-services-with-ko...
- cosn 5y ago
  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.
  - numair 5y ago
    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.

105 points by hdubugras 5y ago

deleted 5y ago

[deleted]

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.

aaronbrager 5y ago
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.)
- pbreit 5y ago
  Isn't that just fancy phrasing for a username/password? 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.
  - jorams 5y ago
    The specified (rfc7235) syntax of the Authorization header is that it starts with an authentication scheme, followed by the parameters for that scheme. "Bearer" is one of those schemes. "Basic" and "Digest" are others.
  - dreyfan 5y ago
    > Isn't that just fancy phrasing for a username/password? Not quite. username/password authenticate who or what something is; bearer tokens permit what actions can be taken by the holder of that token, and tend to be short-lived in nature and ideally for very specific actions.
HeavenFox 5y ago
It's part of the HTTP standard for `Authorization` header, and there is the possibility of some HTTP client / server breaking if you don't add it.
- tptacek 5y ago
  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?
umurkontaci 5y ago
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.

ianhawes 5y ago

How does Brex compare to Mercury?

_pr0ton 5y ago
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. Satchel a SaaS buying-guide (kinda like Wirecutter for startups) wrote an in-depth guide here https://satchel.com/store-of-money/#recommendations https://satchel.com/store-of-money/#recommendations and recommends Brex Cash.
- bootcat 5y ago
  what do you guys think about ramp or divvy ? https://ramp.com/ramp-vs-brex https://ramp.com/ramp-vs-brex https://getdivvy.com/divvy-vs-brex/ https://getdivvy.com/divvy-vs-brex/
- bradgessler 5y ago
  Mercury has physical and virtual debit cards. No credit card products yet.
bradgessler 5y ago
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.
sbuttgereit 5y ago
I ended up disliking both. 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.

alevy1511 5y ago

Love this!!!

dnautics 5y ago

> 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 =(

MediumD 5y ago
I no longer work at Brex, but I believe they did this using Kotlin rather than Elixir.
- dnautics 5y ago
  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)
pratikel 5y ago
Hey, 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-kotlin-7c8410795e4b https://medium.com/brexeng/building-backend-services-with-ko...
- dnautics 5y ago
  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 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)

joshuakelly 5y ago

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.

numair 5y ago

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. 1: https://medium.com/brexeng/building-backend-services-with-kotlin-7c8410795e4b https://medium.com/brexeng/building-backend-services-with-ko...

cosn 5y ago
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.
- numair 5y ago
  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.