feat: add /blocks that enforces range query param.

[TarikGul]

Feature

Endpoint: /blocks

Query params: range (required) ex. /blocks?range=0-999

• I implemented our own range parser because it's not perfectly clear yet if we want to provide support only for a static range such as 0-999, or for something more dynamic such as 1,2,3,10-100,123,1234

Response:

[
{<IBlock>},
{<IBlock>},
...
]

co-authored by @jsdw (Implemented the PromiseQueue)

closes: #460

[TarikGul]

Some benchmarks for querying 1000 blocks at a time against a polkadot archive node:

GET /blocks?range=0-1000 200 4242ms
GET /blocks?range=10000-11000 200 4074ms
GET /blocks?range=100000-101000 200 4578ms
GET /blocks?range=1546264-1547264 200 7568ms
GET /blocks?range=2416152-2417152 200 5778ms
GET /blocks?range=3000000-3001000 200 6084ms
GET /blocks?range=7482904-7483904 200 17009ms

[niklasad1]

I find this logic a little bit hard to understand.

As it will accept both 0-100 and 100-0, I kind assumed that that "reverse range" should not work.

[niklasad1]

i.e,

if !(this.verifyUInt(min) {
  throw new BadRequest('Inputted `min` invalid UInt.');
) 

if !(this.verifyNonZeroUInt(min) {
  throw new BadRequest('Inputted `max` invalid NonZeroUInt.');
) 

// not sure if range(1,1) should be valid seems pointless but could work :)
if (min > max ) {
   throw new BadRequest('Invalid range: max must be bigger than min');
}

[TarikGul]

Yea this is totally correct, will add that check.

[niklasad1]

I would rather a have two different functions because the code becomes easier to understand as I suggested but your choice :)

[TarikGul]

You mean with verifying UInt and a NonZeroUInt correct? If so, sounds totally reasonable.

[niklasad1]

yeah, or something even better.

[TarikGul]

Yea i agree, it will allow for concise behavior between the min and max as well. Will put that in now.

[TarikGul]

Okay yea i cleaned it up to handle Uint correctly and Non zero uints correctly. I think its way cleaner and concise about what the error messages will return.

[niklasad1]

hmm, a double ended queue should be faster than a LinkedList here.

[jsdw]

that's true, the linkedlist was just easier to implement I guess, and with a double ended queue you probably want to make sure it shrinks down again when items are removed, which the linked list thing just handles :)

[TarikGul]

Given this notion, do we want to implement a double ended queue, or is a linked list sufficient?

[niklasad1]

leave it out this PR, I think the networking is the bottleneck anyway.

but maybe worth investigating :)

[jsdw]

Just a random thought; I wonder how many of these sorts of functions could just be standalone utility functions and not be associated with a class in some way (once something is in a class, it has access to everything under this and so in my mind can be a little harder to reason about what they might do, whereas with standlone functions in a utility file you know exactly all of the data they will have access to).

(not suggesting anything should be done here)

[TarikGul]

Yea I am open to pushing this in our util folder. It's newly created with the PromiseQueue being added to sidecar so it would be nice to have these simpler verification helper functions in there.

[TarikGul]

It's a start to definitely clean things up.

[TarikGul]

Okay cool, so the verifyInt has all been removed and added to its own integers util folder.

[jsdw]

Suggested change

	rangeOfNums.map(async (n) => await this.getHashForBlock(n.toString()))
	rangeOfNums.map((n) => this.getHashForBlock(n.toString()))

I guess this is identical anyway?

[TarikGul]

yea this is correct we dont need the async await

[jsdw]

Looks great!