rattray

Long list, I've been meaning to write a blog post.

I recently paid >$1000 for the privilege of access to iMessage when switching from Android to iPhone. I'd have been _much_ happier staying on my preferred operating system and paying $24/yr.

(iMessage has, for me, actually been worth it - but still, I frequently find myself wishing that something like Beeper Mini existed so I could go back to android).

Have you tried django-ninja or FastAPI?

You might be interested in Jebtrains' Kotlin Compose Multiplatform, which lets you cross-compile to native UI in iOS, android, and others - and pretty smoothly interop with native iOS code (especially UI code).

https://www.jetbrains.com/lp/compose-multiplatform/

I think it's new, and I haven't tried it myself.

Ideally yes but the old code search may also require costly infra, like building specialized indexes of the codebase (eg an elasticsearch index).

Since those are "fixed costs" per repo rather than per search, they'd now be much more expensive per search if they were only used by logged-out users.

Pure outside speculation of course.

OOC, was this a google doc or a docx file uploaded?

Claims to be faster (when using multiple cores) but beyond that, I'm also curious.

Speaking as a contributor to Prettier, it is _not_ an easy codebase for someone who knows JS to just jump into and contribute.

Furthermore, projects like Ruff show you can have a lot of contributors for projects like this. Maybe because there are lots of devs who use TS or Python in their day job, but want excuses to use Rust on the side.

I disagree with this decision by Arc, and had the same reaction you did, but I just want to note that I'm very glad I gave it another shot months later – it really is a fantastic browser, much better than FF or Chrome.

Where can I learn more about this?

Webhooks are definitely the most standard way of doing this in my experience.

Have you looked at svix.com ? (I have no affiliation)

Yep. For frontend use, I think https://www.npmjs.com/package/openapi-typescript is the most widely-used/well-regarded, though https://www.npmjs.com/package/orval seems to me to have some nicer features like react-query support.

There are other options too, I'd just stay away from "_the_ openapi generator" (https://openapi-generator.tech/) which does a pretty poor job IMO.

Disclaimer: I'm the founder of a company doing SDKs commercially, but we don't focus on the frontend right now, and our free plan is still in beta.

seems to be Szymon Sidor – https://archive.is/Ij684#selection-595.304-595.316

Who is "Simon"? Link to source re; departure?

