Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add feature to launch deployed functions #19

Open
1 task
TimCoates opened this issue Feb 12, 2018 · 3 comments
Open
1 task

Add feature to launch deployed functions #19

TimCoates opened this issue Feb 12, 2018 · 3 comments
Labels

Comments

@TimCoates
Copy link

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):
@HyperBrain
Copy link
Owner

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".

@TimCoates
Copy link
Author

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?

@HyperBrain
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants