API: use APIv3 endpoint for resources

[humitos]

Initial implementation as a POC to give it a try. It works fine at first sight and I think it could be a good idea to move forward with it. I didn't find any blocker yet.

Closes #356
Requires readthedocs/readthedocs.org#11831

[ericholscher]

I worry a little bit about one of the API calls failing and leading to weird state. Would be good to put a TODO in here probably to do a retry?

[humitos]

Yes. I need to re-write this code to handle errors as well. Currently, if an API call break, the whole code breaks completely 😅

[humitos]

@agjohnson what's the best pattern to use for this chunk of code? async/await Promises (as it's written) or then-ables?

My goal here is to make multiple requests in parallel to APIv3 while handling errors. Besides, once that all requests have responded, I want to use the respond data to form the config object with the same structure we currently have.

[agjohnson]

What you have is close, though yeah it does need more error handling -- especially using fetch() you should check for resp.okay.

One thing though is that this is sort of written more like synchronous code. Normally, you'd want to take advantage of the evented code flow more, and instead of doing operations in bulk and await on each of these blocks, you'd let the request and encoding and any other operation run in a single promise.

That is, this is executing:

fetch(), fetch(), fetch(), fetch()
resp.json(), resp.json(), resp.json(), resp.json()

Where a fully evented flow is more like:

fetch(), resp.json()
fetch(), resp.json()
fetch(), resp.json()
fetch(), resp.json()

The effect can be subtle, but it does allow for early failure if one request or request response is bad.

What you have here overall is good so far, though I think through restructuring to add some error handling and simplifying things, you'll probably end up with a separate async function for a single request and request encoding.