Show HN: Doculite – Use SQLite as a Document Database

I&#x27;m the core maintainer of the npm sqlite package that your library uses. I recommend that you don&#x27;t make it a direct dependency, but use dependency injection or an adapter pattern that way your library isn&#x27;t dependent on a specific package version of sqlite&#x2F;sqlite3 (the npm sqlite package API is pretty static at this point though!).<p>The npm sqlite package used to have sqlite3 as a direct dependency in older major versions and most of the support issues were against sqlite3 instead of sqlite. Taking that dependency out and having the user inject it into sqlite instead removed 99% of the support issues. It&#x27;s also really nice that sqlite has no dependencies at all.<p>If you go the adapter pattern route, you can support other sqlite libraries like better-sqlite3. Sometimes sqlite&#x2F;sqlite3 doesn&#x27;t fit a user&#x27;s use-case and alternative libraries do.<p>Same deal with the pub&#x2F;sub mechanism. You have the Typescript types defined to create abstractions. Would be nice to see adapters for Redis streams &#x2F; kafka &#x2F; etc, as in-memory pub&#x2F;sub may not cut it after a certain point.<p>Great start on your library!

The one feature that I&#x27;d want out of this is atomic writes. If I have a document and want to increment the value of a field in it by one, I&#x27;m not sure that&#x27;s possible with Doculite today: if two requests read the same document at the same time and both write an incremented value, the value is incremented by one, not two.<p>The way _I_ would expect to do this is something like this:<p><pre><code> const ref = db.collection(&#x27;page&#x27;).doc(&#x27;foo&#x27;); do { const current = await ref.get(); try { await ref.set({ likes: current.likes + 1 }, { when: { likes: current.likes } }); } catch { continue; } } while (false); </code></pre> If `set()` attempts to write to the ref when the conditions in `when` are not matched exactly, the write should fail and you should have to try the operation again. In this example, the `set()` call increments the like value by one, but specifies that the write is only valid if `likes` is equal to the value that the client read. In the scenario I provided, one of the two concurrent requests would fail and retry the write (and succeed on the second go).

Why do you have async reads and writes? There&#x27;s no client-server setup here, using async &#x2F; await just introduces pointless waiting.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;WiseLibs&#x2F;better-sqlite3">https:&#x2F;&#x2F;github.com&#x2F;WiseLibs&#x2F;better-sqlite3</a>

Kind of nifty... Just curious if this is using the JSON functions&#x2F;operators for SQLite under the covers?<p><a href="https:&#x2F;&#x2F;www.sqlite.org&#x2F;json1.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.sqlite.org&#x2F;json1.html</a><p>Edit: where is the database file stored? A parameter for the Database() constructor seems obvious, but not seeing it in the basic sample.

&gt;DocuLite lets you use SQLite like Firebase Firestore.<p>Honestly, that sounds absolutely frightening to my ear. There are redis, there is mongo, orient, and plenty of document-based rapid-development databases which will be a substantially better solution than turning sqlite into Firebase.<p>Yes, you can use data change notification callbacks. It is a cool feature of SQLite, but did you know that their performance is a big concern in a large-scale database (document database grows very quickly by design)? What about COUNTs? Batching operations? Deadlocks? This will go out of hand quickly, because a hammer is used as a shovel here.

If you are serious about transactionality, data consistency, and isolation levels, this sounds different from how you want to go. Both Firestore and Realm have shortcomings here. Fauna (where I work at, btw) and Surreal with FoundationDB on the backend, and Spanner are the only ones that can guarantee strict serializability in a distributed environment. I could argue that Fauna is the most turnkey (least pain to try, test, implement). With those &quot;strict serializable&quot; db&#x27;s it is much easier to avoid data anomalies, as the ones mentioned in this thread.

I forgot to share this very cool alternative approach to realtime reactivity, via websockets, by subscribing to actual raw queries from the frontend!<p>- <a href="https:&#x2F;&#x2F;github.com&#x2F;Rolands-Laucis&#x2F;Socio">https:&#x2F;&#x2F;github.com&#x2F;Rolands-Laucis&#x2F;Socio</a><p>- <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=5MxAg-h38VA&amp;list=PLuzV40bvrSqhXZF6HtB1u0nR_lw2Rn-e6&amp;index=1">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=5MxAg-h38VA&amp;list=PLuzV40bvrS...</a> (video updates of the code and functionality)

I&#x27;d see if you can easily port the on top of browser based sqlite in wasm, that&#x27;s expand your user base and lead to some of the &quot;holy Grail&quot; in the offline first&#x2F;sync systems

This is cool. There are a tonne of options for local KV stores that likely outperform this by a large margin, but the obvious benefit here is that SQLite is really simple to configure and operate!

Here&#x27;s the source: <a href="https:&#x2F;&#x2F;github.com&#x2F;thenorthbay&#x2F;doculite">https:&#x2F;&#x2F;github.com&#x2F;thenorthbay&#x2F;doculite</a>

That is an interesting approach.<p>&gt; 6) SQLite is a proven, stable, and well-liked standard.<p>How does adding this adapter on top affect the stability?<p>Have you looked at SurrealDB? - <a href="https:&#x2F;&#x2F;surrealdb.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;surrealdb.com&#x2F;</a><p>Seems like it would provide you with what you need.

&gt; Alternative, proven Document Databases only offered client&#x2F;server support.<p>We currently use Realm for this use case. It’s a local database just like SQLite, but with native support for documents and listeners. Did you try that out?

Thank you, this can be handy really. I would love to have compatible replicas (implementing both the same API and the same storage schema) for other languages like C# and Python.

Does this mean documents in a database, or a database as a document?<p>I&#x27;ve tried the second, but the time comes when you need to (re)order items which gets clumsy.

&gt; Listeners and real-time updates enhance UX greatly.<p>how is this implemented?

I read point 1 as <i>against</i> using SQLite at first. :-D