gliderlabs/com

Library for structuring Golang applications into components

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

com's Issues

config/viper: tests will fail until Viper is fixed

Viper's pluggable filesystem interface is ignored in a critical spot. A PR was submitted to fix it. This issue is to track the PR.

PR: spf13/viper#405
Issue: spf13/viper#404

What else for 1.0?

Besides stable APIs, solid docs, and more test coverage ... what else should we focus on for a 1.0 release? Also, where can the docs be improved? Where are there questionable API choices?

I'm putting a deadline of Feb 1 on the 1.0 milestone. That gives a timeline constraint. Hopefully we use it enough in that time to know what a solid 1.0 API looks like.