apitech
/
grafana
mirror of https://github.com/grafana/grafana
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
The open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
31748 Commits
5979 Branches
596 Tags
1.7 GiB
 
 
 
 
 
 
Tag: Branch: Tree: 37cbed4b48
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '37cbed4b48'
${ noResults }
grafana/contribute/architecture/backend/package-hierarchy.md

877 B
Raw Blame History

Package hierarchy

The Go package hierarchy in Grafana should be organized logically (Ben Johnson's article served as inspiration), according to the following principles:

  • Domain types and interfaces should be in "root" packages (not necessarily at the very top, of the hierarchy, but logical roots)
  • Sub-packages should depend on roots - sub-packages here typically contain implementations, for example of services

Practical example

The pkg/plugins package contains plugin domain types, for example DataPlugin, and also interfaces such as RequestHandler. Then you have the pkg/plugins/managers subpackage, which contains concrete implementations such as the service PluginManager. The subpackage pkg/plugins/backendplugin/coreplugin contains plugins.DataPlugin implementations.