+1, I work at a similar company (https://stainlessapi.com) and have had the exact same conclusions. We use LLMs in similar ways.

Well said @ThomasRooney.

There may be other contexts where pure LLM codegen could work well, but I haven't really encountered them personally yet.

Stainless | Founding Engineer | NYC ONSITE | Full-time

Stainless is building the platform for high-quality, easy-to-use APIs.

Our first product is SDKs as a service – you send us your OpenAPI spec, and we generate packages in all the major languages and publish them to npm/pypi/etc (e.g., `npm install openai`, which is a package we produce).

These SDKs are world-class: you get an idiomatic wrapper with autocomplete, types, etc. (I built a version of this at Stripe for their SDKs, and am now building a better version for everyone.)

Next, we want to make it easy to build amazing REST APIs. REST is simple and ubiquitous, but right now it’s also messy, chaotic, and hard to get right. We’re going to build great open-source standards and tooling that bring the benefits of GraphQL (types, field selection/expansion, standards) and gRPC (types, speed, versioning) to REST.

From there, we plan to build out a rich family of developer platform products – everything an API team would need to deliver a terrific DX to their partners and/or customers.

We’re about 1.5y old, under 5 people, have strong revenue, and are selling to companies you interact with every day. We’re backed by Sequoia, a bunch of (ex-)Stripe people, and founders of Next.js, Prisma, and Segment.

As a founding engineer, you’ll get autonomy to build great products, skilled peers, opportunity for tremendous impact, competitive salary, and a very competitive ownership stake.

We’re looking for exceptionally productive, thoughtful, tasteful, and kind people with a passion for making software development better for everyone. Want to build the future of API tooling? Say hi: alex at stainlessapi.com

I'm getting Jan 2022 on 3.5 & 4. Maybe OP is lucky?

https://www.useoptic.com/ is another one, which is a little more tailored to building & updating OpenAPI specs. Works well on live traffic and/or tests.

For a compact message format being sent to browsers, you might look at messagepack, eg with https://github.com/msgpack/msgpack-javascript – it's essentially binary JSON, so it'd be compatible with OpenAPI specs.

I think the ser/des is slower than JSON in most browsers, but the message format is smaller.

Oftentimes, using a query parameter like `?exclude[]=…` or `?include[]=…` or similar to say "only get me these response fields, not the whole object" can be useful for this too (and then you still get JSON back).

Stainless | Founding Engineer | NYC ONSITE | Full-time

Stainless is building the platform for high-quality, easy-to-use APIs.

Our first product is SDKs as a service – you send us your OpenAPI spec, and we generate packages in all the major languages and publish them to npm/pypi/etc (e.g., `npm install openai`, which is a package we produce).

These SDKs are world-class: you get an idiomatic wrapper with autocomplete, types, etc. (I built a version of this at Stripe for their SDKs, and am now building a better version for everyone.)

Next, we want to make it easy to build amazing REST APIs. REST is simple and ubiquitous, but right now it’s also messy, chaotic, and hard to get right. We’re going to build great open-source standards and tooling that bring the benefits of GraphQL (types, field selection/expansion, standards) and gRPC (types, speed, versioning) to REST.

From there, we plan to build out a rich family of developer platform products – everything an API team would need to deliver a terrific DX to their partners and/or customers.

We’re about 1.5y old, under 5 people, have strong revenue, and are selling to companies you interact with every day. We’re backed by Sequoia, a bunch of (ex-)Stripe people, and founders of Next.js, Prisma, and Segment.

As a founding engineer, you’ll get autonomy to build great products, skilled peers, opportunity for tremendous impact, competitive salary, and a very competitive ownership stake.

We’re looking for exceptionally productive, thoughtful, tasteful, and kind people with a passion for making software development better for everyone. Want to build the future of API tooling? Say hi: alex at stainlessapi.com

Do you have browse enabled? Apparently it's rolling back out.

A package I help maintain was released about a month ago, and we've had bug reports related to this: https://github.com/openai/openai-node/issues/304#issuecommen...

We simply chose to mark Jest 27 as unsupported in this case, but it did cost some debugging time.

Note that jest before v27, and some other runtimes, don't support export maps.

Sorry, I missed the link to https://github.com/sugawarayuuta/benchmark – I don't find its contents very easy to digest, and there's often more to an encoding library than benchmark perf - how does it compare in terms of functionality, correctness, etc would be great to cover too. The README just has vague discussion of "some other alternatives" which isn't very actionable.

How does this compare to the ones from segment?

How popular is fig compared to warp?

Which four companies?

This matters a lot; am I the only one skeptical about this move just being about cloud competitors trying to preserve margin?

Yeah, most are pretty crappy.

Curious if you give ours a try: https://stainlessapi.com (it's a commercial/non-oss option, but one language is free for smaller APIs). You can see an example of a Python library we generate here: https://github.com/Modern-Treasury/modern-treasury-python

Yeah, the path you're talking about is pretty common actually. Companies handwrite one SDK in the language they're most familiar with, then use OpenAPI-Generator to produce a few others and try to patch up the obviously broken things.

They tend to get quite sick of both hand-maintaining any SDK (even in the language they love), and of dealing with the problems/toil of the openapi generator (or the user complaints of the non-idiomatic code they didn't understand, because it was in a different language).

Still, it's better than nothing, so I applaud those who take on the effort!

Thanks for the kind words – we hope to help bring the well-typed nature of gRPC to REST, without making things more complicated.

It's just a ton of work to make a good SDK in every major language.

Something I haven't seen mentioned much on this thread is that the ~top feature people want from SDKs at this point is good static types – so you can get autocomplete, docs-on-hover, etc in your editor. Way better than switching back and forth to the docs and crossing your fingers.

Doing that well means copying every little change into the SDKs (forget about it) or using a generator.

The open-source codegen tools (ie, https://openapi-generator.tech/) are pretty crappy, so you need to either build the SDK yourself fully, or spend a bunch of time wrestling with the generator get it halfway-decent, and then you're still letting your customers/developers down.

Disclaimer, I'm starting a company to make it easy for anyone to ship a great SDK with their REST API: https://stainlessapi.com