HackerTrans
TopNewTrendsCommentsPastAskShowJobs

lapusta

no profile record

comments

lapusta
·2 miesiące temu·discuss
Huh! I see stlc option is added now mentioning "eligible customers", which is great news. I'm curious if we would also get GitHub action?
lapusta
·2 miesiące temu·discuss
I don't think the generators themselves were open-sourced (only the generated SDKs were already open-source). That leaves three main (recommended) options:

* Manual Maintenance: Returning to the pre-Stainless era.

* Agentic Coding: Works to an extent, but you lose the deterministic, review-free output required to keep an SDK perfectly structured and coherent.

* Open-source Generators: Helpful for basic use cases, but they lack Stainless's full-stack features like multi-language generation and publishing, MCPs, and documentation.
lapusta
·12 miesięcy temu·discuss
Red Hat effectively killed their JBoss/Middleware team and the rest of it moved to IBM https://www.redhat.com/en/blog/evolving-our-middleware-strat... Quarkus and other tools were pushed to CommonHaus/Apache. I believe Vert.X was also mostly developer by RH team, although moved to Eclispe Foundation a decade ago.

Oracle also ended up somehow sponsoring 2 frameworks: Helidon & Micronaut.

I'd bet Spring is still the safest choice next to Jakarta EE standards that all are built on top of nowadays.
lapusta
·2 lata temu·discuss
I could really recommend Encore https://encore.dev/ that works best when you use their PaaS offering https://encore.cloud/ (think of NextJS & Vercel combo).

One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.

You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.
lapusta
·2 lata temu·discuss
We've recently evaluated all four platforms—Stainless, Fern, Speakeasy, and Liblab—and here are our key takeaways:

Stainless: The standout for maturity and idiomatic code generation. While method signatures across products may look the same, Stainless shines during developing & debugging - making their codebase easier to navigate. They have a practical separation of SDK configuration from OpenAPI specification, setting it apart from others reliant on OpenAPI overlays. The Stainless Studio also proved invaluable for refining our OpenAPI specs during our exploration phase.

Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs and documentation to Postman collections. Fern uses an internal "Fern Definition" language (~ think Smithy), it's optional and enables capabilities like merging multiple specs, but is adding another layer to navigate in our view.

Speakeasy: Moves at a fast pace, which could be a double-edged sword. Rapid iterations may lead to frequent, potentially disruptive updates for customers. A minor gripe was the inclusion of "Speakeasy" in class names, which felt overly branded.

Liblab: Initially limited in language support, they've expanded but still lag behind in establishing a strong customer base, which might be a red flag for some adopters.

BTW all folks are very approachable and collaborative!
lapusta
·2 lata temu·discuss
Many systems have concepts of booking date & value date https://support.mambu.com/docs/booking-date-vs-value-date

You may also have suspense accounts for certain types of use cases: https://gocardless.com/en-us/guides/posts/what-is-a-suspense...