Comments (12)
provide hook points for private implementations.
@glibsm can you be more specific here?
AFAICT, using dependency injection to accomplish polymorphism (what I think you're talking about here) is more obvious for users and better for testing and concurrency. You no longer need to wonder what globals exist or what side-effects occur, since everything is explicit and defined at the func/struct level.
At face value, I agree with @peter-edge here - it would be great if the user experience for UberFX was:
- Instantiate a few UberFX shapes
- Combine those with the required shapes
- That's all
In general, we've pushed really hard not to have any globals in YARPC, since they compose very poorly, make testing harder, and introduce problems with concurrency.
from fx.
I agree with the general sentiment of removing the globals, but sometimes they are necessary to provide hook points for private implementations. We use that in several places like, for instance, the metrics backend comes from a closed source repo.
from fx.
@breerly Take a look, for instance, at RegisterRootScope
and how it's used in the private repo to hook up the reporter.
I agree that DI can probably help with this, or completely replace the practice alltogether, but we're nowhere near ready to start replacing these registration functions with dig, which is still in short trousers.
from fx.
I actually want to rename this to "let's try to get rid of as many globals as possible". Having gone through the code with the module rewrite PR, there's a lot of places where what I would expect to happen will not happen.
from fx.
I did a quick search, this is a rough list of the globals I think should be killed in theory:
modules/uhttp/internal/stats/metrics.go:38:2: HTTPTags
modules/uhttp/internal/stats/metrics.go:44:2: HTTPPanicCounter
modules/uhttp/internal/stats/metrics.go:46:2: HTTPAuthFailCounter
modules/uhttp/internal/stats/metrics.go:48:2: HTTPMethodTimer
modules/uhttp/internal/stats/metrics.go:50:2: HTTPStatusCountScope
metrics/metrics.go:35:2: _scopeFunc
metrics/metrics.go:36:2: _mu
metrics/metrics.go:37:2: _frozen
metrics/nop_reporter.go:52:5: NopCachedStatsReporter
metrics/nop_reporter.go:77:5: NopCachedCount
metrics/nop_reporter.go:86:5: NopCachedGauge
metrics/nop_reporter.go:95:5: NopCachedTimer
modules/rpc/thrift.go:33:5: _setupMu
modules/rpc/yarpc.go:55:2: _dispatcherMu
modules/rpc/yarpc.go:58:2: _dispatcherFn
modules/rpc/yarpc.go:61:2: _starterFn
modules/rpc/yarpc.go:69:2: _controller
ulog/log.go:90:2: _setupMu
ulog/log.go:91:2: _once
ulog/log.go:92:2: _std
modules/rpc/internal/stats/metrics.go:40:2: RPCTags
modules/rpc/internal/stats/metrics.go:46:2: RPCAuthFailCounter
modules/rpc/internal/stats/metrics.go:48:2: RPCHandleTimer
modules/rpc/internal/stats/metrics.go:50:2: RPCPanicCounter
service/service_setup.go:37:5: _simpleCtx
auth/uauth.go:32:2: _registerFunc
auth/uauth.go:33:2: _setupMu
modules/task/internal/stats/metrics.go:35:2: TaskTags
modules/task/internal/stats/metrics.go:40:2: TaskExecutionCount
modules/task/internal/stats/metrics.go:42:2: TaskPublishCount
modules/task/internal/stats/metrics.go:44:2: TaskExecuteFail
modules/task/internal/stats/metrics.go:46:2: TaskPublishFail
modules/task/internal/stats/metrics.go:48:2: TaskExecutionTime
modules/task/internal/stats/metrics.go:50:2: TaskPublishTime
config/config.go:53:2: _setupMux
dig/default.go:24:5: defaultGraph
modules/task/task.go:39:2: _globalBackendMu
modules/task/task.go:40:2: _globalBackend
modules/task/task.go:41:2: _asyncMod
modules/task/task.go:43:2: _once
from fx.
I think in general, I'd like to be able to have two independent service.Manager
instances that have no effect on each other. I know the general thinking is "well most people won't want this", but 1. I think then we might as well just make the Manager
concept a single global instance inside service 2. I can think of situations like integration testing (imagine two Managers
controlling Modules
that talk to each other) where this could be super useful
from fx.
+1 for Glib, there are useful in some cases to make code more easy and intuitive to use. We can go after specific globals that kill thread safety or make testability harder etc., not all of them.
from fx.
@breerly e.g. RPCInit Dispatcher is different from YARPC Dispatcher, this could go away with DI though.
from fx.
100% agreed - let's grow into it, with the goal of using DI and dig to accomplish this 🗡
from fx.
#316, #317, and #318 gets rid of the relevant global variables for statistics in modules.
from fx.
#323 gets rid of the relevant global variables in the metrics package.
from fx.
Closing - the modular
branch, which reflects the direction of this project, contains absolutely 0 globals.
from fx.
Related Issues (20)
- `fx.Decorate` not working w/ value groups HOT 3
- doc error on [register a handler with the server] HOT 2
- Fx exiting program before panic in OnStart hook gets reported HOT 1
- Add ability to override os.Exit for fxtest HOT 1
- fx.Evaluate: Support dynamic graphs by returning fx.Option from constructors
- https://github.com/benbjohnson/clock is EOL/archived. HOT 1
- fx.Decorate does not add a missing object to the module HOT 3
- When combining fx.As to annotate return type as interface with optional parameters nil value check is not working as expected HOT 1
- Startup order isn't preserved when using modules HOT 3
- Example test failing in master branch when port 8080 is already in use (89f4a90) HOT 3
- fxevent.Logger: Silence until there's an error
- Slog adapter for fx HOT 4
- Release method HOT 10
- fxtest.Lifecycle: Enforce timeout
- Impossible to inject struct that is part of a group by itself HOT 2
- Support Multiple ParamTags? HOT 1
- signalReceivers should call `Signal.Stop(recv.signals)` when stopped
- Release v1.22.0
- Private supplies HOT 1
- Support multiple ResultTags annotations
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fx.