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!
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
Open Banking is a big buzzword at the moment. It is good to distinguish different aspects of it:
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?).
> would be groups of banks or local regulators trying to define common standards
Why 'would be' just out of interest?
AFAICT Open Banking is an organisation that has been given a mandate by the UK government, through the competition and marketing authority, and is funded by the nine largest retail banks. In the UK it is the defacto standard, and compliance of the CMA 9 is mandatory.
While there is so far no consistent standard across the EU, at least within the UK this one is set and pretty much non-negotiable.
(Disclaimer - I have consulted with Open Banking and continue to do so, but of course I do not speak on their behalf)
-- edit --
I'm particularly interested in this -
> Third-Party Providers or Aggregators (Plaid, Teller, Tink, SaltEdge, Bud...) - would essentially provide access to the accounts of multiple banks via APIs.
As AFAICT this would be explicitly disallowed unless all the users of said APIs are themselves accredited. You can't just get accredited for PSD2/OB API use, then expose that information to non-accredited entities. If this is what Plaid are doing then I wouldn't expect their accreditation to last all that long.
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.
I'm not sure they would be allowed to provide access to another party at all, if the other party wasn't accredited, regardless of consent.
I'm sure they've looked into this with their lawyers, but acting as an escape route for banking data to non-approved entities is not likely to be smiled upon.
They are allowed to provide access but with a few stipulations:
Firstly, the consumer must be aware that they are sharing their data via Plaid (i.e. Plaid can't hide behind the scenes).
Secondly, there are certain exceptions for needing to be regulated by the FCA - particularly if you don't show any data back to the user.
In practice, it makes sense to be regulated by the FCA regardless because asking to share bank information/transactions with Plaid can turn users off and you're limited with what you can do with that data without being regulated/authorised.
I find that surprising, given the lengths OB go to to ensure that only registered, accredited entities can participate in using their APIs. I'm not saying you're wrong, just that I find it surprising.
(Source, I consult with OB and have a hand in their PKI, I don't speak for them and I'm not part of or informed well about anything to do with the regulatory environment)
"In the US, where there is no such requirement - the only way to access the bank account is to emulate a browser."
Not entirely correct. In the US, JPMorganChase, Intuit, and others have adopted the OFX standard (consortium-based, which provides #2) as a more secure, controlled API alternative to browser emulation.
like any other entrenched monopolist, Plaid shouldn't want OFX to make it easier for new entrants to enter. Building something to interact with OFX is easier than building a scraper.
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).
Depends on the project. Google 'Apps' use J2CL for shared business logic between platforms, but the UI on each platform is handmade. For the Web, Soy templating is heavily used (known externally as Closure Templates IIRC), along with Closure library primitives. Style Sheets are written in Closure's style sheet syntax and compiled and optimized as well.
With the Elemental2 library and JsInterop this could easily be written in Java "to the metal" as well, but so much of existing Web code is already in Soy and JS, it makes more sense to reuse that.
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
+ 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.
We just push bug fixes now for the legacy app. The roadmap of legacy apps from Google is still not clear. I would strongly suggest the packaged app way for multiple reasons (folders, in-built documentation, syncing, real-time sharing, tests, request capture).
And yes, native apps are coming soon! Atom's Electron is a strong contender. We are exploring all possible options. :)
I don't see how that is addressing my point. Emacs Lisp is the scripting language of Emacs, and you can use it to build AST to deal with syntax highlighting and autocompletions amongst other. And that's what Nitra is intended for, and it doesn't matter that it is written in Nemerle.
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!