Skip to content

Latest commit

 

History

History
30 lines (24 loc) · 3.81 KB

tech_stack.md

File metadata and controls

30 lines (24 loc) · 3.81 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 built up 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 want to contribute a brand new CLI or need to make significant changes to the old kingpin.v2-based 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?