10/13/2023 0 Comments Sqlite3 browser![]() ![]() That's how the web works and Web SQL could have worked that way too. Extension and versioning mechanisms can be made. APIs and languages can evolve, but in (mostly) backwards compatible ways. Developers use feature detection and and work to the lowest supported version. Why not? Web SQL would not be different from WebGL/GLSL or even JavaScript itself in that respect. There would have been no extension mechanism. > WebSQL would have been tied to one specific version of SQLite, and developers would have to work to the lowest supported version. Even for open-in-new-tab, because resources are cached and a dataset is in sync. An app like that shouldn’t even make requests, apart from downloading new jpegs and one narrow replication stream. a page where I buy t-shirts is barely a megabyte of json (sans images) for all items, but it spends probably half an hour in awaiting responses when I’m shopping around. Imagine adjusting a filter and not waiting for reload and rescroll in a “web 2.0” app, when an entire dataset is comparable to a and a roundtrip to it is 1000x+ slower than a query itself. Some e-stores and sites literally reach server on each tick on a sidebar, when it could be a fragmentarily replicated local database with a background periodic or live sync. ![]() #SQLITE3 BROWSER HOW TO#How… I mean this is so obvious to have a RDBMS local to any non-basic app, why are you even asking? No offense, I just don’t understand how to create webapps and be not bothered by a lack of fundamental things. Querying already cached data without reimplementing the query logic in javascript. batch-runner, however, is in no way user friendly. That tool is how we've benchmarked it so far, with the exception of comparing it to WebSQL, which required a custom application which is also in that directory (batch-runner.*). Edit: or (D): we have a WASM port of sqlite's standard benchmarking tool, known as "speedtest1", in the sqlite source tree, but getting it up and running requires reading a good deal of documentation: Until then, however, you'll simply have to (A) take my word for it, (B) try it out yourself, or (C) none of the above, as you wish. Once our documentation effort settles down, and responding to user feedback from the initial announcement slows down, i hope to implement a benchmarking application similar to: However, all such records were in transient spreadsheets intended for one-shot note-taking use, not publication. We've done a tremendous amount of benchmarking during the development because All The Speed was one of our design goals. You can't currently because we don't have them in a user-consumable form. We have an #antidote channel in the ElectricSQL discord if you’d be interested in chatting more. We are also taking advantage of some simplifications which mitigate the known issues. (Professor Annette Bieniusa, who leads the development, is our Chief Architect). We are working, alongside others, with the Antidote developers to help fix these issues and generally improve reliability / engineer correct behaviour under load. There are also other aspects on the Antidote roadmap such as efficiently materialising consistent secondary indexes that are ongoing challenges but aren’t so relevant to how we’re using it as a replication layer. It’s not production ready and neither are we (we’re in developer preview mode, which is like a public alpha ). However it has some known issues, such as behaviour under high load and not currently handling node failure within a DC. Yup, it’s a very rigorous system developed over ~10 years with solid testing, benchmarking and formal proofs. The SQLite Session Extension potentially has the building blocks needed for such a system. What I really want to see next is an eventually constant sync system between browser and server (or truly distributed with WebRTC). #SQLITE3 BROWSER OFFLINE#The concept of a single codebase web/mobile/desktop app with proper offline storage is here. WASM SQLite with the OPFS is the future of offline first web app development. The OPFS supersedes all that and makes it possible to have proper consistent and resilient transactions. #SQLITE3 BROWSER FULL#It provided full ACID compliment transactions. You may have seen “Absurd SQL” which was a proof of concept for building a SQLite Virtual FS backend using IndexedDB. This is really good news, and exactly what the OPFS was designed for. As of this writing, that includes the Origin-Private FileSystem (OPFS) ![]() … support persistent client-side storage using available JS APIs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |