Create README.md

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). 
+