Edge Conf: Front end data

Notes from the front end data panel at Edge Conf.

Until recently there weren't good APIs for dealing with front end data. For a new developer the choice can be overwhelming. Browser support is fragmented and different APIs store different types of data. Reading data from front end data is almost eerily fast. Because it's not using the network it also works offline. This used to be the domain of native apps - we can now do this with websites. devdocs.io is like dash but is a website - app cache and indexDB to download docs. With PouchDB you can store nearly a GB of data in any supported browser. The web can do apps now.

window.name, cookie, indexDB, localStorage, service worker, webSQL, browser cache, file system API, and more. Are there too many ways of storing data? We tend not to use multiple versions at once and most are going away as we move to service workers and indexDB. Libraries help. IndexDB seems to be the future friendly choice but libraries give you a unified API across browsers and storage methods.

Web dev is littered with the corpses of APIs that are standard but aren't used anymore. Why don't browsers add an API that is useable? IndexDB is a low level API which makes it hard to work with directly, it wasn't designed to be interacted with directly. All our tech stack is built on low level APIs - down to assembler - so don't worry about using a library. But we have to send them over the network if they're not built in to the browser.

Syncing logic is hard, can be easier to keep the data live. Can get into race conditions within the page, especially when we use workers. Don't write your own sync engine, there are way too many edge cases.

Browsers need to look at the APIs and listen to the community. Once there is consensus then it needs to be moved upon.

How trustworthy is putting data into the browser? Don't rely on it - replicate your data to the server. There is work starting on a more durable storage. Need to make it clear to the user. This is a UX issue, people are used to it in native apps but the UI in browsers is currently not obvious. Permissions and threshold warnings could make this easier. How do we deal with things that store a lot of data? Ask for permission + show notifications = communication. How is storage data different from history - maybe we need flags on the data to say whether it will have functional effects on apps or is just a cache.

There are different, correct and incompatible ways to do syncing. We don't want to enforce one - let the libraries take up the slack. This is still a fairly new problem. Sync API is transport neutral. Need to translate how the client and server think about data.

Security is an issue - if a site gets XSSed then it could have access to all the client side data. Probably get more data from the server so it will probably be a more attractive target (via XHR). Service workers are HTTPS only which should help, especially if this trend continues. HTTP header to clear all stored data for logout case could also be used to clear potentially compromised accounts.