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

Split the weavelet in two. #466

Merged
merged 1 commit into from
Jul 19, 2023
Merged

Split the weavelet in two. #466

merged 1 commit into from
Jul 19, 2023

Conversation

mwhittaker
Copy link
Member

Before this PR, we had a weavelet that was used by all the deployers. This made the weavelet code a bit hard to follow. I would say 75% of the weavelet code only ran in multiprocess mode (e.g., setting up internal listeners, updating routing info, setting up mTLS), but some bits of code only ran in single process mode. The control flow of this code was also dictated by a combination of a Bootstrap struct passed via a context.Context, some environment variables, and the Env interface (which was only partially implemented in the single process case).

This PR splits the weavelet in two. First, I introduce a new Weavelet interface that borrows from the old private.App interface:

type Weavelet interface {
    GetIntf(t reflect.Type) (any, error)
    GetImpl(t reflect.Type) (any, error)
}

Conceptually, a Weavelet is something that hosts components, and it provides an API to get a handle to these components.

Next, I introduce a SingleWeavelet implementation that is used by go run . and weaver single deploy and a RemoteWeavelet implementation that is used by all other deployers.

@mwhittaker mwhittaker requested a review from ghemawat July 18, 2023 23:20
@mwhittaker mwhittaker self-assigned this Jul 18, 2023
Copy link
Collaborator

@ghemawat ghemawat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice cleanups. Thanks.

Before this PR, we had a weavelet that was used by all the deployers.
This made the weavelet code a bit hard to follow. I would say 75% of the
weavelet code only ran in multiprocess mode (e.g., setting up internal
listeners, updating routing info, setting up mTLS), but some bits of
code only ran in single process mode. The control flow of this code was
also dictated by a combination of a `Bootstrap` struct passed via a
`context.Context`, some environment variables, and the `Env` interface
(which was only partially implemented in the single process case).

This PR splits the weavelet in two. First, I introduce a new `Weavelet`
interface that borrows from the old `private.App` interface:

```go
type Weavelet interface {
    GetIntf(t reflect.Type) (any, error)
    GetImpl(t reflect.Type) (any, error)
}
```

Conceptually, a `Weavelet` is something that hosts components, and it
provides an API to get a handle to these components.

Next, I introduce a `SingleWeavelet` implementation that is used by `go
run .` and `weaver single deploy` and a `RemoteWeavelet` implementation
that is used by all other deployers.
@mwhittaker mwhittaker merged commit 4890fe3 into main Jul 19, 2023
7 checks passed
@mwhittaker mwhittaker deleted the runners branch July 19, 2023 18:26
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

Successfully merging this pull request may close these issues.

2 participants