101–110 of 308 posts
Earlier quoted context omitted.
I think it would be difficult to compare at this point, as there aren't many details about Zero outside of the blog on their landing page. I believe it's very much in early (but active) development. From that blog: > We are working toward a source release in summer 2024 and an open beta EOY 2024.
Makes sense. FWIW, there are some more details here: https://replicache.notion.site/Introducing-Zero-8ce1b1f184aa...
Congrats to the Instant team. It’s a fantastic project. The DX is great and the engineering behind the datalog engine is really impressive.
Is the datalog engine exposed? Is there any way to cache parsed queries? Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this? Or is it on the roadmap? I have fairly large and overlapping rules/queries. Is there any way to store parsed queries and combine them? Also, why the same name as the (Lutris) Enhydra java database? Your domain is currently listed as…
We don't currently expose the datalog engine. You _technically_ could use it, but that part of the query system changes much more quickly.
Queries results are also cached by default on the client.
> Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this?
There's no shorthand for recursive queries yet, but it's on the roadmap. Today if you had a data model like 'blocks have child blocks', you wanted to get 3 levels deep, you could write:
```
useQuery({ blocks: { child: { child: {} } } });
```
> Also, why the same name as the (Lutris) Enhydra java database?
When we first thought of the idea for this project, our 'codename' was Instant. We didn't actually think we could get `instantdb.com` as a real domain name. But, after some sleuthing, we found that the email server for instantdb.com went to a gentleman in New Zealand. Seems like he nabbed it after Lutris shut down. We were about to buy the domain after.
> Given that it's implemented clojure and some other datalog engines are in clojure, can you say anything about antecedents?
Certainly. Datomic has had a huge influence on us. I first used it at a startup in 2014 (wit.ai) and enjoyed it.
Datalog and triples were critical for shipping Instant. The datalog syntax was simple enough that we could write a small query engine for the client. Triples were flexible enough to let us support relations. We wrote a bit about how helpful this was in this essay: https://www.instantdb.com/essays/next_firebase#another-appro...
We studied just about all the codebases you mentioned as we built Instant. Fun fact, datascript actually supports our in-memory cache on the server:
https://github.com/instantdb/instant/blob/main/server/src/in...
Is the datalog engine exposed? Is there any way to cache parsed queries? Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this? Or is it on the roadmap? I have fairly large and overlapping rules/queries. Is there any way to store parsed queries and combine them? Also, why the same name as the (Lutris) Enhydra java database? Your domain is currently listed as…
This is from me. I didn't realize the connection to Lutris + Enhydra. It should be listed as a "Acquired Company" + "Abandoned Project". Wikipedia also says that it lasted until 2001. Usage is different from development/maintenance. I will update the entry for the old InstantDB and add an entry for this new InstantDB. I think given that the original InstantDB died over two decades okay and is not widely known/remembe…
[Firebase founder] The thing I'm excited about w/Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story). Good luck, Joe, Stopa and team!
This is an aside but “trifecta but with four” actually has an awesome name: “Superfecta”!
How do I need to start thinking conceptually for this, InstantDB or Firebase concept to kick in?
Say for a collaborative text editor, I'd use off the shelf CRDT Javascript implementation.
Earlier quoted context omitted.
Absolutely. Instant has similar design goals to Rails and ActiveRecord Here are some parallels your example: A. ActiveRecord: ``` post = Post.find_by(author: "John Smith") post.author.email = "john@example.com" post.save ``` B. Instant: ``` db.transact( tx.users[lookup('author', 'John Smith')].update({ email: 'john@example.com' }), ); ``` > In React/Vue/Solid, I want to say express things like this: Here's what the R…
Maybe a dumb question, but why do I have to wrap in `db.transact` and `tx.*`? Why can't I just have a proxy object that handles that stuff under the hood? Naively, it seems more verbose than necessary. Also, I like that in Rails, there are ways to mutate just in memory, and then ways to push the change to DB. I can just assign, and then changes are only pushed when I call `save()`. Or if I want to do it all-in-one, I…
Writing a `user.save()` could be a good idea, but it opens up a question about how to do transactions. For example, saving _both_ user and post together).
I could see a variant where we return proxied objects from `useQuery`.
What would your ideal API look like?