Hi folks, At Square, we have a collection of shared frameworks and library code, loosely referred to as the “service container” in each language. For example, our framework code in Go includes:
- a lightweight "module" system for dependency injection - config: a way of layering yaml files named for environments. For instance, common.yaml gets loaded first, and production.yaml shadows over it, and production-east-coast.yaml gets applied last. - logging: code for sending log lines over kafka to our logging aggregator - networking: our stubby-alike protobuf RPC mechanism, naming and discovery, etc. Gradually migrating to "just use grpc and envoy" - datasource config: a convention for configuring database sources via the yaml configs People probably also think of our service container as including slightly less core things too: - sharded jobqueues - feature flags (backed by zookeeper) - cron jobs (again configurable via yaml) This stuff has gone a while with less-than-generous attention and upkeep, and the extent of Square-specific code makes it more difficult for new developers to come up to speed. What I'm trying to figure out is: what are folks at other companies using to create a shared set of conventions and out-of-the-box setup for their Go applications? We can knock some pieces out one by one (eg. replace our Module system with Wire), but it would be nice to find an existing lightweight “service container” that other companies are using. I suppose my main question is this: is the kind of flexibility required for a shared, open-source “service container” antithetical to the kind of simple, opinionated, internal-convention-obeying “service container” you'd want for your company? To put it another way, it has never felt like using gokit would be appropriate, because it obeys none of our conventions. Thoughts, comments, experience to relate? Yours, Zellyn -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
