Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Doculite – Use SQLite as a Document Database

npmjs.com

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Show HN: Doculite – Use SQLite as a Document Database

#31

Post by [deleted] »

zdragnar wrote: post #24
thenorthbay wrote: post #17

Earlier quoted context omitted.

If you use the library on a server in a node.js environment, wouldn't it be useful to fetch data (e.g. Remix / NextJS)? Besides, I'm not sure if better-sqlite3 offers the listener functionalities I care about. Skimming the docs, it seems it doesn't.

Listener functionality could be something you'd have to write yourself, I suppose. As for on the server, no. Sqlite is a c library, not a separate application- the work happens inside the node process. Regardless of how you do it, any call into sqlite is going to block. Adding promises or callbacks on top of that is just wasting CPU cycles, unlike reading from the filesystem or making a network request, where the wor…

[deleted]

Re: Show HN: Doculite – Use SQLite as a Document Database

#32

Post by [deleted] »

jitl wrote: post #23
thenorthbay wrote: post #17

Earlier quoted context omitted.

If you use the library on a server in a node.js environment, wouldn't it be useful to fetch data (e.g. Remix / NextJS)? Besides, I'm not sure if better-sqlite3 offers the listener functionalities I care about. Skimming the docs, it seems it doesn't.

better-sqlite3 is orders of magnitude faster than the async SQLite bindings. We found this to be true when testing SQLite options for Notion's desktop app anyways. The "why should I use this" bits sound boastful but are reasonable. https://github.com/WiseLibs/better-sqlite3#why-should-i-use-...

[deleted]

Re: Show HN: Doculite – Use SQLite as a Document Database

#33

Post by kstrauser »

plaguuuuuu wrote: post #20

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!

I wouldn’t count on it. SQLite is unreasonably fast in ways you’d think it shouldn’t be.

Re: Show HN: Doculite – Use SQLite as a Document Database

#34

Post by theogravity »

I'm the core maintainer of the npm sqlite package that your library uses. I recommend that you don't make it a direct dependency, but use dependency injection or an adapter pattern that way your library isn't dependent on a specific package version of sqlite/sqlite3 (the npm sqlite package API is pretty static at this point though!).

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's also really nice that sqlite has no dependencies at all.

If you go the adapter pattern route, you can support other sqlite libraries like better-sqlite3. Sometimes sqlite/sqlite3 doesn't fit a user's use-case and alternative libraries do.

Same deal with the pub/sub mechanism. You have the Typescript types defined to create abstractions. Would be nice to see adapters for Redis streams / kafka / etc, as in-memory pub/sub may not cut it after a certain point.

Great start on your library!

Re: Show HN: Doculite – Use SQLite as a Document Database

#35

Post by gerad »

bastawhiz wrote: post #16
thenorthbay wrote: post #8

Earlier quoted context omitted.

Interesting. Updating values via incrementing them is a use case I barely had in Firebase. I mostly only dealt with 1-time updates to values, e.g. by the user or scheduled jobs. In which scenario would the current design cause you problems?

Incrementing is only one possible use case. Any time you read data and then write back based on that data, you need to ensure that nobody wrote to the document in the interim. RDBMS do this with transactions. Consider the case where a user is submitting an e-commerce order. You want to mark their order as processed and submit it for fulfillment. If you read the order to check if it's already submitted, two requests t…

It’s possible to use optimistic locking and versioning to ensure that things haven’t changed underneath you unexpectedly.

Re: Show HN: Doculite – Use SQLite as a Document Database

#36

Post by skinkestek »

theogravity wrote: post #34

I'm the core maintainer of the npm sqlite package that your library uses. I recommend that you don't make it a direct dependency, but use dependency injection or an adapter pattern that way your library isn't dependent on a specific package version of sqlite/sqlite3 (the npm sqlite package API is pretty static at this point though!). The npm sqlite package used to have sqlite3 as a direct dependency in older major ve…

> I recommend that you don't make it a direct dependency, but use dependency injection or an adapter pattern that way your library isn't dependent on a specific package version of sqlite/sqlite3

Do you have examples of what you mean?

Do you just mean in the code or is this something about how it is imported as a dependency in package.json?

Re: Show HN: Doculite – Use SQLite as a Document Database

#37

Post by theogravity »

skinkestek wrote: post #36
theogravity wrote: post #34

I'm the core maintainer of the npm sqlite package that your library uses. I recommend that you don't make it a direct dependency, but use dependency injection or an adapter pattern that way your library isn't dependent on a specific package version of sqlite/sqlite3 (the npm sqlite package API is pretty static at this point though!). The npm sqlite package used to have sqlite3 as a direct dependency in older major ve…

> I recommend that you don't make it a direct dependency, but use dependency injection or an adapter pattern that way your library isn't dependent on a specific package version of sqlite/sqlite3 Do you have examples of what you mean? Do you just mean in the code or is this something about how it is imported as a dependency in package.json?

They would have to install sqlite and sqlite3 separately and feed the sqlite instance to your library when creating a new instance of your library. It would no longer be a dependency in package.json (maybe a devDependency when you write unit tests using it). Look at how the npm sqlite source code does it as an example.

https://github.com/kriasoft/node-sqlite

In the src/index.ts file, the `open()` function takes in an instance of sqlite3, vs the file importing it from the sqlite3 package itself.

An adapter / driver pattern would extend this where you can interchange usage of either the sqlite package or an alternative.

For example, let's say you have two SQLite drivers. They both allow you to execute a statement, but their methods and maybe parameters are named differently. One might expose a `exec()`, while the other exposes `run()` to do the same thing.

Your codebase probably is coded for one or the other, which means you can't freely interchange the drivers.

So what you do to support this is create a an interface with methods that describe what you want to do. In the above case, you might describe a method called `executeStatement()`.

Then you create two classes, one for each driver. They both implement `executeStatement()`, but under the hood, they'll run `exec()` and `run()` in their implementations.

So your main code now will accept an instance of anything that implements your interface, and instead of calling like `exec()`, you'll be calling `executeStatement()`, which under the hood calls `exec()`.

So it goes like this:

- Define common interface for interacting with different database libraries (the abstraction)

- Implementation class using that interface (the drivers)

- Your constructor takes in anything that conforms to that interface

- The user creates an instance of your implementation (eg SqliteDriver) and feeds in the instance of the driver (eg `new SqliteDriver()`

- Your code calls the interface methods in place of the actual database calls instead

You had something like:

  db.collection('users').set(..)
So rather than calling SQLite `run()`, it'd be calling your interface method `executeStatment()` (which calls `run()`) instead in that `set()` call.

It looks like the "Bridge" pattern is what you want here:

https://www.phind.com/agent?cache=cll1zw1n60010la08mn89dd8g

The generated code is Java, but the idea and concept is the exact same that I've described above.

Post reply on HN