* 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.

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.

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.

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!

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

- Google Meet (~Zoom)

- Google Chat (~Slack)

- Google Currents (~Yammer)

For consumers:

- Google Duo (~Facetime, but cross-platform)

- Google Messages (~iMessage, but non proprietary: SMS, MMS > RCS)

Everything else is on the retirement schedule.

The scenario is typically the following. After the EU Commission approves the directive, each country has to transform it into the national law and define the authority/approach/timelines. In the case of the UK, it's indeed the way you've described.

> As AFAICT this would be explicitly disallowed unless all the users of said APIs are themselves accredited.

In UK Plaid would have to follow the OpenBanking regulation indeed and provide access according to the consent of the account owner. In the US they are just storing your password and using it according to their privacy policy.

1) Regulation. What you heard as "PSD2" - is essentially a directive by European Commission and EBA demanding banks to open up access to accounts data and payment initiation. Neither it defines by what means this access should be provided, nor when it should be available - each European country Central Bank can decide on its own.

2) Technical Specification. Examples are OpenBanking UK specification or The Berlin Group - would be groups of banks or local regulators trying to define common standards. Think of interface definition that describes both APIs as well as journeys/workflows.

3) Compliance. In the EU some of the banks (mostly large ones) are now required to be PSD2 compliant, which means they would need to expose their APIs through the standards described above. In the US, where there is no such requirement - the only way to access the bank account is to emulate a browser.

4) Third-Party Providers or Aggregators (Plaid, Teller, Tink, SaltEdge, Bud...) - would essentially provide access to the accounts of multiple banks via APIs. If you look at Plaid in the US - their codebase is probably 50%+ screenscraping/user emulation scripts in order to retrieve your accounts from e.g. Bank of America. For the EU fin-techs its a bit better, but still depends per country (remember Berlin Group vs UK OpenBanking?).

We are currently looking on what to do with our quite massive GWT app. Already in the process of RPC to REST switch, with Angular, AngularDart and GWT3 (depending what it would end up to be) as options.

Just wanted to check if we are missing an alternative

I work at Mambu and our clients are predominantly Startups - https://www.mambu.com/clients Feel free to drop me an email at alexey.lapusta@mambu.com

Although we do not provide payment services to businesses, rather a SaaS platform for Financial Institutions (e.g. WireCard may use Mambu as their Core Banking when providing banking services to their customers).

https://careers.google.com/stories/google-sales-engineering-...

https://www.facebook.com/careers/life/solutions-engineering-...

https://builttoadapt.io/a-day-in-the-life-of-a-pivotal-platf...

Pros:

+ A lot of customer interaction. Could help you boost communication, presentation and sales skills if you want to start consulting

+ Quite a dynamic role, your agenda is not planned for next weeks but gets filled pretty fast with RFPs, Workshops, Demos, Proof of Concepts, etc.

+ As you are working in between of Sales, Product and Support/Delivery teams - that gives you a good perspective to provide valuable feedback across the company

+ Travel (can get boring after couple years though, and check with your partner if he/she is ok with that)

Cons:

- Some organizations are doing (Enterprise) Sales in old school way, in that case, Sales may just dump on your work they don't want to do like filling RFPs (Excel file with 100+ line of questions) or doing standard demos

- Your technical skills may stagnate as you would be less hands-on, but that depends on the type of the product (e.g. SaaS vs SDKs, Platforms)

- In terms of career development, you actually would have to choose if you want to go back to tech focusing on Solutions Architecture, or to Sales/Management roles

Before agreeing to the role - discuss the actual responsibilities (and ask those to be put on the job description), as well as the percentage of travel.

Are you planning to go more native with something like Atom's Electron platform?

Location: Amsterdam(we do sponsor work VISA), London, NY/Atlanta - FULLTIME

* Want to work in an international company travelling over the globe & work with clients?

* Or you prefer creating a solid platform for millions customers in our R&D dept in Amsterdam?

* You are a skilled frontend(Javascript, AngularJS, ReactJS), backend(Java, Spring, REST, Camel) or mobile(iOS, Android) engineer?

* We do have UX/BA/QA/Manager/Cloud positions too!

Check out our jobs at http://www.backbase.com/about/careers#jobs or drop a mail to alexey@backbase.com

For developers I suggest to try some of plugins, which are listed on GitHub wiki in the binding section and also take a look at Knockout/Ember/Angular so at least you would know what other frameworks offer.

View part is too much DIY. Seriously, _.template is okay for views with no input and simple updates, but if you have heavy IO views become bloated. Check the wiki, there are 7 "yet another binding plugins". Make default one, and make it an option (view binding can be slow and not needed sometimes).

Another DIY are models relations & nesting. These two additions wouldn't be big for the core, but they could really improve the ecosystem. Now you have to take in mind those third-party plugins people are using for these covering basic gaps.