A dependency injection based application framework for Go.

Overview

🦄 Fx GoDoc Github release Build Status Coverage Status Go Report Card

An application framework for Go that:

  • Makes dependency injection easy.
  • Eliminates the need for global state and func init().

Installation

We recommend locking to SemVer range ^1 using Glide:

glide get 'go.uber.org/fx#^1'

Alternatively you can add it as a dependency using go mod:

go get go.uber.org/[email protected]

Or by using dep:

dep ensure -add go.uber.org/[email protected]

Stability

This library is v1 and follows SemVer strictly.

No breaking changes will be made to exported APIs before v2.0.0.

This project follows the Go Release Policy. Each major version of Go is supported until there are two newer major releases.

Issues
  • Move service handler creation after FX creates dispatcher

    Move service handler creation after FX creates dispatcher

    Because we create service before the yarpc.Dispatcher it is hard for clients to get it in the constructor, they have to get it during request serving to e.g. create client.

    With this change services will be able to resolve Dispatcher at construction time.

    opened by ghost 21
  • [WIP] Add fx.OnStart

    [WIP] Add fx.OnStart

    fx.OnStart reduces boilerplate when adding a function to be run when the application is started.

    It reduces boilerplate like:

    fx.Invoke(
        func(lc fx.Lifecycle, a *Type1, b *Type2) {
            lc.Append(fx.Hook{
                OnStart: func(ctx context.Context) error {
                    doSomething(a, b)
                },
            })
        },
    )
    

    into

    fx.OnStart(
        func(a *Type1, b *Type2) {
            doSomething(a, b)
        },
    )
    

    This is a WIP implementation which implements the logic "outside" of fx, to start a discussion of whether this is what we want.

    There are some details to consider:

    • What happens if the graph has a context and the passed in function has a context Currently: If the first argument is a context, it's always the Start context. Any other argument as context is provided from the graph.
    • What is the source of the OnStart for errors? Today it'll be a generated function, but fx should probably skip these. We might want a t.Helper() to provide fx helpers that don't pollute the stack.

    This could also be implemented "internally" in fx, which would complicate the core framework but possibly provide better stacks/errors.

    See T2133659 for more details.

    opened by prashantv 21
  • Initial DIG implementation

    Initial DIG implementation

    Several things still to tidy up, but seems to be working to review.

    README.md is a good place to start and examples/dig/* to see how one might use it in a "real" application.

    TODO list:

    • [x] Thread safety
    • [x] Rebrand Inject to Register

    Other TODOs are now filed as issues.

    #282 #283 #284 #285

    opened by glibsm 21
  • Breaking the glass on the stack

    Breaking the glass on the stack

    Given a stack var Stack = fx.Options(A.Module, B.Module, C.Module)

    What options are available to the user to either mutate or provide a custom A.Module. Right now the only option is to copy-pasta the stack (and therefore forego and branch the tight default version).

    I'd like to think through being able to override one of the options, or ability to decorate the object right after it's creation before it's piped through the rest of the graph.

    Option A: Do nothing

    Declare this as SOL situation and have the service owner re-assemble the stack from the components.

    This has two downsides that jump out:

    • Versioning control has been transferred from the stack to the service. This can be solved by still importing the stack in the glide.yaml and picking up the right version
    • More importantly: additional default components that get added to the stack are no longer picked up, meaning every now and again the service author would have to manually peek to see what's going on in the stack and sync the changes.

    Option B: Override approach

    It could look something like:

    import "default/stack"
    import "fx"
    
    func main() {
      // MyA.Module and A.Module provide the same types
      fx.New(stack.Stack, MyA.Module).Run() 
    }
    

    And would require Fx to understand which option is providing which types.

    Option C: Decoration

    This could be a new option that functions very similar to Invoke, however to solve the siblings problem it gets executed first before the rest of the constructors.

    import "default/stack"
    import "fx"
    
    func main() {
      // <- A.Type is what's provided by A.Module
      fx.New(stack.Stack, fx.Decorate(func(a A.Type) { 
        a.mutate = true // ...
      }.Run()
    
    opened by glibsm 20
  • Module rewrite

    Module rewrite

    refactor 
    opened by bufdev 19
  • Update zap to latest commit on dev branch

    Update zap to latest commit on dev branch

    I was working on writing a new Module for another project that also uses zap, and I noticed that FX currently uses zap on master, which is way behind the latest zap development on dev. I think this was on purpose (ie I think the whole purpose of the master branch on zap is so that FX could develop against a stable zap API), but as you approach 1.0 for FX, I think getting the latest updates would be a really good idea, so that users of FX are using zap as it will be going forward.

    This also does a global glide update, but I think this is the only breaking change. It would be a good idea to audit the rest of the dependencies for updates before FX goes to 1.0 as well. If this is merged, it would be nice to just merge zap dev into master, and then have this depend on master again.

    A few notes:

    • This is a half hack job. I am just learning the workings of FX, and this should be a drop-in replacement, but I worked to get this just passing tests. This could use a fine-tooth comb by one of the FX maintainers, and I left some TODOs in the code as it is now.
    • I think LogBuilder could use some general work afterwards, but I know you're all pushing for 1.0 so this is for later.
    • Instead of using LogConfiguration, it might be nice to directly use zap's new configuration struct.
    • A general wish: I wish FX wasn't so tightly tied to zap, I wish we could have other logging libraries as well (and a lot of users will want this). It would be non-trivial but not too difficult to separate the tight coupling to zap.
    • This PR was a pain in the butt, and if you want to merge it, we should go over it NOW and get it in before this gets into rebase world. I'm happy to do a video chat to get this done quickly, or if someone else wants to take it over, go for it.

    @sectioneight @akshayjshah @glibsm @anuptalwalkar

    opened by bufdev 19
  • Sentry

    Sentry

    Adds sentry integration for ulog.

    Can be configured out-of-the-box with defaults by just providing a logging.sentry.dsn in config, or for those wanting more control there is a way for that too.

    opened by glibsm 18
  • Owner -> Manager

    Owner -> Manager

    opened by glibsm 18
  • Config using camelCase instead of underscore

    Config using camelCase instead of underscore

    For yaml files, it feels more natural to have:

    logging:
      text_formatter: true
    

    Instead of:

    logging:
      textFormatter: true
    

    With how the config reads yaml files right now, the latter will work, while the former will not, unless you have explicit yaml tags (right?). Could we make this magical to do either/or? I haven't looked into it at all, so it may take a change to the yaml library.

    Also something to note that you might want to use: https://github.com/peter-edge/pkg-go/blob/master/yaml/pkgyaml.go#L55

    What this allows me to do is to have either yaml or json files, and do the same thing. This also makes parsing work if there are only json tags without yaml tags, which gets REALLY useful when you have protobuf/thrift entities like

    message Config {
      bool stdout = 1;
    }
    

    And you can just have protobuf/thrift generate the structs, which (at least for protobuf) have json tags already, and then read them in using that function.

    opened by bufdev 18
  • Error when dig.In struct contains unexported fields

    Error when dig.In struct contains unexported fields

    It's very easy for users to make one of their params types have unexported fields which means it will silently have the default value.

    It seems reasonable to me to to say that a struct being used as a dig.In struct should not be used for anything else. This means that we can warn users if any fields are unexported and improve this silent rough edge users can easily hit.

    opened by bayesianmind 17
  • [Feature Request] OverrideSupply and OverrideProvide

    [Feature Request] OverrideSupply and OverrideProvide

    What

    Currently, the FX errors if you Provide/Supply for an unnamed/ungrouped type multiple times. However, there are use cases where overriding an existing Provide or Supply becomes useful, like in testing(#649). Also, this becomes useful for big applications with a liberal API allowing their users to override the default setup of modules. That is, the API devs prepare the default set of modules, while a user can swap out a module of their choice through overriding.

    Why

    Essentially, the feature would allow APIs like:

    some.New(Modules, WithModule(custom.Module))
    

    Currently, users have to decouple Modules, understand what needs to drop out, and pass their custom one. With this feature, users would add desired things on top.

    How

    API

    // OverrideSupply overwrites values passed to Supply and constructed with Provide.
    // It mimics Supply with one difference - it does not error if there are multiple instances of a type
    // are supplied/provided. Instead, OverrideSupply forces the Supply.
    // Only one override can happen for a type.
    func OverrideSupply(vals ...interface{}) Option
    
    // OverrideProvide mimics Provide with one difference - it does not error if there are multiple instances of a type
    // are provided or supplied. Instead, OverrideProvide forces the provide.
    // Only one override can happen for a type.
    func OverrideProvide(vals ...interface{}) Option
    

    Implementation ideas

    • A naive idea would be to collect all the overrides and exclude Provides and Supplies with conflicting types. However, the problem arises when provided ctor returns multiple types, and overriding happens for only one of them, as the whole ctor is excluded. The issue might be ok for some cases and easily detected, thus errored. The good thing is that this can be implemented beneath FX only, without digging into dig. Also, this should be fine enough for testing needs in #649.

    • A more thorough approach without the issue of the approach above would go dipper into dig and somehow be part of graph construction. Unfortunately, I am not that familiar with dig implementation to understand the complexity and feasibility, so kindly ask you to help. Ideally, the implementation should still execute a conflicting ctor but exclude an overridden type from the dependency graph.

    Happy to submit a patch once there is a decision on how to proceed.

    opened by Wondertan 3
  • Fix timeout report generation race

    Fix timeout report generation race

    When fx is run with a very short timeout, it's possible for the timeout error message to be in a bad format "OnStart hook added by failed" where the name of the OnStart hook's caller hasn't been recorded before the context times out.

    This fixes the error message generation to not rely on the OnStart hook's caller always being known to fix this race.

    Fixes #815

    opened by sywhang 1
  • Race in timeout failure report generation

    Race in timeout failure report generation

    When there is a timeout, we try to generate a timeout report by printing what timed out. There is a race in this logic which sometimes results in CI failures like this:

        --- FAIL: TestAppStart/Timeout (0.01s)
    9 app_test.go:905: 
    10 Error Trace:	app_test.go:905
    11 Error:      	"OnStart hook added by  failed: context deadline exceeded" does not contain "OnStart hook added by go.uber.org/fx_test.TestAppStart.func1.1 failed: context deadline exceeded"
    12 Test:       	TestAppStart/Timeout
    13 FAIL
    

    We can actually repro this pretty easily by changing the timeout in TestAppStart/Timeout to 1 nanosecond:

    context.WithTimeout(context.Background(), time.Nanosecond)
    
    fx ➤ make test                                                                                                                                                                                git:master*
    --- FAIL: TestAppStart (0.00s)
        --- FAIL: TestAppStart/Timeout (0.00s)
            app_test.go:905:
                    Error Trace:    app_test.go:905
                    Error:          "OnStart hook added by  failed: context deadline exceeded" does not contain "OnStart hook added by go.uber.org/fx_test.TestAppStart.func1.1 failed: context deadline exceeded"
                    Test:           TestAppStart/Timeout
    
    opened by sywhang 2
  • Support app shutdown with exit codes

    Support app shutdown with exit codes

    We provide a way to shutdown an app via the Shutdowner interface but, we do not provide a way to specify/change the exit code. This commit adds support for shutting down apps with an exit code. Exit code can be controlled by providing a new Option to configure the Shutdowner. This can be done via shutdowner.Shutdown(WithExitCode(...))

    • For apps that use app.Run(), the exit code is read directly and returned.
    • For apps that are orchestrated with app.Start() and app.Stop(), a new function app.DoneWithCode() is presented that works similar to app.Done(). The following code illustrats its usage -
    app := ...
    app.Start(...)
    done := app.DoneWithCode()
    res := <-done
    app.Stop(...)
    res.ExitCode // captures the exit code
    

    Refs: GO-981, #763

    opened by manjari25 2
  • How to organize error handling at OnStart hook properly?

    How to organize error handling at OnStart hook properly?

    If this hook is intended to call long-running goroutines like this, then why it waits for an error that never can be provided due to the locking nature of the call?

    We only can return nil there, otherwise, if try to return s.ListenAndServe(), then we get the start timeout.

    So, does fx assume to omit error handling here?

    opened by blank-teer 1
  • Question: Way to avoid boilerplate code for trivial constructors?

    Question: Way to avoid boilerplate code for trivial constructors?

    Hello 👋

    I have an service where we have to make a bunch of structs that have really trivial constructors. Namely, all they do is store the parameters wholesale. For example:

    type Foo struct {
        MyBar  Bar
        MyBaz  Baz
        MyQuux Quux
    }
    
    
    func NewFoo(mbr Bar, mbz Baz, mq Quux) Foo {
        return Foo{
            MyBar: mbr,
            MyBaz: mbz,
            MyQuux: mq,
        }
    }
    

    The Bar, Baz, and Quux are all fx.Provide'd elsewhere. I have a bunch of structs that look like this, that take various combinations of these dependencies.

    Is there a standard way of avoiding all this boilerplate?

    I did try this:

    
    type FooParams struct {
        fx.In
        Foo
    }
    type Foo struct {
        MyBar  Bar
        MyBaz  Baz
        MyQuux Quux
    }
    
    
    func NewFoo(fp FooParams) Foo {
        return fp.Foo
    }
    

    in the hopes that Fx would not see the Foo member and only see the MyBar, MyBaz, and MyQuux members embedded, but Fx was not tricked and declared that there was a circular dependency.

    opened by grantwwu 1
  • Shutdowner: provide option to communicate an exit code or even a value for fx.Run to return

    Shutdowner: provide option to communicate an exit code or even a value for fx.Run to return

    Shutdowner is a useful mechanism for willfully exiting applications, but it can be even better. To this end, the application channel can be upgraded to carry a value of type

    type SignalWithValue struct {
        Signal os.Signal
        ExitValue interface{}
    }
    

    The exit value can then be recovered from the App.Done channel value or from App.Run return value.

    This is mostly useful to set the application exit code to some value, but in a slightly more generic way than simply returning int.

    For a bit of context: Dotnet Core allows applications to set the eventual application exit code without actually exiting. This enables a pattern of the following sort:

    System.Environment.ExitCode = 0;
    // do things
    // bad things happen
    System.Environment.ExitCode = 255;
    // Perform an orderly shutdown
    (IHostApplicationLifetime).StopApplication();
    

    Thus, Dotnet Core can avoid passing any values to StopApplication, but we don't have such a luxury in Go.

    opened by oakad 2
  • Example of using fx for a short-lived CLI process?

    Example of using fx for a short-lived CLI process?

    All of the information/examples that I can find about how to use Fx in the "correct" way are centered around long-lived processes (HTTP servers and the like). I really like how my application is structured with Fx, but I'm not quite sure how to use it for e.g. a CLI application that should be running for < 1 second.

    For instance, is there any way to silence the log output entirely? Is there a way to default to not a long-running process?

    opened by cweagans 4
  • test issue - example_test relies on port 8080 being available

    test issue - example_test relies on port 8080 being available

    Not a major issue, but example_test relies on port 8080 being available, so when 8080 is being used by another process, it fails without much info:

    --- FAIL: Example (0.01s)
    got:
    Executing NewLogger.
    Executing NewMux.
    Executing NewHandler.
    Starting HTTP server.
    Stopping HTTP server.
    want:
    Executing NewLogger.
    Executing NewMux.
    Executing NewHandler.
    Starting HTTP server.
    Got a request.
    Stopping HTTP server.
    {"level":"info","ts":1624405878.099044,"msg":"providing","type":"fx_test.Username","constructor":"go.uber.org/fx_test.ExamplePopulate.func1()"}
    {"level":"info","ts":1624405878.099235,"msg":"providing","type":"fx.Lifecycle","constructor":"go.uber.org/fx.New.func1()"}
    {"level":"info","ts":1624405878.099299,"msg":"providing","type":"fx.Shutdowner","constructor":"go.uber.org/fx.(*App).shutdowner-fm()"}
    {"level":"info","ts":1624405878.099367,"msg":"providing","type":"fx.DotGraph","constructor":"go.uber.org/fx.(*App).dotGraph-fm()"}
    {"level":"info","ts":1624405878.0994182,"msg":"invoke","function":"reflect.makeFuncStub()"}
    {"level":"info","ts":1624405878.099509,"msg":"running"}
    FAIL
    FAIL	go.uber.org/fx	1.802s
    ok  	go.uber.org/fx/fxtest	(cached)
    ok  	go.uber.org/fx/internal/fxlog	(cached)
    ?   	go.uber.org/fx/internal/fxlog/foovendor	[no test files]
    ?   	go.uber.org/fx/internal/fxlog/sample.git	[no test files]
    ok  	go.uber.org/fx/internal/fxreflect	(cached)
    ok  	go.uber.org/fx/internal/lifecycle	(cached)
    ok  	go.uber.org/fx/internal/testutil	(cached)
    FAIL
    

    We should change the test to check if 8080 is available and pick a different port if it's not available.

    opened by sywhang 0
  • Make sure that constructor only creates one Dependency (and an optional error)

    Make sure that constructor only creates one Dependency (and an optional error)

    The ability to create several dependencies from a single constructor function is very useful, but it makes it very hard to replace a dependency during tests.

    func CreateDep() (dep.One, dep.Two, error) {...}
    

    Currently we maintain several dependency trees, one for production/main and others for tests. This is a manual process, where one needs to constantly remember to adjust trees when some dependencies change. I read in previous issues that there were attempts to replace dependencies in tests, but without any real progress on that. That's why I propose to limit the amount of dependencies one can produce from a single constructor. This will make it much easier to "ignore" a constructor function and "replace" it, impacting only 1 dependency. I know this is a breaking change and that's why I propose to include this as part of the major release.

    v2 
    opened by talgendler 3
Releases(v1.16.0)
  • v1.16.0(Dec 3, 2021)

    Added

    • Add the ability to provide a function as multiple interfaces at once using fx.As.

    Changed

    • fx.Annotate: support variadic functions, and feeding value groups into them.

    Fixed

    • Fix an issue where OnStop hooks weren't getting called on SIGINT on Windows.
    • Fix a data race between app.Done() and shutdown.
    Source code(tar.gz)
    Source code(zip)
  • v1.15.0(Nov 8, 2021)

    Added

    • Add fx.Annotate to allow users to provide parameter and result tags easily without having to create fx.In or fx.Out structs.
    • Add fx.As that allows users to annotate a constructor to provide its result type(s) as interface(s) that they implement instead of the types themselves.

    Fixed

    • Fix fxevent.Stopped not being logged when App.Stop is called.
    • Fix fxevent.Started or fxevent.Stopped not being logged when start or stop times out.
    Source code(tar.gz)
    Source code(zip)
  • v1.14.2(Aug 16, 2021)

    Changed

    • For fxevent console implementation: no longer log non-error case for fxevent.Invoke event, while for zap implementation, start logging fx.Invoking case without stack.
    Source code(tar.gz)
    Source code(zip)
  • v1.14.1(Aug 16, 2021)

    Changed

    • fxevent.Invoked was being logged at Error level even upon successful Invoke. This was changed to log at Info level when Invoke succeeded.
    Source code(tar.gz)
    Source code(zip)
  • v1.14.0(Aug 12, 2021)

    Added

    • Introduce the new fx.WithLogger option. Provide a constructor for fxevent.Logger objects with it to customize how Fx logs events.
    • Add new fxevent package that exposes events from Fx in a structured way. Use this to write custom logger implementations for use with the fx.WithLogger option.
    • Expose and log additional information when lifecycle hooks time out.

    Changed

    • Fx now emits structured JSON logs by default. These may be parsed and processed by log ingestion systems.
    • fxtest.Lifecycle now logs to the provided testing.TB instead of stderr.
    • fx.In and fx.Out are now type aliases instead of structs.
    Source code(tar.gz)
    Source code(zip)
  • v1.13.1(Aug 19, 2020)

  • v1.13.0(Jun 16, 2020)

    Added

    • Added fx.ValidateGraph which allows graph cycle validation and dependency correctness without running anything. This is useful if fx.Invoke has side effects, does I/O, etc.
    Source code(tar.gz)
    Source code(zip)
  • v1.12.0(Apr 9, 2020)

    Added

    • Added fx.Supply to provide externally created values to Fx containers without building anonymous constructors.

    Changed

    • Drop library dependency on development tools.
    Source code(tar.gz)
    Source code(zip)
  • v1.11.0(Apr 1, 2020)

    Added

    • Value groups can use the flatten option to indicate values in a slice should be provided individually rather than providing the slice itself. See package documentation for details.
    Source code(tar.gz)
    Source code(zip)
  • v1.10.0(Nov 20, 2019)

    Added

    • All fx.Options now include readable string representations.
    • Report stack traces when fx.Provide and fx.Invoke calls fail. This should make these errors more debuggable.

    Changed

    • Migrated to Go modules.
    Source code(tar.gz)
    Source code(zip)
  • v1.9.0(Jan 22, 2019)

    Added

    • Add the ability to shutdown Fx applications from inside the container. See the Shutdowner documentation for details.
    • Add fx.Annotated to allow users to provide named values without creating a new constructor.
    Source code(tar.gz)
    Source code(zip)
  • v1.8.0(Nov 6, 2018)

  • v1.7.1(Sep 26, 2018)

    Fixed

    • Make fxtest.New ensure that the app was created successfully. Previously, it would return the app (similar to fx.New, which expects the user to verify the error).
    • Update dig container to defer acyclic validation until after Invoke. Application startup time should improve proportional to the size of the dependency graph.
    • Fix a goroutine leak in fxtest.Lifecycle.
    Source code(tar.gz)
    Source code(zip)
  • v1.7.0(Aug 17, 2018)

    Added

    • Add fx.ErrorHook option to allow users to provide ErrorHandlers on invoke failures.
    • VisualizeError returns the visualization wrapped in the error if available.
    Source code(tar.gz)
    Source code(zip)
  • v1.6.0(Jun 12, 2018)

  • v1.5.0(Apr 14, 2018)

    Added

    • Add fx.StartTimeout and fx.StopTimeout to make configuring application start and stop timeouts easier.
    • Export the default start and stop timeout as fx.DefaultTimeout.

    Fixed

    • Make fxtest respect the application's start and stop timeouts.
    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Dec 8, 2017)

  • v1.3.0(Nov 28, 2017)

    • Improve readability of hook logging in addition to provide and invoke.
    • Fix bug which caused the OnStop for a lifecycle hook to be called even if it failed to start.
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Sep 6, 2017)

  • v1.1.0(Aug 22, 2017)

  • v1.0.0(Jul 31, 2017)

    First stable release: no breaking changes will be made in the 1.x series.

    • [Breaking] Rename fx.Inject to fx.Extract.
    • [Breaking] Rename fxtest.Must* to fxtest.Require*.
    • [Breaking] Remove fx.Timeout and fx.DefaultTimeout.
    • fx.Extract now supports fx.In tags on target structs.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc2(Jul 21, 2017)

    • [Breaking] Lifecycle hooks now take a context.
    • Add fx.In and fx.Out which exposes optional and named types. Modules should embed these types instead of relying on dig.In and dig.Out.
    • Add an Err method to retrieve the underlying errors during the dependency graph construction. The same error is also returned from Start.
    • Graph resolution now happens as part of fx.New, rather than at the beginning of app.Start. This allows inspection of the graph errors through app.Err() before the decision to start the app.
    • Add a Logger option, which allows users to send Fx's logs to different sink.
    • Add fxtest.App, which redirects log output to the user's testing.TB and provides some lifecycle helpers.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-beta3.1(Jul 5, 2017)

    Patch release to the widely adopted Beta3 version that updates the obsolete dependencies which have been causing problems, especially the logrus imports.

    This release is only intended to remove the immediate pressure to migrate to RC1, there is no current plan to support the "beta3 branch".

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc1(Jun 21, 2017)

    • [Breaking] Providing types into fx.App and invoking functions are now options passed during application construction. This makes users' interactions with modules and collections of modules identical.
    • [Breaking] TestLifecycle is now in a separate fxtest subpackage.
    • Add fx.Inject() to pull values from the container into a struct.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-beta4(Jun 12, 2017)

    • [Breaking] Monolithic framework, as released in initial betas, has been broken into smaller pieces as a result of recent advances in dig library. This is a radical departure from the previous direction, but it needed to be done for the long-term good of the project.
    • [Breaking] Module interface has been scoped all the way down to being a single dig constructor. This allows for very sophisticated module compositions. See go.uber.org/dig for more information on the constructors.
    • [Breaking] package config has been moved to its own repository. see go.uber.org/config for more information.
    • fx.Lifecycle has been added for modules to hook into the framework lifecycle events.
    • service.Host interface which composed a number of primitives together (configuration, metrics, tracing) has been deprecated in favor of fx.App.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-beta3(Mar 29, 2017)

    • [Breaking] Environment config provider was removed. If you were using environment variables to override YAML values, see config documentation for more information.
    • [Breaking] Simplify Provider interface: remove Scope method from the config.Provider interface, one can use either ScopedProvider and Value.Get() to access sub fields.
    • Add task.MustRegister convenience function which fails fast by panicking Note that this should only be used during app initialization, and is provided to avoid repetetive error checking for services which register many tasks.
    • Expose options on task module to disable execution. This will allow users to enqueue and consume tasks on different clusters.
    • [Breaking] Rename Backend interface Publish to Enqueue. Created a new ExecuteAsync method that will kick off workers to consume tasks and this is subsumed by module Start.
    • [Breaking] Rename package uhttp/client to uhttp/uhttpclient for clarity.
    • [Breaking] Rename PopulateStruct method in value to Populate. The method can now populate not only structs, but anything: slices, maps, builtin types and maps.
    • [Breaking] package dig has moved from go.uber.org/fx/dig to a new home at go.uber.org/dig.
    • [Breaking] Pass a tracer the uhttp/uhttpclient constructor explicitly, instead of using a global tracer. This will allow to use http client in parallel tests.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-beta1(Mar 10, 2017)

    This is the first beta release of the framework, where we invite users to start building services on it and provide us feedback. Warning we are not promising API compatibility between beta releases and the final 1.0.0 release. In fact, we expect our beta user feedback to require some changes to the way things work. Once we reach 1.0, we will provider proper version compatibility.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-beta2(Mar 10, 2017)

    • [Breaking] Remove ulog.Logger interface and expose *zap.Logger directly.
    • [Breaking] Upgrade zap to v1.0.0-rc.3 (now go.uber.org/zap, was github.com/uber-go/zap)
    • Remove now-unused config.IsDevelopmentEnv() helper to encourage better testing practices. Not a breaking change as nobody is using this func themselves according to our code search tool.
    • Log traceID and spanID in hex format to match Jaeger UI. Upgrade Jaeger to min version 2.1.0 and use jaeger's adapters for jaeger and tally initialization.
    • Tally now supports reporting histogram samples for a bucket. Upgrade Tally to 2.1.0
    • [Breaking] Rename modules/rpc to modules/yarpc
    • [Breaking] Make new module naming consistent yarpc.ThriftModule to yarpc.New, task.NewModule to task.New
    • [Breaking] Rename yarpc.CreateThriftServiceFunc to yarpc.ServiceCreateFunc as it is not thrift-specific.
    • Report version metrics for company-wide version usage information.
    • DIG constructors now support returning a tuple with the second argument being an error.
    Source code(tar.gz)
    Source code(zip)
Owner
Uber Go
Uber's open source software for Go development
Uber Go
A reflection based dependency injection toolkit for Go.

⚒️ dig A reflection based dependency injection toolkit for Go. Good for: Powering an application framework, e.g. Fx. Resolving the object graph during

Uber Go 2.3k Jan 15, 2022
An additive dependency injection container for Golang.

Alice Alice is an additive dependency injection container for Golang. Philosophy Design philosophy behind Alice: The application components should not

Minjie Zha 43 Sep 15, 2021
🛠 A full-featured dependency injection container for go programming language.

DI Dependency injection for Go programming language. Tutorial | Examples | Advanced features Dependency injection is one form of the broader technique

Goava 118 Jan 14, 2022
Simple Dependency Injection Container

?? gocontainer gocontainer - Dependency Injection Container ?? ABOUT Contributors: Rafał Lorenz Want to contribute ? Feel free to send pull requests!

Rafał Lorenz 14 Dec 10, 2020
Simple and yet powerful Dependency Injection for Go

goioc/di: Dependency Injection Why DI in Go? Why IoC at all? I've been using Dependency Injection in Java for nearly 10 years via Spring Framework. I'

Go IoC 140 Jan 15, 2022
Dependency Injection and Inversion of Control package

Linker Linker is Dependency Injection and Inversion of Control package. It supports the following features: Components registry Automatic dependency i

Logrange 32 May 6, 2021
Strict Runtime Dependency Injection for Golang

wire Wire is runtime depedency injection/wiring for golang. It's designed to be strict to avoid your go application running without proper dependency

Muhammad Surya 35 Dec 16, 2021
Compile-time dependency injection for Go

Dihedral Dihedral is a compile-time injection framework for Go. Getting started > go get -u github.com/dimes/dihedral Create a type you want injected

null 76 Sep 4, 2020
Compile-time Dependency Injection for Go

Wire: Automated Initialization in Go Wire is a code generation tool that automates connecting components using dependency injection. Dependencies betw

Google 7.3k Jan 23, 2022
Generated dependency injection containers in go (golang)

Generation of dependency injection containers for go programs (golang). Dingo is a code generator. It generates dependency injection containers based

null 68 Jan 20, 2022
A dependency injection library that is focused on clean API and flexibility

Dependency injection DI is a dependency injection library that is focused on clean API and flexibility. DI has two types of top-level abstractions: Co

Sergey Treinis 3 Dec 10, 2021
Golang PE injection on windows

GoPEInjection Golang PE injection on windows See: https://malwareunicorn.org/workshops/peinjection.html Based on Cryptowall's PE injection technique.

malwareunicorn 139 Dec 25, 2021
two scripts written in golang that will help you recognize dependency confusion.

two scripts written in golang that will help you recognize dependency confusion.

gv1_ 5 Oct 4, 2021
hiboot is a high performance web and cli application framework with dependency injection support

Hiboot - web/cli application framework About Hiboot is a cloud native web and cli application framework written in Go. Hiboot is not trying to reinven

hidevops.io 162 Jan 21, 2022
🦄🌈 YoyoGo is a simple, light and fast , dependency injection based micro-service framework written in Go.

???? YoyoGo is a simple, light and fast , dependency injection based micro-service framework written in Go. Support Nacos ,Consoul ,Etcd ,Eureka ,kubernetes.

YoyoFx 509 Jan 11, 2022
Go Dependency Injection Framework

Dingo Dependency injection for go Hello Dingo Dingo works very very similiar to Guice Basically one binds implementations/factories to interfaces, whi

Flamingo 120 Dec 30, 2021
Gerasimos (Makis) Maropoulos 21.7k Jan 21, 2022
A reflection based dependency injection toolkit for Go.

⚒️ dig A reflection based dependency injection toolkit for Go. Good for: Powering an application framework, e.g. Fx. Resolving the object graph during

Uber Go 2.3k Jan 15, 2022
How we can run unit tests in parallel mode with failpoint injection taking effect and without injection race

This is a simple demo to show how we can run unit tests in parallel mode with failpoint injection taking effect and without injection race. The basic

amyangfei 1 Oct 31, 2021
An additive dependency injection container for Golang.

Alice Alice is an additive dependency injection container for Golang. Philosophy Design philosophy behind Alice: The application components should not

Minjie Zha 43 Sep 15, 2021
🛠 A full-featured dependency injection container for go programming language.

DI Dependency injection for Go programming language. Tutorial | Examples | Advanced features Dependency injection is one form of the broader technique

Goava 118 Jan 14, 2022
Simple Dependency Injection Container

?? gocontainer gocontainer - Dependency Injection Container ?? ABOUT Contributors: Rafał Lorenz Want to contribute ? Feel free to send pull requests!

Rafał Lorenz 14 Dec 10, 2020
Simple and yet powerful Dependency Injection for Go

goioc/di: Dependency Injection Why DI in Go? Why IoC at all? I've been using Dependency Injection in Java for nearly 10 years via Spring Framework. I'

Go IoC 140 Jan 15, 2022
Dependency Injection and Inversion of Control package

Linker Linker is Dependency Injection and Inversion of Control package. It supports the following features: Components registry Automatic dependency i

Logrange 32 May 6, 2021
Strict Runtime Dependency Injection for Golang

wire Wire is runtime depedency injection/wiring for golang. It's designed to be strict to avoid your go application running without proper dependency

Muhammad Surya 35 Dec 16, 2021
Minimalistic, pluggable Golang evloop/timer handler with dependency-injection

Anagent Minimalistic, pluggable Golang evloop/timer handler with dependency-injection - based on codegangsta/inject - go-macaron/inject and chuckpresl

Ettore Di Giacinto 13 Jun 22, 2021
Compile-time dependency injection for Go

Dihedral Dihedral is a compile-time injection framework for Go. Getting started > go get -u github.com/dimes/dihedral Create a type you want injected

null 76 Sep 4, 2020
Compile-time Dependency Injection for Go

Wire: Automated Initialization in Go Wire is a code generation tool that automates connecting components using dependency injection. Dependencies betw

Google 7.3k Jan 23, 2022
Generated dependency injection containers in go (golang)

Generation of dependency injection containers for go programs (golang). Dingo is a code generator. It generates dependency injection containers based

null 68 Jan 20, 2022