parse.com 'retweet' pattern is too verbose

@jesses.co.tt I'm sorry if this is too little too late, I definitely take note that I am answering this months after it was asked, but I do think this is worth answering in general (and maybe could still be of value to you).

In general, I 100% agree that that triple query with Parse is a) going to be massively inefficient the way it's billed (in the old system) and b) with that in mind, seems like the wrong approach even with self-hosted Parse (which contextually is the only mechanism usable at this point since Parse has now shut down, but I think would still have been up possibly when question was asked...regardless...). There's 2 solutions I see that can fix this in a fairly clean way, assuming these changes can be made to the general schema/architecture.

1)A first solution is to re-schematize the data set and essentially "foreign key" the subset of supporters each User has in the User table itself. This way, instead of going from Cause->Supporter->User, you'd theoretically be able to do Cause->User (where from users, you'd get their supporters by default as it'd be a column there). To do this in Parse, if I remember correctly you can set a column to have an array of a certain type as it's value, and then have object links there (that show up nicely in the Parse dashboard) that are actual Supporter table objects, but maintaining this column of links to that table in your User table.

While is a bit more work on the write side, since you'll have to manually do that (by manually I mean write the code yourself to do that, it should be automated but it won't happen for free in terms of development). With this slightly more upfront write operation, you then have a 2 step read instead of 3.

2) A second solution is to use a different provider for this kind of data, if query speed is an issue. In several of my projects I use socket based approaches for this kind of data query lookup, and thinks like Pusher or Firebase (both very different levels of "all inclusiveness", Firebase being much more like a Parse but from Google this time, Pusher being a bit more basic and "DIY").

With Firebase, for example, and a socket to this data set + a schema in which the Cause table itself has a cache of what Users belong to them (and in which User has a cache of their Supporters), this 3 step look up could effectively be 1 query with 2 parameters (which is I think the ideal scenario). I believe this can be achieved with Parse as well, but would require another step of schema refactoring to the first proposed solution.

I think in the comments something similar to this is recommended (both above solutions) but in a much more un-elaborated format. I hope this helps the original question-asker or someone. This could also, theoretically, as someone recommended, use PubNub as 1 comment mentioned, but it could just as easily build this schema into a PostgreSQL DB hosted on AWS or Heroku and accomplish the exact same mechanisms as Parse without the overhead.

Also, since this is in reference to Parse which is now only offered as an Open Source self hosted solution, here's a guide to migrate to hosting Parse on one's own on AWS: link here