[HN Gopher] Building the Brex API
___________________________________________________________________
Building the Brex API
Author : hdubugras
Score : 88 points
Date : 2021-10-21 17:29 UTC (5 hours ago)
(HTM) web link (building.brex.com)
(TXT) w3m dump (building.brex.com)
| [deleted]
| pbreit wrote:
| 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.
| umurkontaci wrote:
| 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.
| HeavenFox wrote:
| 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 wrote:
| 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?
| aaronbrager wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| dnautics wrote:
| > 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 =(
| pratikel wrote:
| 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-ko...
| dnautics wrote:
| 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)
| pratikel wrote:
| Sure. I'd frame this question of not whether these
| endeavors are difficult or possible but rather if they're
| the best way to use our time and effort to serve our
| customers.
|
| FWIW on the note of OSS, we've made some minor
| contributions to micronaut and other open-source projects
| we use. We love OSS and are happy to make contributions and
| work with the broader community! The community and
| ecosystem has been incredible for us so far.
| MediumD wrote:
| I no longer work at Brex, but I believe they did this using
| Kotlin rather than Elixir.
| dnautics wrote:
| 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)
| joshuakelly wrote:
| 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.
| alevy1511 wrote:
| Love this!!!
| ianhawes wrote:
| How does Brex compare to Mercury?
| bradgessler wrote:
| 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.
| _pr0ton wrote:
| 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 and
| recommends Brex Cash.
| bootcat wrote:
| what do you guys think about ramp or divvy ?
|
| https://ramp.com/ramp-vs-brex
|
| https://getdivvy.com/divvy-vs-brex/
| bradgessler wrote:
| Mercury has physical and virtual debit cards. No credit card
| products yet.
___________________________________________________________________
(page generated 2021-10-21 23:01 UTC)