Add continuous queries

[rhauch]

The prototype did not support queries due to time constraints, and because queries were likely to be pretty straightforward.

But rather than just add regular queries, it would be far better (and more along the lines of the rest of the architecture) to support continuous queries, and allow clients to subscribe to these queries and receive the results (initially) and changes to the results (continually).

Consider RethinkDB, which allows ad hoc queries that produce results and that will also tell the server to send changes in that view to the client. This is quite interesting and powerful, but it's not clear that most mobile apps really need ad hoc queries. Instead, developers might need to try different queries, but then once they settle upon a set of queries the mobile app will use, those queries will not change (until future releases of the app).

Some of these queries will not use parameters, meaning all mobile apps would issue the exact same query. Debezium could maintain the results and would return them as needed (as soon as the client subscribed), and any changes in the results could be sent to subscribed clients (via events and notifications).

Some of the queries would likely be parameterized, meaning different clients would supply different values for the parameters. To implement this, Debezium could maintain the complete results as well as indexes (either on the parameters and/or the clients) so that as changes come in it can continually evaluate which clients need the update and send the changes to them.

[emmanuelbernard]

It's unclear to me that continuous query is a clear winner and has obvious use cases for the mobile case. It makes for a strange UI as things do change without user intervention.