Their PR really puts me off. Makes me think the authors are sneering at everyone who uses JSON. And who says they get to deprecate anything?
Buf raises $93M to deprecate REST/JSON
41–50 of 91 posts
Re: Buf raises $93M to deprecate REST/JSON
#42I’m not up-to-date with protobuf, but last time I reviewed it like 4 years ago, it still wasn’t consistent at describing schemas as well as avro, esp in describing schema changes.
Good luck to buf.build to sell a revamped wsdl and getting everyone to adopt it.
Re: Buf raises $93M to deprecate REST/JSON
#43Earlier quoted context omitted.
I don't even know why they need so much money for what they do. Based on their website, they solve the following problems: - a central schema registery. Even if that's something you actually want, it's not a problem that requires $93M to solve, or a commercial company to operate - communicating schema changes primarily via human-oriented sources like handwritten documentation on emails. I mean sure, if you are a maso…
Hmm well I get that we're in an asset bubble with startups, but if this company is creating jobs, then I think it's somewhat reasonable to assume that they are fixing a problem ppl are willing to pay for. I do agree with what you're saying from my perspective as an average swe that doesn't do anything highly specialized... I wonder though, what would the workflows look like for a swe, product, ops person even, where…
Is there enough money to recoup investment if they don't get the average engineer churning out crud apps?
I mean, there probably is, but what kind of market penetration would this require if you are only going after the specialists?
Re: Buf raises $93M to deprecate REST/JSON
#44Hmm why do they need to raise so much cash every 9 months? Also does anyone here use them and have any thoughts about their product?
> Hmm why do they need to raise so much cash every 9 months? Well, they say the best time to take investment is when you don't need it. If you wait until you need it then the terms will be worse. If investors are offering you money when you don't need it, it may be the best time to accept it. The sequence of raises here look like a fairly normal sequence for a growing startup, except that they happened much closer to…
Would there be a free reader? What is their business model?
Re: Buf raises $93M to deprecate REST/JSON
#45[deleted]
Re: Buf raises $93M to deprecate REST/JSON
#46When shit like this happens, I just always think "I don't understand finance at all and never will."
I read the company's primary blog blog post, https://buf.build/blog/api-design-is-stuck-in-the-past, about "schema driven development" and agree with a lot of it. Which is why I'm a huge fan of GraphQL and related completely free open source libraries, where I define my API endpoints with a strongly typed yet easily evolvable schema, and auto-generate my Typescript types from my GraphQL definitions.
$93 million dollars is just nuts to me.
Re: Buf raises $93M to deprecate REST/JSON
#47A case study of the pandemic speed of capital: May 2020- $1M Pre-Seed Sept 2020- $3.7M Seed April 2021- $20.7M Series A Dec 2021- $68M Series B How can so many rounds be condensed so quickly for a business like this? Is the number of Homebrew downloads (37k as advertised on the home page) a metric that can lead to an 18 month ramp to Series B now? I think there's a trend at play here I'd love to hear more about.
Maybe it's a lot more simple, like they have someone that's ridiculously good at raising venture capital, like the Posthog guys.
TBH not really. I've talked to the founder a few times. He doesn't want to put his name on things, as he's kind of a private person and really wants to direct the spotlight at his employees. But he's just an engineer who has spent a lot of time working with Protobufs, not a sales person at all.
(Disclosure: I was the maintainer of Protobuf who put together the first open source release at Google, and I made a small investment in buf early on.)
Re: Buf raises $93M to deprecate REST/JSON
#48When shit like this happens, I just always think "I don't understand finance at all and never will." I read the company's primary blog blog post, https://buf.build/blog/api-design-is-stuck-in-the-past , about "schema driven development" and agree with a lot of it. Which is why I'm a huge fan of GraphQL and related completely free open source libraries, where I define my API endpoints with a strongly typed yet easily…
I was just about to ask ‘what are the differences between this and GraphQL?’ Maybe tag on an AWS AppSync & DynamoDB, and you have pretty much all of this?
And before anyone goes all ‘but what about Dropbox?’ when scrutinizing this idea... Dropbox was never really made for technical people, this is squarely at people who know what JSON means, so technical.
Re: Buf raises $93M to deprecate REST/JSON
#49Earlier quoted context omitted.
> Hmm why do they need to raise so much cash every 9 months? Well, they say the best time to take investment is when you don't need it. If you wait until you need it then the terms will be worse. If investors are offering you money when you don't need it, it may be the best time to accept it. The sequence of raises here look like a fairly normal sequence for a growing startup, except that they happened much closer to…
> FWIW, long ago I was the maintainer of Protobuf at Google, including putting together the first open source release. I like what buf is doing -- enough that, full disclosure, I made an angel investment in their seed round. I know this might not be the best way to ask but have they considered creating proto rules for Bazel? The existing proto + gRPC story is pretty unfortunate.
Huh. As the person who literally implemented the original proto_library rule in Blaze (which was later publicly released as "Bazel"), I'm a bit surprised to learn this doesn't work well today... but admittedly I haven't had the opportunity to try Bazel since the public release. What is the story today?
Re: Buf raises $93M to deprecate REST/JSON
#50Lol. Imagine trying to capture a market that is already mostly happy with what it's got, and for free.
Imagine this offering: "Why go through the hassle of generating clients for your service for each language when we can build ergonomic clients automatically" and "Why manually look for breaking changes in your API when we can detect them manually" or "We can give you $AMAZING_FEATURE for free by using a clearer language to describe your api" where your feature could be: 1. Reduced bandwidth ingress 2. Automatic traci…
> Why manually look for breaking changes in your API when we can detect them manually
You can't detect all breaking changes automatically. A field can subtly shift semantics on an API level, yet that breaks a workflow for some downstream consumer somewhere.
OpenAPI and other API description languages give a clear an unambiguous description of an API that can auto-generate clients just fine. Binary JSON/gzipped JSON is frequently very space efficient too. I'm happy to grant the rest of your points, but I cannot see that much value here from an SME perspective. Using tracing and other advanced techniques require the right knowledge to use, and I don't think it's that common in smaller orgs.