3 ms·
Why not use SQLite directly instead of this extra layer?
by bufferoverflow 8y ago
Why not use SQLite directly instead of this extra layer?
- radex 8y agoSQLite gives you just the "data fetching" part. But if you're building a React/RN app, you probably also want everything to be automatically observable. For example, if you have a todo app, and you mark a task as done, you'd want the task component to re-render, the list to re-render (put the task at the bottom), and update the right counters (the counter of all tasks, and a counter of all tasks in ta project), etc. I hope you're getting the point. Watermelon is an observable abstraction on top of SQLite (or an arbitrary database), so that you can connect data to components and have them update automatically
- nepeckman 8y agoSo is it fair to say its a React specific ORM, that automatically makes the mapped objects observable (an OORM, if you will)? Just trying to understand the level of abstraction that you're going for.
- radex 8y agoThat's a fair description, yeah!
- amelius 8y agoDoes that mean that if user A makes an update to the database, then user B (on a different computer) will see the update?
- radex 8y agoNo, Watermelon is a local app database. But you can plug it into a sync engine to synchronize with the server (and then from the server to another device) — it's up to you
- jonnydubowsky 8y agoThanks for this concise example! This helped me to understand why I should try it out, and led me to demoing this myself. I'll report back my findings
- eyeos 8y agoBecause then you don’t get to reinvent the wheel.
- radex 8y agoIt's easy to be cynical on HN, but to the best of my knowledge, no other solution for React Native checks all the boxes we need. And it's not like reinventing the wheel (it still uses SQLite), more like inventing better suspenders for the whole undercarriage ;)
- cift 8y agoLooks like it's mostly to provide a lazy loading wrapper for SQLite to React
- tomhoward 8y agoBecause it's very cumbersome, interfacing between Javascript and SQLite, and mapping between database records and Javascript objects. And it doesn't easily fit with the React way of doing things without some library to abstract away all the wiring. I started building a hybrid mobile app (not React) with a large SQLite database about 4 years ago and have kept working on it ever since, and I've found the data storage aspect of the app very painful to maintain and extend. I'm now starting to rebuild it using React Native, and a storage plugin like this could be perfect. I'd been looking at Realm, but haven't gotten as far as committing to it yet, so I'll take a close look at WatermelonDB too.
- pknopf 8y agoI'm not buying the "too cumbersome to use SQLite" argument. This still seems like a large unnecessary abtraction.
- tomhoward 8y agoSincere question: do you much work in React/React Native with large SQLite databases or other large data stores? As the sibling (and better) comment[1] to my original comment points out, this library makes the data automatically observable throughout the React app, making it much simpler to update views in response to database changes. I can understand you might not understand the value of this if you hadn't done a lot of work with React apps that have large data sets and where data changes need to be reflected in multiple different views. [1] https://news.ycombinator.com/item?id=17958822 https://news.ycombinator.com/item?id=17958822
- anaganisk 8y agoWhy don't you try linking react with a large Sqlite, and later build a wrapper of your own, and then release it in HN next year as, pinappleDB?