Re:Skip the API, Ship Your Database
by yyyk on Wednesday September 13, 2023 @11:38PM
(#37504700)
I have some experience with a comparable platform. In a typical CouchDB/PouchDB design, syncs are common and easy and it's pretty close to database-based design if you get fancy with views and javascript-based logic.
For this project, I'd do:
* A database for each user (this is natural on CouchDB, a setting one can enable to create the DB automatically. The platform won't choke on many databases) - for some per-user data, like comments, if the user has already reserved a booking we can mirror booking data there + some info regarding the hotel.
* Common synced databases - some general info regarding the platform and hotels. Preferably not too large (IIRC there's no limit to attachments with 3.x, but it sounds risky). Anything too large we'd do online or use data provided with the application.
* A large booking database which isn't synced and must be modified online with a REST call - we don't have to allow every action offline. This obviously needs the online component for making sure bookings don't conflict. Could even be a regular relational database. (Something like allowing a provisional offline reservation to the user database followed by a possible rejection on the server when syncing is doable, but I'm don't think there's much value to the user here).
It sounds very doable, rather similar to a project I was involved with, but I miss SQL a lot with that platform. A sqlite-based approach is an interesting alternative.
For this project, I'd do:
* A database for each user (this is natural on CouchDB, a setting one can enable to create the DB automatically. The platform won't choke on many databases) - for some per-user data, like comments, if the user has already reserved a booking we can mirror booking data there + some info regarding the hotel.
* Common synced databases - some general info regarding the platform and hotels. Preferably not too large (IIRC there's no limit to attachments with 3.x, but it sounds risky). Anything too large we'd do online or use data provided with the application.
* A large booking database which isn't synced and must be modified online with a REST call - we don't have to allow every action offline. This obviously needs the online component for making sure bookings don't conflict. Could even be a regular relational database. (Something like allowing a provisional offline reservation to the user database followed by a possible rejection on the server when syncing is doable, but I'm don't think there's much value to the user here).
It sounds very doable, rather similar to a project I was involved with, but I miss SQL a lot with that platform. A sqlite-based approach is an interesting alternative.