simplesager

Thanks for the mention! We do move fast and to help manage the changes better we've introduced a number of change management concepts recently like breaking change detection and more controls around semver. The updates can also be stacked by the user into PRs and versions updated and published in one go. Definitely choices that we can guide you through

On the Speakeasy branded classes. We got rid of that some time ago based on customer feedback. Check out our new TS generator https://www.speakeasyapi.dev/post/how-we-built-universal-ts

Congratulations to the Stainless team on a fantastic launch! I'm one of the co founders of Speakeasy (https://www.speakeasyapi.dev/). We do similar things in the SDK space and some other things too.

I resonate with a lot of what is said in the comments. Last mile API tooling is underrated and most companies don't have the deep API platform expertise to build from scratch. The OSS options in the space proved SDK generation could be done but the actual product that you got in hand still needed a lot of work to be enterprise ready. The code was poor quality, wasn't customisable and there was no change management story. We're seeing a new wave of work in this space that's making api platform engineering much more accessible.

The API devex story starts with SDK creation and maintenance but there is a lot more to come!

Speakeasy (https://www.speakeasyapi.dev/) | Product Engineers (Full Stack), Founding Designer, Developer Advocate | US (SF), London (UK) | Full Time (Open to Remote, with willingness to travel a few times per quarter)

Hey there ! I'm Sagar, one of the co-founders at Speakeasy. We build tools to enhance the API developer experience. This primarily includes production-quality automatically-generated interfaces for companies' APIs such as SDKs and Terraform providers. Our mission is to assist teams in distributing their APIs to developers while handling the complex aspects.

We're a small, highly autonomous team looking for contributors to drive major projects from inception through delivery and iteration, working closely with our customers and community. If you're interested in developer-focused UX building with code generation, linters, parsers, LLMs you might find our work engaging. Although our primary languages are TypeScript and GoLang, our code gen product spans across more than eight languages — we're truly polyglots! As we scale rapidly alongside our customers, we're eager for individuals excited about delivering products that could impact millions of developers. Learn more about our "why" here: https://www.speakeasyapi.dev/docs/introduction/api-devex

Apply here https://jobs.ashbyhq.com/Speakeasy or email me at [email protected]

Completely agree. Keeping the openapi spec as tightly coupled to types in code builds a single source truth from your development to your deployment

Speakeasy (https://www.speakeasyapi.dev/) | Senior Product Engineers (Fullstack) | US (SF), London (UK) | Full time . (Will consider Remote too if you are open to travel a couple times a quarter).

About us: Hey there ! I'm one of the co founders of Speakeasy. We're building out a complete toolchain for API developer experience starting with production quality interfaces for company's APIs like SDKs, terraform providers and other novel generation targets. We help teams distribute their API to developers and deal with all the tough bits of scaling API usage.

You'll own, drive on major projects from inception to delivery and iteration with with our customers and community. You'll enjoy working on the stack if you're interested in codegen, linters, parsers, llms and developer focused UX. Our primary languages are Typescript and Golang but being a codegen product we work across 8+ languages, we're polyglots! We're scaling quickly with customers and looking for folks who are excited by the idea of shipping products that can touch millions of devs. More on the "why" here: https://www.speakeasyapi.dev/docs/intro

We're a small but tight knit team that iterates rapidly on product and has high autonomy to drive the business forward.

Apply here https://jobs.ashbyhq.com/Speakeasy or email me at [email protected]

Its a spicy time in IAC. Here is quick guide on how to leverage your existing terraform provider to unlock the Pulumi ecosystem using the Terraform Bridge.

I'm working on a company https://speakeasyapi.dev/ with the goal helping companies in this ecosystem get great production quality client sdks, terraform providers, cli(s) and all the developer surfaces you may want supported for our API. We also manage the spec and publishing workflow for you so all you have to do is build your API and we'll do the rest.

Feel free to email me at [email protected] or join our slack (https://join.slack.com/t/speakeasy-dev/shared_invite/zt-1cwb...) . We're in open beta and working with a few great companies already and we'd be happy for you to try out the platform for free!

Thanks ! let us know if you'd want to try it out, happy to give you early access or generate a few SDKs for you.

Disclosure: I'm a cofounder of this startup

We've been building client sdks as a service at Speakeasy (https://www.speakeasyapi.dev/). API developer experience today in REST struggles because the openapi generators are buggy and generate machine-readable stubs rather than ergonomic SDKs. We ended up building a new generator from ground up focused on ensuring we could capture idiomatic features specific to each languages. For API consumers our goal is to provide a best in class dev ex and taking the burden off of having to rewrite common boilerplate like pagination and retries. For API producers you get to focus on building your API and not have to worry about table stakes features for your users. We started a closed beta programme recently. Shoot me a message at [email protected] or come chat with us on slack if you want to early access!

https://join.slack.com/t/speakeasy-dev/shared_invite/zt-1df0...

We're building a product to tackle the time to value problem for API integration at Speakeasy (speakeasyapi.dev) . This is the onboarding problem you described but specifically for APIs which have a whole set of special needs and table stakes like dev portals with request logs, client sdks, usage limits, key rotation etc. Lots of companies building partner and public APIs often spend weeks if not months getting new partners to make a successful API call and move the integration into production. We've seen that only the biggest API as product companies have the time to invest in this internally by building out API platform teams. You still need a lot of this dev ex even if you a smaller company so usage of your API grows quickly. If what you are doing is API centric shoot me a note and happy to have you test out the product or just jam on ideas :)

Thanks tyho - let us know if you have any feedback !

Come join us on Slack if you have any questions on using the SDKs ! https://join.slack.com/t/speakeasy-dev/shared_invite/zt-1df0...

Client SDKs are a great way to provide a normalised and predictable experience for customers but we're also working on tools for API Producers to self service all parts of the API integration experience. Check out our website! https://www.speakeasyapi.dev/.

the web world is missing a nice IDL - OpenAPI is honestly way too much !

very cool - reminds me we should build a vscode plugin :D

i see you went the way of having a basic IDL ? looks nice and succint like protobuff

Yeah Nswag is great, but pretty specific to the .NET ecosystem if i understand correctly ? Ideally we'd like this to become a universal generator where any dev/team/company publishing an API gets typed and idiomatic clients, including the long tail of languages.

very cool ! So Samen is a way to manage types across frontend and backends?

Yeah totally agree - unfortunate that OpenAPI so much flexibility that there are multiple ways to define the same operations. For api users having the concrete types just means faster integration, no ambiguity on what is/is not supported.

Thanks !

thanks ! what languages do you use ?

yeah i was always annoyed how machine like the stubs that it generated are. I did here that they invested on making the go SDK more idiomatic. We've been exploring using templating or taking this approach of writing the generators from scratch in the native language.

We used a forked version of https://github.com/readmeio/oas to help dereference `$ref` statements, but other than that this is entirely hand-written: The Typescript `factory` AST API + `prettier` for formatting.

Would love to know more about this , how do you plan on using it ?

Great blog post :) How would i sign up as a user - are you considering having a dev portal?

Speakeasy, Zero Ops APIs | US, US Remote, London | Full-time | Dev Experience / API infrastructure

Speakeasy takes the heavy lifting out of operationalising an API. It does this orchestrating all the associated concerns necessary to launch or maintain a great API straight from your code – just hit git push and we'll take care of syncing changes to your customer facing artifacts and your infrastructure.

Come join a developer focused startup on day 0 and help build the next generation of API infrastructure. We are hiring founding team members who want to end to end ownership(SF, US Remote, London)

Founding engineer:https://jobs.lever.co/speakeasyapi/2a32b209-d562-4b43-a5f5-7... Founding fullstack engineer: https://jobs.lever.co/speakeasyapi/9c6e3f29-298b-4707-a748-3... Founding UX Lead: https://jobs.lever.co/speakeasyapi/a1eab675-eee3-45ea-af09-2...