mirror of
https://github.com/grafana/grafana.git
synced 2025-02-15 10:03:33 -06:00
47 lines
3.0 KiB
Markdown
47 lines
3.0 KiB
Markdown
|
grafana-pro
|
||
|
|
===========
|
||
|
|
|
||
|
|
This is very much a Work in Progess. The architecture and organisation has changed many times and I am not very happy
|
||
|
|
with the current structure and architecture. I started with a lot of unit tests and drove the design though that in
|
||
|
|
the begining, but then having changed the code and structure (and web framework libs, and database) I sort of
|
||
|
|
abandoned them. When the architecture is getting more stable I will write & require more unit & integration tests.
|
||
|
|
|
||
|
|
# Architecture
|
||
|
|
I have researched a lot of go projects, found very few with a nice modular & loosly coupled archictecture. Go projects
|
||
|
|
organize code very differently, some treat packages as global singletons (which reads nicely and is nice to work with
|
||
|
|
but seems like a bad practice). I do miss generics for doing strongly typed but loosley coupled command/query style
|
||
|
|
internal buss messaging.
|
||
|
|
|
||
|
|
The biggest challange for architecture is making Grafana Pro very modular in a way that all/most components can
|
||
|
|
run inproc or in seperate process (usefull when running Grafana Pro in a large scale SaaS setup). Been investigating
|
||
|
|
using ZeroMQ or NanoMsg to handle module communication (Both ZeroMQ and NanoMsg can handle inproc & tcp which a number of
|
||
|
|
different topologies). Running Grafana Pro in a SaaS setup might warrant that the alerting stuff runs out of proc on
|
||
|
|
other servers feeding of a queue for example, but for simple on prem stuff it would be cool if that could be run in the
|
||
|
|
same process. I am also thinking that some stuff might need swapping out/in depending on the setup (plugin model or just
|
||
|
|
interfaces with different implementations).
|
||
|
|
|
||
|
|
# Building
|
||
|
|
* Just added a simple make file (the main binary package is in pkg/cmd/grafana-pro)
|
||
|
|
* Need to change to godep or some go lang dependency management system
|
||
|
|
|
||
|
|
# Data access
|
||
|
|
Data access is very strange right now, instead of an interface I tried using public methods in the models package.
|
||
|
|
These method pointers are assigned in when the sqlstore is initialized in pkg/store/sqlstore. This is probably a
|
||
|
|
bad idea. I am thinking about either moving to simple interfaces. But I do not want a giant interface for all
|
||
|
|
data acess. Would much prefe a simple generic command/query interface but golang lacks generics which makes this
|
||
|
|
painful. But a generic command/query interface could still be good as it would make it easier to have some commands or
|
||
|
|
queries handled buy out of proc components (or inproc if we used someting like ZeroMQ for communication). Or it
|
||
|
|
could be overengineering thinking like this.
|
||
|
|
|
||
|
|
# Grafana frontend
|
||
|
|
The grafana frontend is added as git submodule in order to easily sync with upstream grafana.
|
||
|
|
There should be a symbolic link from ./grafana/src to ./public . Need to add this to the Makefile.
|
||
|
|
|
||
|
|
# TODO
|
||
|
|
* Add symbolik link between ./grafana/src ./public
|
||
|
|
* Hash & Salt password
|
||
|
|
* Unit tests for data access
|
||
|
|
* I switched recently from rethinkdb to sql (using a simple mini ORM lib called xorm, might need to switch to a more
|
||
|
|
popular ORM lib).
|
||
|
|
|