Query data on Receivers!

Hi dev and community team!

We were wondering how useful it would be to create a query option on the Receivers. The use case would be on really large datasets, an engineer instead of requesting the whole stream and then doing some filtering on the clients they can prefilter those data on the server. This has obvious benefits as the filtering in the db would be much more efficient than on your client, less data to move around the networks and probably smoother clients all around!

  • Do you think this could be something you would use in your day to day work?

At Arup we did create a version of the sender like that on v1 of Speckle. As you can see there was a separate component that could guide the user on what is possible i.e. include specific type of geometry, specific layers, info from those objects etc…

  • We also wonder if this should go to the main receivers or on a new “custom” receiver?

Would love yo hear your thoughts.

cc: @jenessa.man @daviddekoning

1 Like

I like this and I’m sure others would find it useful! In general, we’d like to keep the core send & receive nodes as simple as possible, so my vote would be for a separate one…
Let’s see what others have to say :smiley:

1 Like

It will be a welcome feature! There’s several blockers for this, namely #339.

There are some hidden depths: Currently the rest endpoints only support a “full” object download, with all its sub-components. One limitation when using queries like this is that you will not be able to get the full object tree, but rather a flat list of objects that match what you’ve requested. We’ll need to see how this will actually perform with the rest of the SDK (specifically deserialisation).

We’ll need to weigh that against client side filtering :slight_smile: V1 was easier from this POW as all data was guaranteed to be in a list.

Side note: In Grasshopper & Dynamo you can “receive” by object URL by inputting that straight in a receiver node. It’s useful to receive subsets of data. E.g.:


You can just get one slice:

Not the first time we think about this, but it would actually be useful if collections would be directly addressable like this too.