Limitations on pagination & filtering

[FranZavalla]

Hello everyone!

I'm building a dApp with your SDK for a token swap system and I'm having some issues with pagination/filtering. Do you have or are you planning to provide a more expressive filtering solution from the SDK?

My use case is that: I have a listing page where groups of 10 swap offers are displayed at a time.
Currently, my pagination works as follows:

1. First, I call the SDK function getContracts({tags: [myDAppTag], range: "contractId;limit 10;offset 0;order desc"})
2. Then, I filter the elements that are "valid for my app," meaning they are currently "swappable" (i.e., no one has accepted the offer yet) and the swap has not expired.
3. Finally, I parse the resulting list to display the data correctly.

So, it may happen, in step 2, that out of the 10 contracts I request in the query, none are "valid" on page X according to my filters, resulting in a blank page. Then, on page X+1, I might get results. In other words, the following scenario could occur:

Since the fetching results (except for the first one that went fine) would be:

[hrajchert]

Filtering can be done either in the Frontend or the Backend, the issue that you mention happens when the filtering is done on the Frontend.

At the moment the filtering capabilities of the getContracts method are quite limited. For example, when you provide multiple tags, the filter behaviour is to see if a contract has tag A OR tag B. If you want to do AND logic instead, for the moment you need to pass both tags and do additional filtering in the front.

We are thinking on how we could extend the filtering capabilities. One alternative could be to use a query DSL that works with query parameters, another could be to create a GraphQL service, but we need more feedback from different use cases to come up with the proper solution.

In any case, the Marlowe Web Runtime is a useful service that some Dapps can use as its sole backend, but it is impossible to cover all use cases. For complex Dapps it is recommended to create a backend infrastructure (that can use different components of the runtime) that uses the BFF (backend for frontend) pattern.

You can also make a pure frontend solution, but you need to keep some state and depending on how many elements you discard, you might suffer from latency. The basic idea here would be to ask for elements, filter the ones that doesn't match, and ask for the next range to fill in the previous page.