I’ve got a reasonably complicated data model for my pseudo-social system, and I’d love to hear some thoughts about how I should structure the relationship between the actual database, the RESTful API, and ember-data stuff.
The core objects I’m dealing with are Users (easy), Sources (one example of which would be a blog), and Items (individual blog posts). Tangentially, it’s amazing how much can boil down to pub/sub/hub systems. Anyway.
The problem is that the Sources are shared across the entire userbase, and users show interest in a particular source. That’s easy - there’s a Subscription table, which is a junction table between Source and User, with a few extra columns (type of subscription and so on). There’s a similar mapping done on Item, so I can have shared Item data but also per-user item_status information (read/unread, flagged, etc)
The problem arises in how I choose to build the API and ember-data’s interface to it.
After mucking around with embedded objects, I ended up just writing some computed properties into the ActiveRecordSerializer for Subscription which transparently (to the API viewer) forward the relevant Source columns.
This isn’t entirely unreasonable, but as I build out the parallel interface for the Items, right before the weekend, I decided I should take a moment to think about whether this is Good or Bad. Figure it’s worth seeing if anyone else in Emberland has an opinion on this.
My options are basically:
- present the API faithfully to the database design, which makes things a bit more complicated on the Ember side, as all the information needed to display to a user is spread across two objects (typically, the actually-displayed data is in the “global” object, and the junction object represents filters and/or display settings such as starred or unread)
- present the API less-faithfully, with /api/subscription/2 actually returning a JSON object that includes what amounts to a join between two tables in the database.
Both are feasible, and it’s not like there will be multiple users interfacing with the same instance of the ember app on the same browser, so it’s not like I need to pool objects on that side the way I want to do on the database side.
Given my experience differential with databases/rails and ember, if I’m going to do something complicated at this point I’d rather do it on the serverside.
Thoughts? Ideas?
Thanks.