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

Move to OpenFaaS golang-http-template - part 2 #96

Open
alexellis opened this issue Oct 27, 2018 · 11 comments
Open

Move to OpenFaaS golang-http-template - part 2 #96

alexellis opened this issue Oct 27, 2018 · 11 comments
Labels

Comments

@alexellis
Copy link
Owner

alexellis commented Oct 27, 2018

Expected Behaviour

I would like to move Derek to the OpenFaaS golang-http-template so that the process can stay alive for longer without re-forking. This would allow access tokens etc to be cached in memory to reduce API requests and will increase memory under load.

It is also a step towards #62 (break out SDK) so that Derek can be run on other platforms or by other processes other than the OpenFaaS watchdog to enable wider use.

Current Behaviour

Each request runs in a new process meaning that panic and os.Exit() are fair-game to appear anywhere in the code. This prevents the above, so part of the work is refactoring any exiting and error handling.

Possible Solution

Template:

golang-http via: https://github.com/openfaas-incubator/golang-http-template

The initial work will be moving to the new template signature, this should be minimal, then from there testing that we never call panic/os.Exit.

The current Dockerfile is unnecessary at this point, since it could be replaced by the original Golang template. https://github.com/alexellis/derek/blob/master/Dockerfile

@alexellis alexellis changed the title Move to OpenFaaS golang-http-template Move to OpenFaaS golang-http-template - part 2 Oct 27, 2018
@cheikhshift
Copy link
Contributor

Would it be possible to keep panics and catch them by deferring a call to function recover?
I searched through the code, there are os.Exit invocations in vendor packages and 4 within Derek

@alexellis
Copy link
Owner Author

It would be possible, but I think we could change the code as part of this instead. Can you link to the instances (with line number) please?

@cheikhshift
Copy link
Contributor

cheikhshift commented Oct 27, 2018

@alexellis
Copy link
Owner Author

Thanks for the research.

Do you want to try doing this issue first? #97

For the line numbers you can click the line on GitHub's UI and then copy/paste the URL.

@cheikhshift
Copy link
Contributor

Sure, I updated my previous comment with links to the corresponding line.

@alexellis
Copy link
Owner Author

@cheikhshift are you still working on this? 😄

@cheikhshift
Copy link
Contributor

cheikhshift commented Jun 3, 2019 via email

@alexellis
Copy link
Owner Author

Can you propose a PR?

Alex

@cheikhshift
Copy link
Contributor

cheikhshift commented Jun 3, 2019 via email

@cheikhshift
Copy link
Contributor

cheikhshift commented Jun 3, 2019

I reviewed the issue, this is what I'm going to work on :

  • isolate most of the main.go file (in package root) in a new sub package called handler.
  • Modify the current OpenFaaS deployment file to use the Go template.
  • We need to keep invocations to panic, as they can modify response code provided by OpenFaaS. Some dependencies make invocations to os.Exit, but as long as derek is not using any deprecated functions, things should be fine.
    PR to follow soon.

Since I've mentioned HTTP responses, OpenFaas should have a helper package, to provide a sort of translation of how OpenFaaS interfaces with HTTP requests. This may reduce friction for users coming from a RESTful API background.

@alexellis
Copy link
Owner Author

Thanks for your take on the changes. We have a REST-compatible template called golang-http and golang-middleware both are available via faas-cli template store list and would have the benefit of keeping Derek's process alive between requests.

zoidyzoidzoid pushed a commit to zoidyzoidzoid/derek that referenced this issue Oct 18, 2021
zoidyzoidzoid pushed a commit to zoidyzoidzoid/derek that referenced this issue Oct 18, 2021
Closes alexellis#96

Might also close alexellis#123

Signed-off-by: zoidbergwill <[email protected]>
zoidyzoidzoid pushed a commit to zoidyzoidzoid/derek that referenced this issue Oct 18, 2021
Closes alexellis#96

Might also close alexellis#123

Signed-off-by: zoidbergwill <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants