rattray

> Stripe are lying when they say their IDs are random

Where does Stripe make that claim?

I think most of the value of Stripe-style IDs is in their other properties, like the information they bear, readability, copy-pasteability (which uuids lack - double-click to select often stops at hyphens), etc.

Either of those situations should be very easy to catch and prevent with basic rate limiting and monitoring.

Anyone else confused with this name vs Microsoft Entra, the new name for Active Directory?

Is there any shared etymology between Ente and Entra? I'm curious where both come from.

Stainless | Generalist Engineers, First AE | NYC ONSITE | Full-time

Stainless is building the platform for high-quality, easy-to-use APIs. Our first product is SDKs as a service.

When you `npm install openai` or `pip install anthropic` or `go get …cloudflare`, for example, you’re downloading code that we generated. (I built the codegen system 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.

We’re ~2y old, ~10 people, have strong revenue (could choose to be profitable), and great customers (including OpenAI, Anthropic, and Cloudflare). We’re backed by Sequoia.

As one of our first ten engineers, 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

Ah, interesting! Thanks!

Right; what does it look like with bun?

Sorry if I'm being dense/lazy, but can you give an example of what this looks like:

> Bun shell replaced the need for something like “concurrently”.

What do you mean "got shutdown"? What happened?

What do you know of / think of Daniel Gross? What is his reputation?

Is there more you can share, or point to?

Sounds like he might become an important player soon and it'd be helpful for people to learn what they can.

Stainless | Generalist Engineers, First AE | NYC ONSITE | Full-time

(We were on hn recently: https://news.ycombinator.com/item?id=40146505)

Stainless is building the platform for high-quality, easy-to-use APIs. Our first product is SDKs as a service. When you `npm install openai` or `pip install openai`, for example, you’re downloading code that we generated. (I built the codegen system 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.

We’re ~2y old, ~10 people, have strong revenue (could choose to be profitable), and great customers (including OpenAI, Anthropic, and Cloudflare). We’re backed by Sequoia.

As one of our first ten engineers, 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 develop client SDKS)

It could make sense for first-party SDKs for an API to block http access to the first-party API domain, but that should be unnecessary – typically users would use the default base URL hardcoded in the client library, and only replace it if they're going through some other proxy.

When they _do_ go through some other proxy, it's commonly in an internal network of some kind, where http is appropriate and should not be blocked.

I mean, did they specifically check that the Kindle app works well on their OS.

Is the kindle app not supported?

If someone from the wikimedia enterprise team is here and interested in providing those SDKs, but finds the openapi generator linked above to be lacking, I'd be happy to help (my company does the SDKs for OpenAI, Cloudflare, etc).

I've been a monthly donor to wikimedia for a long time and it'd be quite a privilege to support them with nice API wrappers too. Email in profile.

Title needs a (2020) - this is an old classic. It does have a minor 2023 update to include more sample code.

Stainless | Generalist Engineers, First AE | NYC ONSITE | Full-time

(We were on hn recently: https://news.ycombinator.com/item?id=40146505)

Stainless is building the platform for high-quality, easy-to-use APIs. Our first product is SDKs as a service. When you `npm install openai` or `pip install openai`, for example, you’re downloading code that we generated. (I built the codegen system 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.

We’re ~2y old, ~10 people, have strong revenue (could choose to be profitable), and great customers (including OpenAI, Anthropic, and Cloudflare). We’re backed by Sequoia.

As one of our first ten engineers, 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

It definitely isn't easy, but it's the kind of challenges we love! You mentioned many of the big ones, but there's also just the sheer scale of the userbase, which means the libraries will be run under every permutation of runtime and configuration under the sun. It's a lot of edge cases to get right!

Their team is great to work with, which helps make it worth it.

(Note that a lot of the SSE type stuff we do generally so we're able to support a variety of AI companies and other streaming use cases, though disclaimer it is a premium feature)

Very different! Stainless crafts each language's SDK generator around its specific idioms.

> We didn't ship public SDKs. So, maybe that's what I'm missing

Yeah, Stainless is more focused on public SDKs, which can be a lot trickier and more demanding.

Some more details replying to your other comment here: https://news.ycombinator.com/item?id=40148629

If it works great for you, that's great – stick with it!

From what I've seen, a lot of API developers find that openapi-generator flat-out breaks or produces broken code for their OpenAPI spec (varies language-to-language of course).

Beyond hitting the "it just works" mark more often, some other key differentiators:

1. much easier to configure & customize

2. auto-retry with exponential backoff (this is huge for our customers)

3. auto-pagination

4. overall ergonomics of using the SDK

5. internals that look handwritten (some people care, others don't)

6. one-click releases to github & package managers w/ semver, changelogs, etc

7. careful handling of edge cases (eg, will adding a new enum variant cause your Java client to crash?)

8. a long tail of more advanced features, like webhook signature verification, streaming, etc

Thanks for the question – hope this helps :)

> I don't know where to start to actually codegen an OpenAPI spec from a Ruby/Rails API… How did Stripe handle this?

Stripe built their own Ruby DSL for exactly this, and it worked great. It looked something like this:

    class CreateCustomerMethod < AbstractAPIMethod
      endpoint "post /v1/customers"

      returns CustomerAPIResource
      
      required :name, String, description: "The name of the customer."
      optional :description, String, description: "Additional information about the customer."

      def execute
        # …
      end
    end

Unfortunately, I don't know of an open-source equivalent for Ruby; FastAPI in Python is the closest I know of in any language. At Stainless, we're building a TypeScript version of this, but it's still deep in dogfooding.

Most people just end up maintaining by hand and using a tool like Optic or Akita to check that it's not wildly out-of-date.

Yeah, we opted for classes like this to ensure simple, reliable static typing.

The amount of runtime code generated per endpoint is typically around 3 short lines – here's an example, also posted elsewhere on this thread: https://github.com/lithic-com/lithic-node/blob/36d4a6a70597e...

We try to keep it to a minimum, especially in JS (though we have some nice improvements coming soon when we deprecate node-fetch in favor of built-in fetch). The package sizes aren't tiny because we include thorough types and sourcemaps, but the bundle sizes are fairly tidy.

Here's an example of a typical RESTful endpoint (Lithic's `client.cards.create()`:

https://github.com/lithic-com/lithic-node/blob/36d4a6a70597e...

Here are some example repos produced by Stainless:

1. https://github.com/openai/openai-node 2. https://github.com/openai/openai-python 3. https://github.com/cloudflare/cloudflare-go 4. https://github.com/Modern-Treasury/modern-treasury-java

buf.build : protobuf :: stainless : REST

(roughly)

oapi-codegen looks pretty cool (it seems I starred it some time ago) but for starters, it's Go only. Stainless does a bunch of languages with more on the way.

You can see an example of the Go code Stainless produces here: https://github.com/cloudflare/cloudflare-go

(I'm the Stainless founder)

ah, yeah their instagram integration is often pretty rough.

I'm a pretty avid Texts user, and I both agree and don't… as much as I ~regularly run into hiccups of some kind, I feel they're pretty inevitable with this sort of thing, and the parts of Texts that _could_ be stable definitely are. The overall product feels polished and snappy IMO.

Source? Or how do you know that?

Not for some time, unfortunately.