RPC: Add get objects by type endpoint

[666lcz]

@longbowlu has pointed out a way to implement this without adding additional indexing on the objects level. We can leverage the existing events store by querying events by specific package/module and event type == 'newObject' to get all the object ids created in the module.

The current blocker is exposing the events query API, issue to track: #2067

[0xYao]

Hey, I'd be interested to help out. Can you share the details of the context in this issue please?

[0xYao]

Here is a draft specification of the API. Please share your feedback, and I will start the implementation if we think it's good to go.

[0xYao]

API use case

• Get all shared objects of a package with a RPC call and display these objects on the frontend without knowing the object ids beforehand.
• This can be a powerful code search tool for explorations for developers.

Expected function signature and output

• Expected function signature:

  #[method(name = "getModuleObjectsByTypes")]
  async fn get_module_objects_by_types(
    &self,
    package: ObjectID,
    module: String,
    /// If the types is None, return all objects in this module.
    types: Option<Vec<String>>
    /// We can potentially add other filters in this function,
    /// e.g. is_object_shared, owner_address, recipient_address etc.
    ...other_filters
  ) -> RpcResult<Vec<GetObjectDataResponse>>;

• Expected output, see Sam’s message in Telegram:

  • Get the type(s) from the package.
  • Get all the objects of this type, then filter by the ones that are shared.
  • Or, if you happen to know which ones are supposed to be shared up-front (usually the case in idiomatic Move code), you can query for those types directly.

• Note: get_module_objects_by_types will be part of the RpcReadApi trait.

Pseudo code implementation

1. Get all events of a module using get_events_by_module
   1. Paginated the queries to get every event of the module because the query has a response count limit.
2. Filter and get all the NewObject and DeleteObject events, then remove any NewObject events if that object has been deleted (i.e. this is the disjoint set of the two events).
3. For every object id, call the get_object function defined in RpcReadApiServer.
4. Filter the objects by the type given from the input.
5. Return the final list of filtered objects.

Clarifications / Assumptions

• Do you guys think we should add additional filters defined in the comments of the function?
• Is it be better to return Vec<GetObjectDataResponse> or Vec<SuiObjectInfo>?
• [event][mvp] streaming & query apis #2067 is blocking this issue because:
  • The EventReadApi trait is not fully implemented, e.g. every function returns an empty vector.
• Which trait should I add the get_objects_by_types method to?
  • It looks like I should add it to the RpcReadApi.

Optimizations

• Need to profile the method implementation first.
• What are the bottlenecks of this implementation?
  • The number of events returned from the event store can be potentially very large, so we might need to think of an alternative way to getting all events of the module.

[jamescarter-le]

This is a very useful call, but please consider extending this to Address/Object Owned objects also: get_owned_objects_by_type

[wlmyng]

This endpoint is available on the rpc 2.0 implementation in graphql. Example .graphql:

{
  objects(filter: {type: "0x2::coin::Coin", owner:"0xaddress"}) {
    nodes {
      address
    }
  }
}