I'm currently building an app which uses Open Banking through Plaid. This is a React front-end app with serverless functions supporting a 'back-end'.
At the moment, on every page load, the user's access token is transferred through the Plaid API and the banking data is pulled. The user data is not persisted in any way, and is lost when the user leaves the page.
This unfortunately is quite a performance drain - it means every time the user navigates around the site that the API has to be called on every page load, even if the data has just loaded, and so it's causing a 3/4 second load on every page. Very slow.
I've noticed other 'banking' apps that hold data like this seem to persist it somehow. Whether this be data pulled via an API and then stored in an encrypted database, or perhaps pulled and stored in local storage, I'm not sure..
So my question is - broadly - what is the best way of me persisting user banking data pulled through an API?
Is it acceptable for me to store it in a database that's updated every time the user 'refreshes' the connection? Perhaps every few hours, or on clicking 'refresh'?
Or is there another, more suitable way of me doing this?
Hope this makes sense and is asked in the correct place.
So in general when calling an open banking API you don't want to call it from the client side -- both for performance reasons (as you've already run into) and for security reasons because you risk exposing your API secret. This article on the topic has some handy guidance: keeping credentials secure when making API calls with JavaScript.
We recommend securing the data encrypted and in a database rather than local storage. The Plaid docs also touch on this a little in the launch checklist.
The exact mechanics of refreshing data depend on which API you're using, but if it's something like Transactions, Plaid can send webhooks to alert you when there is new data available, so that you don't need to wait for interactive user input in order to refresh data.