4 ms·

Author here. Finally got through most of the questions, will keep checking periodically for ones I've missed (has someone built a better way to track HN discuss

Author here. Finally got through most of the questions, will keep checking periodically for ones I've missed (has someone built a better way to track HN discussions?). I'm very happy to see the discussion thus far. This first post focused on the parts of frontend engineering that motivated me to create SQLSync rather than specifically how SQLSync works. I'll be addressing that in my next post. Thanks for all the great questions! Keep them coming :)

tegmarks 3y ago
Thankyou for the very informative article, I appreciate the irony using a post titled "Stop building databases" to announce a new database :-)
- carlsverre 3y ago
  You're welcome! And I'm glad you enjoyed it. Once I thought of that title I had to use it. My only saving grace is that technically I didn't make a new DB - just using good ol SQLite. Mostly. :)
  - dev-tacular 3y ago
    The title certain piqued my interest!
kaishin 3y ago
Any plans to support mobile? That’s where I’d consider using this most.
- carlsverre 3y ago
  Yes! I'm looking at how to evolve this into a native SQLite extension which would dramatically improve distribution.
  - onemiketwelve 3y ago
    Hey, finally got around to reading the article. I have been grappling with the convoluted, fucked up mess that is offline first over the last 6 months. I really truly thought that this was a solved problem which the likes of facebook, instagram, etc have solved a long time ago and that there was some open source version copying whatever underlying mechanism they created. As for the prior art, I was surprised you didn't mention watermelonDB. It sounds like what you are building but specifically for react native. I tried to use it but there were lots of really annoying api choices regarding how the querying works in the front end and their choices on how their ORM works. But the sync methodology they use seems to be sound, and as they say, they've thought long and hard about. https://watermelondb.dev/docs/Sync/Intro https://watermelondb.dev/docs/Sync/Intro The project as it is seems pretty low level. Are you planning on adding and ORM layer, or leave that up to someone else? The last question that I always have is, how would this project create a facebook app clone? IE the user will almost always have subsets of tables that are much much smaller than the full tables the the backend has. IE, a user should have various posts from the feed, and various users, photos, comments and liked tables downloaded for the next 30 minutes of offline activity lets say. In this system, it seems like we are syncing entire databases. But syncing small slivers of the entire system seems to be what a lot of your typical REST based apps do. Yet it is a problem I haven't been able to solve cleanly or with a unified plan of attack Thanks

tegmarks 3y ago

Thankyou for the very informative article, I appreciate the irony using a post titled "Stop building databases" to announce a new database :-)

carlsverre 3y ago
You're welcome! And I'm glad you enjoyed it. Once I thought of that title I had to use it. My only saving grace is that technically I didn't make a new DB - just using good ol SQLite. Mostly. :)
- dev-tacular 3y ago
  The title certain piqued my interest!

kaishin 3y ago

Any plans to support mobile? That’s where I’d consider using this most.

carlsverre 3y ago
Yes! I'm looking at how to evolve this into a native SQLite extension which would dramatically improve distribution.
- onemiketwelve 3y ago
  Hey, finally got around to reading the article. I have been grappling with the convoluted, fucked up mess that is offline first over the last 6 months. I really truly thought that this was a solved problem which the likes of facebook, instagram, etc have solved a long time ago and that there was some open source version copying whatever underlying mechanism they created. As for the prior art, I was surprised you didn't mention watermelonDB. It sounds like what you are building but specifically for react native. I tried to use it but there were lots of really annoying api choices regarding how the querying works in the front end and their choices on how their ORM works. But the sync methodology they use seems to be sound, and as they say, they've thought long and hard about. https://watermelondb.dev/docs/Sync/Intro https://watermelondb.dev/docs/Sync/Intro The project as it is seems pretty low level. Are you planning on adding and ORM layer, or leave that up to someone else? The last question that I always have is, how would this project create a facebook app clone? IE the user will almost always have subsets of tables that are much much smaller than the full tables the the backend has. IE, a user should have various posts from the feed, and various users, photos, comments and liked tables downloaded for the next 30 minutes of offline activity lets say. In this system, it seems like we are syncing entire databases. But syncing small slivers of the entire system seems to be what a lot of your typical REST based apps do. Yet it is a problem I haven't been able to solve cleanly or with a unified plan of attack Thanks