From d8d5516e24484f8b12abd473822af894736e5863 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torkel=20=C3=96degaard?= Date: Wed, 26 Nov 2014 12:57:16 +0100 Subject: [PATCH] Create README.md --- README.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 00000000000..02cae2bb0e9 --- /dev/null +++ b/README.md @@ -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). +