serverless-vscode icon indicating copy to clipboard operation
serverless-vscode copied to clipboard

Add feature to launch deployed functions

Open TimCoates opened this issue 7 years ago • 3 comments

This is a (Feature Proposal)

Description

For bug reports:

  • What went wrong?
  • What did you expect should have happened?
  • What was the config you used?
  • What stacktrace or error message from your provider did you see?

For feature proposals:

  • User creates a Serverless service, containing n functions. User deploys the service, AWS allocates a randonly named API gateway URL for the service, suffixed with each function. User wants to open one or more functions in a browser.
  • Might be sensible to enable 'open all functions in browser' or 'open this function in browser' by default?

Similar or dependent issue(s):

  • none

Additional Data

  • Extension version:
  • Serverless Framework: Version:
  • [ ] Serverless installed globally
  • Operating System:
  • Stack Trace (if available):

TimCoates avatar Feb 12 '18 13:02 TimCoates

Hi @TimCoates , thanks for the feature request 👍

You're absolutely right. The feature makes sense because of the random nature of the API and lambda path names. Of course the AWS specific functions should only appear if used with an AWS service (the plugin should be compatible with all others too, like Azure, OpenWhisk, Google, etc.).

However, there are some things that need to be clarified first. If we offer a context menu entry "open in browser" on a http endpoint in the serverless tree, wouldn't that only be suitable for GET requests? How could such a feature be offered for other endpoint types like PUT or POST?

On a function level (the function nodes in the tree) it would not make so much sense, because the lambda's url itself is only a POST capable url. There it might be better to offer something like "open in AWS console".

HyperBrain avatar Feb 12 '18 14:02 HyperBrain

I take your point about POST (or other) http methods, the suggestion is only really good for a GET request.

Another option (perhaps more valid for POST etc) might be to generate a Postman (or other REST client) collection which targets the URLs exposed by the service?

TimCoates avatar Feb 13 '18 11:02 TimCoates

might be to generate a Postman (or other REST client) collection

I like the idea. A PostMan collection would be great and I'd even favor that for all endpoints. The REST client type could then be defined in the configuration (with a default of PostMan), so that other clients could be added as well (as soon as someone has a specific demand).

Additionally this fits into a good OOD approach for the extension's implementation itself.

HyperBrain avatar Feb 13 '18 12:02 HyperBrain