For lots of constant persistent syncing (e.g. IndexedDB read / writes), might not be the best pick since the IndexedDB connection is sort of manual. Looks really neat for large in-memory queries and offers some unique compatibilities (supports Excel `.xls` and `.xlsx`), so might be a good pick for BI applications. Extensibility and portability seem to be the key here, which is evident in the number of adapters, plugins, and customization options. Seems like a very ambitious, but well thought out project, with good results. For some, this might not be enough and you might want to evaluate some of the alternatives with a larger feature set. LocalForage has been around for a long time, and is stable and well-liked, but it also remains focused on a simple localStorage like API. It comes with a large feature-set, beyond just the reactivity schema migrations, ORM capabilities, and field encryption are all features not present in PouchDB, but come out-of-the-box with RxDB. Since it is built on PouchDB, syntax is still NoSQL / documents. RxDB is built on top of PouchDB, and you can think of it as providing a reactive layer between your data and your UI, whereas normally you might need to manually code timed synchronization events. If you are not used to NoSQL / CouchDB, the syntax can be a little daunting. Also in active production use with some major players.ĬouchDB interoperability and sync features are the main selling points, but is also a very well thought out product, that is well-liked and maintained. Native Export / Import (aka dump imports)?Īlthough legacy support might not be as nice as localForage, and sync not as nice as PouchDB, overall has great performance and is well-liked. I’ve also copied and pasted the main table below: Library I’ve been using Google Sheets to record my findings – you can access it here (no login required). I was also interested in which libraries supported things like manual import / export shortcuts (so I don’t have to write a huge amount of code just so a user can download their own data), sync, NodeJS support, and legacy fallbacks. My research into the libraries supporting IndexedDB-backed local persistance and querying is the reason for this post. However, using IndexedDB is a little tricky (it is a low-level API) and most developers (including myself) are going to prefer a wrapper library around it, which will make writing code to use it easier. The explanation for why this is the superior option (over localStorage, cookies, etc.) is long and technical, so I’ll defer to the experts ( this is a good summary, from web.dev). In 2020, the best overall option for local data persistence is going to be the IndexedDB browser API. There is even a community around the topic. What if we are developing something that is meant to be used offline, after the initial page load? Is there a way we can persist and query user data locally, without ever needing a server?Īpps that are designed to be fully functional without an internet connection are often categorized as “ offline-first”. However, there is a gap left by all of the above approaches. These typically support an “offline” mode, but the main functionality is for sync / online operations. Managed database services (such as Google Firestore and AWS DynamoDB).Similar to AJAX database agnostic, requires active connection. Database agnostic the client-side code does not even necessarily know what type of DB is on the other end.This assumption means that the most common methods for storing and retrieving user data for the UI are things like: For most people building web applications, the general idea is that the user is connected to your service a fair amount of the time there might be periods of time where they go offline, but the goal is for a state of being “connected”.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |