invoking api function vs route is confusing

[skorfmann]

I tried this:

// This is the import statement in Wing.
// Here we bring the Wing standard library that 
// contains abstractions of popular cloud services.
bring cloud;

// This code defines a bucket as part of your app.
// When compiling to a specific cloud provider
// it will be substituted by an implementation for
// that cloud. I.e, for AWS it will be an S3 Bucket.
let api = new cloud.Api();

api.get("/foo", inflight (req) => {  
  let search = req.query.get("hello");
  log(search);
  return {
    status: 200,
    body: "yeah"
  };
});

playground

use the Wing console to invoke:

1. The API route
2. The API route handler

This happened:

1. API Route

response: 200 / no error query variable is logged as undefined

1. API Handler

Error from the invoked function

{
  "success": false,
  "error": "Cannot read properties of undefined (reading 'hello')"
}

I expected this:

Original content of the I expected this paragraph: While I understand that these are two different "features", intuitively I was clicking on the get function and invoked it, expecting that it would perform an HTTP call to via the API. I was actually looking for a way to specify the query parameter until I realized that this has to be done on the API itself. And yes, I think I ran into this multiple times already.

The desired behavior decided is to show this error message:

{
  "success": false,
  "error": "Function payload did not match the schema of cloud.ApiRequest (received 'undefined')."
}

Is there a workaround?

use the API node

Component

Wing Console

Wing Version

0.29.6

Node.js Version

18.6.0

Platform(s)

MacOS

Anything else?

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

[Chriscbr]

query variable is logged as undefined

I think this should be fixed by #3771

While I understand that these are two different "features", intuitively I was clicking on the get function and invoked it, expecting that it would perform an HTTP call to via the API. I was actually looking for a way to specify the query parameter until I realized that this has to be done on the API itself. And yes, I think I ran into this multiple times already.

Yeah, I see the confusion. I think the situation would be improved if we added some basic validation to the route handlers, so that instead the user will see an error like:

{
  "success": false,
  "error": "Function payload did not match the schema of cloud.ApiRequest (received 'undefined')."
}

We could also e.g. make the child resources of cloud.Api hidden by default, but I think there's some value to letting the users build understanding / "empathy" for the fact that each route will actually create a cloud.Function on your behalf. (Similar to if you call queue.setConsumer, it also creates a cloud.Function on your behalf). But I'm not sure.

Maybe there are other UX solutions to this? cc @skyrpex

[skorfmann]

While I understand that these are two different "features", intuitively I was clicking on the get function and invoked it, expecting that it would perform an HTTP call to via the API. I was actually looking for a way to specify the query parameter until I realized that this has to be done on the API itself. And yes, I think I ran into this multiple times already.

Yeah, I see the confusion. I think the situation would be improved if we added some basic validation to the route handlers, so that instead the user will see an error like:

{
  "success": false,
  "error": "Function payload did not match the schema of cloud.ApiRequest (received 'undefined')."
}

This would help already 👍

We could also e.g. make the child resources of cloud.Api hidden by default, but I think there's some value to letting the users build understanding / "empathy" for the fact that each route will actually create a cloud.Function on your behalf. (Similar to if you call queue.setConsumer, it also creates a cloud.Function on your behalf). But I'm not sure.

I see the point of conveying the fact that there are cloud functions involved. However, are there good use-cases where the function would actually have to be invoked directly rather than through the Api?

[Chriscbr]

However, are there good use-cases where the function would actually have to be invoked directly rather than through the Api?

I'm not sure if you'd want to invoke the function directly, but maybe when the Wing Console supports it, users might want to click on the children cloud.Function's to view their logs, or check the most recent invocations, etc. But yeah, it's probably not a big deal one way or another. :-)

[staycoolcall911]

I updated the I expected this section to reflect that the desired behavior change here is merely to change the error message.

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!