Skip to content

Latest commit

 

History

History
30 lines (24 loc) · 3.78 KB

tech_stack.md

File metadata and controls

30 lines (24 loc) · 3.78 KB
Raw

Tech stack

Currently, our development team has fewer people than components/repositories. It is important for us to use shared libraries and tools to make our life easier. It's also fine to bring in new ones if there is a reason, but that reason should be more appealing than just "let's try this new cool package" or "that's an overengineering". Also, if we decide to make a change in this list, it's better to change it in all components within a reasonable timeframe.

Our technology stack

  • protobuf v3 gives us strongly-typed serialization format with good forward- and backward-compatibility, canonical mapping to and from JSON, and a large ecosystem of libraries and tools. We don't have to write code to work with it because there are code generators for a lot of languages.
  • gRPC extends protobuf with RPC mechanism. Both single requests/responses and bi-directional streams are supported. Error handling is built-in. Again, there are code generators for both client- and server-side code, so we don't have to write it by ourselves.
  • grpc-gateway takes gRPC specification and generates code for HTTP JSON API server-side wrapper for it. It also generates Swagger specification from protocol specification and annotations, with documentation from comments. In turn, it is used to generate client-side code for environments where gRPC is not yet supported natively (e.g. web browser). No manual writing of serialization and communication code, and documentation with examples and interactive tools – gRPC specification becomes the single source of truth.
  • logrus or stdlib log package should be used for logging. Always log to unbuffered stderr, let process supervisor do the rest.
  • prometheus client is used for exposing internal metrics of application and gRPC library.
  • testify or stdlib testing package should be used for writing tests. Testify should be used only for assert and require packages – suites here have some problems with logging and parallel tests. Common setups and teardowns should be implemented with testing subtests.
  • golangci-lint is used for static code checks.
  • gocov.io and gocoverutil gather code coverage metrics.
  • Docker Compose is used for a local development environment and in CI.
  • Kong for pmm CLI and kingpin.v2 for exporters and some other code. Use Kong if you need some new CLI or need to make significant changes to the old kingpin.v2 CLI.
  • go modules for vendoring.

Open questions

  • Do we need something else for tracing?
  • Do we need something for integration tests? Something like https://github.com/go-gophers/gophers?
  • Configuration library? Files, flags, environment variables?
  • Build system:
    • Use promu so we don't have to copy&paste Makefiles everywhere? It also has a nice cross-build functionality, it can build containers, it has license checking tools.
    • Consider Go Releaser?