Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building the Brex API

building.brex.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Building the Brex API

#21

Post by pratikel »

dnautics wrote: post #17

> 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 lat…

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...

Re: Building the Brex API

#22

Post by dnautics »

pratikel wrote: post #21
dnautics wrote: post #17

> 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 lat…

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...

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)

Re: Building the Brex API

#23

Post by pratikel »

dnautics wrote: post #22
pratikel wrote: post #21

Earlier quoted context omitted.

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...

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)

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.

Re: Building the Brex API

#24

Post by nerdponx »

dnautics wrote: post #17

> 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 lat…

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.

Re: Building the Brex API

#25

Post by numair »

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-ko...

Re: Building the Brex API

#26

Post by sbuttgereit »

ianhawes wrote: post #9

How does Brex compare to Mercury?

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.

Re: Building the Brex API

#27

Post by dnautics »

nerdponx wrote: post #24
dnautics wrote: post #17

> 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 lat…

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?

Re: Building the Brex API

#28

Post by cosn »

numair wrote: post #25

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 contributi…

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.

Re: Building the Brex API

#29

Post by numair »

cosn wrote: post #28
numair wrote: post #25

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 contributi…

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…

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.
Post reply on HN