I should say that I have written up chunks of this on my own as well. I’m using the current Crossbar database integration with PostgreSQL triggers to automatically dispatch updates to tables onto topics of my choice, and have RPC bits for getting table snapshots (this along with the topic give me read functionality), along with other RPC bits for create, update, and delete.
The real problem here is user auth and permissioning. WAMP-CRA/ticket with dynamic authentication lets me do password-based authentication, except it looks to be a bit awkward for setting up a user registration - and realistically it’d be nicer for this to be offered at a library/framework level, like how Meteor users work. For example, since the challenge is made as soon as the connection is made, you end up needing to do awkward things like dropping-and-re-establishing the connection to allow a user to actually log in, and overall it seems a bit awkward, but perhaps the complexity is better resolved in a higher-level library.
The other issue is that the WAMP v2 subscriber whitelisting is not set up to allow this pattern in a transparent way. Ideally I’d like to be able to whitelist a set of users (auth ids and/or auth roles) to receive a message on a topic, rather than a set of subscription IDs. I feel like the right way to deal with object-level permissioning in this context is for all updates to go to a single topic, for the publisher to designate the authorized users, and for the broker to take care of making sure that only the properly authorized users see updates. I know that you can do this right now with per-user topics, but it’s not ideal and doesn’t really let you get to the level of richness or convenience that you get with a real object-level permissioning scheme.
It’s possible that a lot of this can (and maybe should, since you’d probably want SQLAlchemy integration) live in a framework that wraps Crossbar, but I think the authorization and subscriber whitelisting are not ideal. You can wrap some or all of this, but it feels like it’d be re-inventing the wheel.
On Monday, January 12, 2015 at 7:12:33 PM UTC-5, Greg Miller wrote:
Back in the summer I spent quite a bit of time with Meteor. It’s quite impressive but I felt it was a little constricting, and for various reasons abandoned it. But I didn’t abandon the concept of reactivity. Having found crossbar/autobahn helped me decide to ditch Meteor and to ‘roll my own’. I was mostly interested in knowing when records in a DB changed. I use Kendo UI widgets and their version of MVVM. From there it was just a matter of knowing when a record(s) changed in a table and then re-executing a read. In Crossbar I have one generic procedure for each of the CRUD operations. As soon as the operation is complete I publish the table/record to anyone that’s listening, using crossbar’s pub/sub. In the browser I have some code that registers what to do when a table/record is affected and then subscribes to that event. When the event occurs that code runs and Kendo’s MVVM updates the page. It works fine, and is nice and quick. I haven’t yet tried to replicate Meteor’s reactive select. I was hoping to find a DB that takes care of it, and rethinkdb sort of does, but they aren’t quite there yet.
I could make what I have better by having a more defined event as right now the browser reacts when any table/record is changed and it decides if it’s interested in the change. I could have one event per table, or perhaps one for each table/record.
From my point of view I use crossbar for what it can do, pub/sub, RPC, and I do the rest.