Add GET support to RPC specification

[siddhsuresh]

Closes: #2162

What are the changes and their implications?

• Allow opt-in configuration to use GET requests than POST for query files [ mutations even with this config will only use POST requests]

Example Usage

export const config: ResolverConfig = {
  httpMethod: "GET",
}

• Show warning to the user if URL length exceeds 2083 characters which is the minimum of the maximum URL limit set by browsers (IE and Edge 16)
  • https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers/417184#417184
  • https://wiert.me/2010/04/20/maximum-url-lengths/

But, there is no practical limit for URL size for the latest browsers. So, should the warning be removed?

• Update the rpc tests to accept GET requests
• Remove updates to toolkit app - currently present to test

TODO:

• Replace esbuild usage with jscodeshift to get the config from the files

• try shifting to swc from recast to improve performance

• Remove caching layer as it is not needed anymore

Output

(Where GET request has been set for getProject and the default POST request set for getProjects

[changeset-bot]

🦋 Changeset detected

Latest commit: 5d4e3af

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
blitz	Patch
@blitzjs/rpc	Patch
@blitzjs/auth	Patch
@blitzjs/next	Patch
@blitzjs/codemod	Patch
@blitzjs/config	Patch
@blitzjs/generator	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[siddhsuresh]

@dillonraphael @beerose what is the recommended way to get the config file from the resolvers?
The ways I have tried till now:

• Use esbuild and require the resolver file directly and then get the named export config. This method exists till the 4d70c40 commit.
• Use jscodeshift and recast to use AST to find the named export config by reading the file.

I switched to the second method as it was able to handle re-runs faster when changing the config.httpMethod value in the resolvers on pnpm dev, which I think is due to the for loop in

blitz/packages/blitz-rpc/src/loader-server.ts

Line 62 in de92804

for (let resolverFilePath of resolvers) {

and am I missing an easier method to get this config?

EDIT [11-10]:

I ran a test to check the time difference between method 1 and method 2 for the

Tested using console.time in the loader-server.ts file just before and after the for loop in windows 11

  console.time("answer time");
  ...
  console.timeEnd("answer time");

1. esbuild
   

2. jscodeshift
   

Ig this makes method 2 the better choice as it is almost 500 😅 times faster even for low number of resolvers in the toolkit-app. But this is still a 12ms delay from the original, which could become worse in larger projects, to further optimise this will try to use the swc parser to read the config

EDIT 2 [12-10]:

Switched to swc parser and added an LRU caching layer to avoid re-parsing of the file to optimise the reading of the resolver configs

[flybayer]

awesome, just one small change left!