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

Resource injection in Go #2641

Open
worstell opened this issue Sep 10, 2024 · 0 comments
Open

Resource injection in Go #2641

worstell opened this issue Sep 10, 2024 · 0 comments
Assignees

Comments

@worstell
Copy link
Contributor

supply resources (DB, verb clients) to verbs explicitly— replacing ftl.Call(...), db.Exec(...) etc. (inspired by the pattern of injecting resources @stuartwdouglas implemented for the JVM)

need a way of knowing deterministically which resources a given verb uses. investigate/propose ways to accomplish this

@worstell worstell self-assigned this Sep 10, 2024
@ftl-robot ftl-robot mentioned this issue Sep 11, 2024
worstell added a commit that referenced this issue Sep 26, 2024
https://hackmd.io/OULeRFQQQvaMURysN27eEw

only the TestLifecycle integration test is updated with the new approach
in this PR, to demonstrate that both old and new verb call strategies
are still functional. will remove other usages of `ftl.Call(...)` to
follow

- generates `<Verb>Client` signatures in external stubs and (local)
signatures in `types.ftl.go`
- generates resource registrations in `main.go` and `types.ftl.go`, e.g.
"providers" for verb clients
-`go-runtime/build.go` changes accompanying the above^ bunch of stuff to
get imports working now that we're generating full verb request/response
types rather than just function references
- updates `go-runtime/server.go` to inject the registered providers when
processing an inbound call

#2641

---------

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant