README
¶
gliderlabs/com
A component-oriented approach to building Golang applications
Concept
We want to see a world with great "building blocks" where you can quickly build whatever you want. Traditional "composability" is not enough, they need to integrate and hook into each other.
This library provides the core mechanisms needed to build out a modular and extensible component architecture for your application, which also extend into an ecosystem of "drop-in" reusable components.
There are two parts to this package that are designed to work with each other:
- An object registry for interface-based extension points and dependency injection
- A configuration API for settings, disabling objects, and picking interface backends
Example application
See the example wiki app repo.
After building out reusable components, a simple wiki with GitHub authentication could be put together in ~200 lines of Go as a single component.
Using com
For now, see GoDocs, the example application, and the components in stdcom.
Dependencies
Good libraries should have minimal dependencies. Here are the ones com uses and for what:
- github.com/spf13/afero (plugins, config tests)
- github.com/spf13/viper (config, config/viper)
License
BSD
Documentation
¶
Overview ¶
Package com is a user-facing interface to the object registry. Since the only part of the API you need to use is Register, the rest of the API for interacting with an object registry is in its own subpackage. This is used by other tooling built around com, for example the config subpackage.
When you register an object, it will populate fields based on the com struct tags used on them. The object will then also be used to populate fields of other objects in the registry where the type or interface matches.
type Component struct {
Log log.Logger `com:"singleton"`
Handlers []api.Handlers `com:"extpoint"`
DB api.Store `com:"config"`
}
In the above example component, it has fields with all three possible struct tags:
Singleton will pick the first object in the registry that implements that interface. You can also use pointers to concrete types, for example to other component types.
Extpoint is going to be a slice of all objects in the registry that implement that interface.
Config is not populated, but is allowed to be populated via the registry API. If you're using the config package, it will do this for you and populate it based on configuration. In this case, the key would be "DB" and the value could be the name of any registered component that implements api.Store.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ( // DefaultRegistry is often used as the single top level registry for an app. DefaultRegistry = &objects.Registry{} )
Functions ¶
Types ¶
This section is empty.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
Package config does 3 things: 1.
|
Package config does 3 things: 1. |
|
viper
Package viper provides a config.Provider based on the Viper configuration library.
|
Package viper provides a config.Provider based on the Viper configuration library. |
|
Package plugins allows dynamic Go plugins to provide objects to a registry.
|
Package plugins allows dynamic Go plugins to provide objects to a registry. |