![]() ![]() When designing Flex Link, our guiding principle was to reduce complexity, in particular, by leveraging strong boundaries. Fortunately, a singular guiding principle allowed the team to define these wide-ranging goals while sharing the same underlying solution. These goals directly addressed the problems exposed by a complex codebase and the difficulties faced when deploying native experiences across many platforms. Oh, and we didn’t want to adjust the surface area of our SDK at all, so that we could transparently shift to the new architecture without requiring any changes from our customers. Safer & More Reliable - deploying changes with higher confidence, easier testing, and better support for backwards compatibility. The overarching goal of this project is to provide a better product experience for our customers while increasing velocity for our internal teams.Įasier for customers - requiring fewer SDK updates to get the latest features.īetter for end users - providing best-in-class native experiences per platform with fast fixes and improvements.įaster for Plaid - providing a product platform to scale the company and its suite of products. Follow along and let us know what you think! Goals We’re going to dive into the problem, how we defined success and how we built Flexible Link (or “Flex Link” as we tend to call it □). The particular mechanism in which we married directed graphs with dynamic services is novel and unlocks myriad advantages around backwards compatibility, quality, testability, velocity, reuse, and experimentation.ĭubbed “Flexible Link”, the re-architecture set out to not only solve the existing scaling problems but to develop a product platform that would deliver years of diverse new product experiences for our customers. More importantly, we moved all user experience logic into a no-code directed graph data model and transformed the client-side SDK into a focused rendering engine. While there’s a number of ways¹ to mitigate these problems, we chose to rebuild the foundation behind the Plaid Link SDK by moving all logic to the backend so it could be shared across Web, iOS, and Android. As the number of features and fixes we deployed increased, this simple design became an impediment to velocity (code had to be changed on three different platforms), quality (client-server logic complexity was hard to test) and ease-of-integration (customers had to rebuild and resubmit mobile apps for each improvement). The original design of the Plaid Link SDK was straightforward: the SDK contained all the user interface (UI) and business logic for the user experience and called a handful of internal backend endpoints to fetch localized data, authenticate users, and ultimately return a public token for the customer application to use with the Plaid API. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |