Provide API endpoint for transactions of an account

[slaweet]

Expected behavior

Based on the discussion between frontend team, full-stack team, and @MaciejBaj we had in the office today we came to the conclusion that there should be an endpoint to get all (incoming and outgoing) transactions of a given address.
Something like:

/api/accounts/{address}/transactions?offset=100&limit=20&type=0

Listing transactions of an account is a basic need of every banking application.

Actual behavior

In Lisk Core 0.9.X it was possible to get transactions of account with
/api/transactions?senderId={address}&recipientId={address}&offset=100&limit=20

But in Lisk Core 1.0.0 this is no longer possible because it connects senderId and recipientId with AND, not OR as it used to in 0.9.X

To some extent, it can be emulated by doing a separate request for senderId and separate for recipientId, but that doesn't scale with higher offset. As soon as, there is a higher offset (like 1000) I would have to fetch all the transactions for both senderId and recipientId up to that offset, because I cannot know how many outgoing and how many incoming are before the offset.

/api/transactions?senderId={address}&recipientId={address}&offset=1000&limit=20

Which version(s) does this affect? (Environment, OS, etc...)

Lisk Core 1.0.0

[pcdinh]

I think that we should avoid offset, limit for paging. It is not scalable. There is better way to do it: https://use-the-index-luke.com/blog/2013-07/pagination-done-the-postgresql-way

[slaweet]

Or another option to achieve the goal would be to add address parameter that internally works as senderId OR recipientId to the current endpoint:
/api/transactions?address={address}&offset=1000&limit=20

This might require less work, as it won't add a new endpoint. Also LiskArchive/lisk-elements#648 would then not be necessary.

[nazarhussain]

I agree to @slaweet we should use composite filters. We are already using behavior already and can extend if further.

https://github.com/LiskHQ/lisk/blob/20d0bbab7bc5874b802344a1c31a8cdabea7dcd9/db/repos/accounts.js#L378-L379

But what I suggest to have clear and direct naming for such parameters. senderIdOrRecipientId would be nice and easily understandable. Or some other option that clearly explain the behavior.

@Tschakki Let me know if you need any input from me.