WIP: Make Queries use GET

[shayneczyzewski]

Description

This PR is open mainly for the discussion around shifting Queries from POST to GET. The approach in this PR does move us in the "right direction" of usingGET for their semantically correct operations. However, because Wasp lacks the input arg type info, if we simply made them URL params they would all come out on the server as strings. That would not be ideal since it would (a) be a breaking change, and (b) the user would have to do a ton of type conversions in their query functions. The approach taken here mirrors that of POST before- namely, serializing JSON as an arg. This is not ideal/traditional REST-style, however. :/

The main question is: do we wait on this until we allow users to specify the route and param types for Queries, or is this already a useful step in the right direction we want to take on, knowing it still may "look weird" to devs.

Before:

Request URL: http://localhost:3001/operations/get-task
Request Method: POST
Request Payload:
{"id":23}

After:

Request URL: http://localhost:3001/operations/get-task?args=%7B%22id%22:23%7D
Request Method: GET

Let's discuss! :D

Fixes #445

Type of change

Please select the option(s) that is more relevant.

• Code cleanup
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

[Martinsos]

Looks good @shayneczyzewski !

This is a bit hard decision. What are pros and cons?
I guess this makes it a bit nicer / more semantically correct, right?
Yes it is still one big argument, but ok.
If there wasn't for limit, I would say it is certainly better. But if we say limit is not a problem, then that also stands.
So I think it is ok to do this change, why not!

And in the future we can type it better. But I don't see anything very bad with having one big argument, to be honest.

[Martinsos]

Ah yes well this captures it all!
Should we leave some of this comment around? Or maybe best just to create a GH issue to track this?

[shayneczyzewski]

If we do go with this approach I will do one of those options for sure 👍🏻 thnx

[shayneczyzewski]

Thanks for your thoughts @Martinsos. The more I think about this, the more I am inclined to leave it as a POST until we have enough information about args to make them proper GET requests. Right now, we are just trading one "strange" thing for another, which probably isn't worth it. And while the 2k char limit for some browsers for URIs is also there, I think that is a side concern- if you are adding that much info to your GET request I think "you are doing it wrong." :D

What do you think @sodic? Use this? Punt until we have proper types associated with route/query params in .wasp files? Something else? Thnx

[Martinsos]

Makes sense! I am ok with both, although if I had to choose right now, I would probably go with this GET even though it has "weird" arguments. It still feels a bit more correct. But whatever you decide I am good with!

[sodic]

Punt until we have proper types associated with route/query params in .wasp files?

Yes, I prefer sticking with POST for now.

I know some sites use long base64 URLs, but I always found it ugly. It's also a non-standard approach (i.e., browsers and the infrastructure aren't built to optimize on it). Plus, I think it makes for a worse developer experience (think about how debugging requests would look like in Chrome DevTools, or even by reading the logs).

Therefore, I agree with Shayne's last comment, we would be substituting one strange thing for another, and the one we have now is at least human readable and easy to debug.

[Martinsos]

All right, sounds good to me!

[shayneczyzewski]

Thanks for the input @Martinsos and @sodic. I will close this PR now. At least we reminded ourselves of the reasons to stick with POST until we have proper types for operations. :) One day... haha

[Martinsos]

Hah yes :D. Maybe sooner than we think :D!