Allow to run queries through LiveQueryClient

[messagenius-admin]

Current Limitation

When developing applications using Parse, you want to sync the App with the Server when the App is re-opened after being killed, shut down or restored from the background.

You need a Query to obtain the most current data and subscribe to a LiveQuery to receive real-time updates while the application is in use.

In complex apps with multiple collections, a large number of Query + LiveQuery combinations are necessary every time the app is restored from the background, requiring several REST calls and a WebSocket connection.

Feature / Enhancement Description

It should be possible to run Queries through a LiveQueryClient, and/or to request query results along with LiveQuery subscription to enable syncing collections and subscribing to LiveQueries with a single WebSocket connection.

We believe that this improvement makes a difference. It's easy to develop and maintain, with minimal changes to the Parse Server and client SDKs.

This is not a breaking change, it is fully retrocompatible, and existing apps can be improved easily.

EDIT Apr 30:
It would be beneficial to have the option to use WebSocket for all requests, including Queries, Saves, Cloud Functions, and all CRUD operations.

Example Use Case

Imagine a complex TODO mobile app with six collections: boards, tasks, goals, categories, tags, and users.

Every time the user opens the App after from background, especially after being offline, you need to run six Parse Queries and subscribe to them.

Each of the six queries is an HTTP/REST API call, while all LiveQueries travel on a single Websocket connection.

Current Approach:

const tasks = getTasksFromLocalDb();

const query = new Parse.Query('Tasks');
query.greaterThan("modifiedAt", getLastTimeOpenedApp());

// This is the standard (and only) way so far to retrieve objects. 
const results = await query.find(); // For each Query, the SDK triggers the REST API Call we want to avoid.
results.forEach(task => tasks[task.id] = task);

const subscription = await query.subscribe();
subscription.on('create', task => tasks[task.id] = task);

Possible Alternative 1:
Get query results leveraging the subscription

subscription.on('result', task => tasks[task.id] = task);
subscription.find(); // or subscription.first(); or getResults() or runQuery(), or any other naming that makes sense.

Possible Alternative 2:
Allow running any query from a LiveQueryClient. This potentially enables developers to run queries through WebSocket, detached from a subscription.

const client = new LiveQueryClient({ ... });
const querySubscription = client.querySubscribe(query);
querySubscription.on('result', task => tasks[task.id] = task);

Ideally, both alternatives 1 and 2 should be developed, with one serving as a shortcut for the other.

3rd Party References

Firebase onSnapshot event.

[parse-github-assistant]

Thanks for opening this issue!

[mtrezza]

I suppose this feature requires changes in Parse Server and at least the Parse JS SDK to a Parse client SDK to test with?

[messagenius-admin]

Created a JS SDK Issue ere: parse-community/Parse-SDK-JS#2114

[mtrezza]

Note: the scope of this issue in regard to the bounty includes parse-community/Parse-SDK-JS#2114

[mortenmo]

Is this trying to solve a performance problem with too many https calls? Working a lot with ParseJS trying to make it work great offline lately, in my humble opinion this is probably not worth the effort.

Its not like you have to write the code for each object type but create a generic store that executes the logic you describe. We built one loosely based on https://github.com/parse-community/parse-react/blame/master/packages/parse-react-base/src/useParseQuery.ts which has a decent way of doing what you describe. I do think it is useful to get the "current results" when you subscribe (because you almost always need that), but this could be solved in the JS SDK completely today without doing pure queries over the websocket.

If it is a performance challenge to fix, why not put every request over the livestream, not just one you subscribe to. Then I'd like a mode where just all server comms go over the websocket and never uses https (ad-hoc finds, saves, etc).

[messagenius-admin]

Hi @mortenmo,
thanks for sharing.

In this particular Issue, I'm trying to solve performance issues but with minimal impact on existing code and this is just a piece of a larger improvement.

The problem is that, even with the generic handler that you implemented in React, the client has to run a query (which means an HTTP call) each time the app is restored from an offline period, (even after being in background for just 1 second, in iOS)

The code you pasted:

... but create a generic store that executes the logic you describe. We built one loosely based on https://github.com/parse-community/parse-react/blame/master/packages/parse-react-base/src/useParseQuery.ts
the client is doing 3 operations for each Class:

is a great example of how each client SDK should manage to sync; in fact, we would need it for iOS, Android, Flutter, and others. We should open a feature request for each client.

why not put every request over the live stream [...] all server comms go over the websocket [...] (ad-hoc finds, saves, etc)

I would love it, but it may be a longer shot. I'll edit the Issue to add this option.