131–140 of 308 posts
That strongly reminds me of Meteor. It's crazy to think how many modern problems were solved by design there years ago. I wish you the best of luck, having a real-time database on the client does make things much easier.
To be fair, maybe it was unrealistic to expect Meteor to do real-time communication for my game.
I've found triple stores to have pretty poor performance when most of your queries fetch full objects, or many fields of the same object, which in the real world seems to be very common. Postgres also isn't terrible, but also not brilliant for that use case. How has your experience been in that regard?
It’s not quite the same thing but nearby: I built a EAV secondary index system on top of Postgres to accelerate Notion’s user-defined-schema “Databases” feature about a year ago. By secondary index, I mean the EAV table was used for queries that returned IDs, and we hydrated the full objects from another store. We’d heard that “EAV in Postgres is bad” but wanted to find out for ourselves. Our strategy was to push the…
Long long time ago, I found that quite helpful with MySQL.
I know it's "just a paycheck," but I despise both of these companies, so I'll probably pass on this.
The usage of "schlep" so freely is also a bit unsettling.
Good luck!
Earlier quoted context omitted.
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…
This is a great question. We are working on a more concise transaction API, and are still in the design phase. 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?
He gave an example in the first post in this chain xD
I've found triple stores to have pretty poor performance when most of your queries fetch full objects, or many fields of the same object, which in the real world seems to be very common. Postgres also isn't terrible, but also not brilliant for that use case. How has your experience been in that regard?
So far we haven't hit intractable problems with query performance. One approach that we could evolving too down the road is similar to Tao [1]. In Tao, there are two tables: objects and references. This has scaled well for Facebook. We're also working on an individual Postgres adapter. This would replace the underlying triple store with a fully relational Postgres database. [1] https://www.usenix.org/system/files/con…
That's a rather tremendous oversimplification, unless something major changed in recent years. When I worked on database infra at FB, MySQL-backed TAO objects and associations were mapped to distinct underlying tables for each major type of entity or relationship. In other words, each UDB shard had hundreds of tables. Also each MySQL instance had a bunch (few dozen?) of shards, and each physical host had multiple MySQL instances. So the end result of that is that each individual table was kept to a quite reasonable size.
Nor was it an EAV / KV pattern at all, since each row represented a full object or association, rather than just a single attribute. And the read workload for associations typically consisted of range scans across an index, which isn't really a thing with EAV.
Earlier quoted context omitted.
It’s not quite the same thing but nearby: I built a EAV secondary index system on top of Postgres to accelerate Notion’s user-defined-schema “Databases” feature about a year ago. By secondary index, I mean the EAV table was used for queries that returned IDs, and we hydrated the full objects from another store. We’d heard that “EAV in Postgres is bad” but wanted to find out for ourselves. Our strategy was to push the…
Does postgres not have the ability to hint or force indexes? Long long time ago, I found that quite helpful with MySQL.
For example, creating a user table and ensuring that emails are unique - I've done it 50 times with Postgres. Is that part built out yet?
Very cool. Appreciate the "Don't Make Me Think" API.
(written with aqua)
I read the whole thing but I fail to understand how does this help or fit into picture of CRUD app. Most app I interact and work for a living are essentially a CRUD, SQL Server and a DOA layer by Spring. 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.
Imagine a you want to create a 'todo' list. If you used classic Rails, you'd be very productive. You could write most of your code on the server, and sprinkle some erb templates. However, if you want to improve the UX, you generally end up writing more Javascript. Once you do that, things get hairier: You create REST endpoints, funnel data into stores, normalize them, and denormalize them. Then you write optimistic u…
I've been planning to move to indexedDb using dexie for kinda the same use case of easier transaction, not maintaining a huge redux state (16k lines or so), and improved performance.
Now if my app is not supposed to be backed by a online database (single player only, complete offline), would instant make sense for this?
or would indexedDB be the safer choice?
One bit of feedback: Its always appreciated when code examples on websites are complete. Your example isn't complete -- where's the `transact` import coming from, or `useQuery`? Little minor details that go far as your product scales out to a wider user base.
I updated the example to include the imports:
```
import { init, tx, id } from "@instantdb/react";
const db = init({ appId: process.env.NEXT_PUBLIC_APP_ID, });
function Chat() {
// 1. Read
const { isLoading, error, data } = db.useQuery({
messages: {},
});
// 2. Write
const addMessage = (message) => {
db.transact(tx.messages[id()].update(message));
};
// 3. Render!
return ;```
What do you think?
One bit of feedback: Its always appreciated when code examples on websites are complete. Your example isn't complete -- where's the `transact` import coming from, or `useQuery`? Little minor details that go far as your product scales out to a wider user base.