Add feature to launch deployed functions
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):
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".
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?
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.