|
|
@@ -0,0 +1,46 @@
|
|
|
+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).
|
|
|
+
|
Torkel Ödegaard