Process releases in the server

[Belco90]

What feature would you like to have?

The current version is processing the selected range of releases in the browser. We should move this process to the server with Next.js API Routes.

What problem will this feature solve?

By moving this logic to the server, we would benefit from:

• sending less code to the browser (lighter bundle)
• processing the releases in a more powerful environment (faster processing)
• caching responses (saving processing time)

Do you want to help make the feature?

Yes

Is there anything else we need to know?

• [ ] Blocked by #2085

• All the existing E2E should work in the same way

• We need to cache the responses based on repo slug, from version and to version

• If "latest" option is found in either from or to version, we can't cache the response

[HonkingGoose]

• caching responses (saving processing time)

That sounds like a big improvement! Fetching the changelogs takes a long time right now...

I'm wondering does the cache update when people "refresh" the query? For example:

1. current cache contains renovatebot/renovate changelogs from 1.0.0 to 31.0.0
2. User runs query from 1.0.0 to latest
3. Program fetches results and updates cache
4. Cache code understands that latest points to 31.56.0???
5. Cache now contains renovatebot/renovate changelogs from 1.0.0 to 31.56.0???
6. If user runs query from 1.0.0 to 31.56.0 fetch directly from cache, no waiting???

[Belco90]

I still need to check how much granular control I have for caching requests at Vercel for Serverless Functions.

From what I've seen so far, I think that your example would work in the following way:

1. That's a request with a repo slug, from version and to version, so it's cached with no problems indeed.
2. Since one of the versions is latest, I want to use stale-while-revalidate strategy there
3. That's correct.
4. No: cache doesn't understand that latest points to 31.56.0 per se. We have two options here: a. Use the stale-while-revalidate strategy. In this case, we would return the previously processed data cached for 1.0.0 --> latest, which could be 1.0.0 --> 31.55.4 for example. This strategy would recalculate the cache in the background so it returns processed releases for 1.0.0 --> 31.56.0 the next time that 1.0.0 --> latest is requested b. In the browser we convert latest to the actual last version at that point in time, so we request 1.0.0 --> 31.56.0 to the server, which will cache the response properly
5. No matter what strategy we pick on the previous step, both 1.0.0 --> 31.0.0 and 1.0.0 --> 31.56.0 would be cached at this point
6. Next user requesting (could be the same user, or another one) 1.0.0 --> 31.56.0 would get it directly from cache, so would be an almost instant response.

[Belco90]

Increasing the priority for this one since it would make the processing faster, but also the final bundle sent to the browser smaller.