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

[Observability discussion] How do we untangle our dependencies between plugins? #88788

Open
jasonrhodes opened this issue Jan 20, 2021 · 2 comments
Labels
chore R&D Research and development ticket (not meant to produce code, but to make a decision) Team:Observability Team label for Observability Team (for things that are handled across all of observability)

Comments

@jasonrhodes
Copy link
Member

@smith and @weltenwort, I know you two have thought about this a lot already. Primarily, we need to untangle our dependencies between each of our plugins because of Typescript, but I think it's a good idea to do this work for lots of reasons. 

I'd just like to make sure we have a somewhat consistent way to manage breaking out shared pieces of our apps so that they can be imported across other Kibana plugins without causing complex dependency trees that risk accidental circular dependencies. Can we start a conversation about the different options for solving this here in this issue?

For instance, we've discussed breaking our various apps into multiple plugins, e.g. "logs-shared" and "logs-app", and require that all deps flow from shared to app. In this model, we would only export deps for others from our "-shared" apps.

Also pinging @elastic/logs-metrics-ui @elastic/apm-ui @elastic/uptime @elastic/kibana-core @elastic/kibana-stack-services for any context anyone on those teams can provide for how to best handle this.

@jasonrhodes jasonrhodes added chore R&D Research and development ticket (not meant to produce code, but to make a decision) Team:Observability Team label for Observability Team (for things that are handled across all of observability) labels Jan 20, 2021
@pgayvallet
Copy link
Contributor

For instance, we've discussed breaking our various apps into multiple plugins, e.g. "logs-shared" and "logs-app", and require that all deps flow from shared to app

That's the most common adopted pattern when there are some bi-directional dependencies between 2 plugins

e.g

appA -> appB
appB -> appA

=>

appA -> commonA, commonB
appB -> commonA, commonB

@smith
Copy link
Contributor

smith commented Jan 20, 2021

Adding TS project references will be a big help here, since currently dependencies between plugins are tracked through kibana.json, which is basically a guess, as I've discovered quite a few dependencies that weren't declared in those files.

#81003 is where we're tracking this migration in APM. I'm working through the tree of dependencies, currently working on the observability plugin and its dependencies.

From what I can tell so far, we're not in too bad of a state, and I don't foresee any big problems untangling our existing circular dependencies. I feel like right now it's a problem of visibility and once that's resolved a few minor untangling tasks need to happen.

Once all that's taken care of, the suggestions above should be sufficient and I'd be open to any methods we can come up with together to keep it clean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore R&D Research and development ticket (not meant to produce code, but to make a decision) Team:Observability Team label for Observability Team (for things that are handled across all of observability)
Projects
None yet
Development

No branches or pull requests

3 participants