Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A New Architecture for Plaid Link: Server-Driven UI with Directed Graphs

plaid.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: A New Architecture for Plaid Link: Server-Driven UI with Directed Graphs

#21

Post by jeandenis »

TruthWillHurt wrote: post #18
smallnamespace wrote: post #7

Earlier quoted context omitted.

Our team will be gearing up for this soon, any additional details you can share?

Basically you need to fill out an exhausting 8 part form drilling down on every aspect of your business - Security - policies, architecture, breach procedures, external review, GDPR compliance, hosting structure, cryptography. Compliance - proove registration with different compliance bodies, proof of insurance (professional indemnity AND cyber), AML measures, KYC measures, proof of purchase of monitoring systems.. I…

Hi TruthWillHurt, are you in the UK? Looking at that list, that looks like what's required for a UK developer -- the environment in the UK is very regulated and quite different than the U.S.

Re: A New Architecture for Plaid Link: Server-Driven UI with Directed Graphs

#22

Post by xref »

Will this new architecture make it so sharing banking login credentials with Plaid is unnecessary? Similarly, will it change how much data Plaid scrapes from those bank accounts and shares with “partners” as described in the privacy policy?

https://plaid.com/legal/

https://security.stackexchange.com/questions/198005/is-plaid...

Re: A New Architecture for Plaid Link: Server-Driven UI with Directed Graphs

#24

Post by wkiefer »

gbrayut wrote: post #23

Curious how this compares with something like Apache Airflow? https://airflow.apache.org/docs/apache-airflow/stable/concep...

Airflow is an acyclic graph, but our user experience graphs have cycles (intentionally).

Airflow also focuses a bit more on being a multi-process data pipeline with workers rather than a way to drive user experiences with rendering, localization, user interaction, etc.

Re: A New Architecture for Plaid Link: Server-Driven UI with Directed Graphs

#26

Post by wkiefer »

davidkpiano wrote: post #25
wkiefer wrote: post #2

Hi folks — author/engineer here. Happy to answer any questions about this system!

Is the fact that this is technically a "state machine" intentionally left out? What are the differences, if any?

Good question — leaving out comparison with a traditional state machine wasn't intentional so I'm glad you asked.

A state machine will typically fully describe all the state at any given node in it. i.e. there's no additional state or context not represented by the state machine itself.

In our case, we have (1) the directed graph and (2) the session state. These two are related but don't have a direct correlation. The session state accrues new values as the graph is walked. As an example, theoretically the user could walk through a graph that has a cycle and get back to an earlier node but the session state would be different. In that case the same node would be "current" but there would be a different session state the second time it was visited.

Re: A New Architecture for Plaid Link: Server-Driven UI with Directed Graphs

#27

Post by wkiefer »

MrSaints wrote: post #17
wkiefer wrote: post #2

Hi folks — author/engineer here. Happy to answer any questions about this system!

Is my understanding correct in that a "Pane" is essentially a UI component? And I am assuming there are tests to catch cases where a new pane is defined in the backend, but not in the SDK (or I suppose, how do you deal with any discrepancy)? Do you lazy-load the components?

> Is my understanding correct in that a "Pane" is essentially a UI component?

Yes — it is essentially a UI component (and the only node that represents UI).

> And I am assuming there are tests to catch cases where a new pane is defined in the backend, but not in the SDK (or I suppose, how do you deal with any discrepancy)?

Great question! Because we use proto, the SDK and the backend share the same pane definitions. So we can't have a case where they don't match in the repo. However, SDKs that have already shipped obviously can't be updated with new panes. To handle this, we have a piece of the backend service called the "dispatcher" whose job it is to look at the initial /start request and determine which workflow should be used for that specific client.

Let's say a very old Android SDK is issuing a /start request. The dispatcher knows the version of the SDK requesting a workflow and programmatically can determine which major version of workflow graphs it supports, and pick an appropriate (older) workflow to send back where we know all panes are supported by the SDK.

We also have an escape hatch where the backend can tell an older SDK "actually, you're so old you should fallback on a webview implementation to get the latest and greatest experience".

Post reply on HN