This looks like interesting technology! Congrats on the launch, it's great to have people exploring the space of realtime data storage & sync. Some thoughts, that I hope you can find constructive.
The landing page draws comparison to Figma, Linear and Notion. But they are vastly different use cases.
Figma is document-centric, which means that:
- All data is tied to a single document, limiting their size.
- Requires that single backend session holds a document in-memory and deals with split-brain issues.
- Operational complexity arises around deployment.
- User interactions are often continuous (one event / frame), imposing tighter latency requirements.
- Generally requires that the document stays loaded in a memory in a stateful backend session.
- Technologies like Jamsocket are targeting such use cases.
Notion & Linear, on the other hand, have collaborative editing but not to the same degree of realtimeness.
- Data is not tied to a single document.
- Data can grow unbounded.
- Data is typically more relational.
Presenting both these uses cases adds confusion. By using SQLite (emphasis: database and "SQL"), it makes the technology appear at first glance more suited for the Linear/Notion use case. However, the opposite appears to be true after reading https://docs.livestore.dev/evaluation/when-livestore/.
- "All the client app data should fit into a in-memory SQLite database".
- "Reasons when not to use LiveStore" -> "Your app data is highly connected across users".
The Figma-like document use case does seem like something that LiveStore could support. When it comes to designing a data model for collaborative apps (CRDT or CRDT-like), the most simple and flexible solution is to store every object as a map of [Object ID] -> [Property Name] -> [Property Value]. Assuming that the properties names & values come from a fixed set and are typed (this will generally be true unless you allow for arbitrary user-defined fields), that looks like a database row! So why not just store it in a database, indeed.
However, among databases, there are object stores and relational databases. The latter is useful, as applications often want to represent relationships between different objects. But if we support multiplayer-like use cases which implies the absence of server-side transactions, how should conflicting events involving the creation/deletion/relationships between objects be handled? Is it entirely on the application to think about it? This is an interesting topic that I believe LiveStore seems well-positioned to innovate in.
I also find the "local-first" emphasis to be at odds with all of Figma/Notion/Linear. Local-first software tends to have a limited number of concurrent users accessing the data in-mind. SaaS applications that are truly targeted at collaboration tend to have a lot of different requirements. On the other hand, those applications do tend to have relatively limited offline support, which a local-first application tends to emphasize more.
The Figma-like use cases also has additional requirements. But I understand this is beta and look forward to seeing further development!
The landing page draws comparison to Figma, Linear and Notion. But they are vastly different use cases.
Figma is document-centric, which means that:
- All data is tied to a single document, limiting their size.
- Requires that single backend session holds a document in-memory and deals with split-brain issues.
- Operational complexity arises around deployment.
- User interactions are often continuous (one event / frame), imposing tighter latency requirements.
- Generally requires that the document stays loaded in a memory in a stateful backend session.
- Technologies like Jamsocket are targeting such use cases.
Notion & Linear, on the other hand, have collaborative editing but not to the same degree of realtimeness. - Data is not tied to a single document.
- Data can grow unbounded.
- Data is typically more relational.
Presenting both these uses cases adds confusion. By using SQLite (emphasis: database and "SQL"), it makes the technology appear at first glance more suited for the Linear/Notion use case. However, the opposite appears to be true after reading https://docs.livestore.dev/evaluation/when-livestore/.
- "All the client app data should fit into a in-memory SQLite database".
- "Reasons when not to use LiveStore" -> "Your app data is highly connected across users".
The Figma-like document use case does seem like something that LiveStore could support. When it comes to designing a data model for collaborative apps (CRDT or CRDT-like), the most simple and flexible solution is to store every object as a map of [Object ID] -> [Property Name] -> [Property Value]. Assuming that the properties names & values come from a fixed set and are typed (this will generally be true unless you allow for arbitrary user-defined fields), that looks like a database row! So why not just store it in a database, indeed.
However, among databases, there are object stores and relational databases. The latter is useful, as applications often want to represent relationships between different objects. But if we support multiplayer-like use cases which implies the absence of server-side transactions, how should conflicting events involving the creation/deletion/relationships between objects be handled? Is it entirely on the application to think about it? This is an interesting topic that I believe LiveStore seems well-positioned to innovate in.
I also find the "local-first" emphasis to be at odds with all of Figma/Notion/Linear. Local-first software tends to have a limited number of concurrent users accessing the data in-mind. SaaS applications that are truly targeted at collaboration tend to have a lot of different requirements. On the other hand, those applications do tend to have relatively limited offline support, which a local-first application tends to emphasize more.
The Figma-like use cases also has additional requirements. But I understand this is beta and look forward to seeing further development!