Having analytics-related code on the backend side gives you more flexibility than having them on the mobile side.
Let me show you why it’s true and how to quickly migrate your analytics code to the backend side.
It is hard to synchronise, develop and maintain analytics related code, especially during the ongoing development on multiple platforms. iOS, Android, Web… with its own implementation, developed by different developers can generate different results. Cost of adding another measure is multiplied by number of clients you have in the system. What’s more analytics related code can shadow business implementation, which is very undesirable. Finally it just makes sense to have them on the backend since it is part of the whole system, not client app only.
So one day an idea came to my mind. What if we use the information already present in our database for most analytics? If I miss some information, I can add it very easily during the feature implementation on the backend. Then we could extract all the necessary data using plain SQL, which is much faster and more powerful than writing custom code and endpoints for this. metrics very easily by modifying the front-end panel only. This is what I did.
- It does not require the entire team to measure a new feature. Adding a few statistics takes one developer only a few hours. It is very rare case when we need to store some additional information in the database.
- Because adding of new statistics is easy, it became natural for the team to plan it as a part of the sprint. “How we can measure the impact?” became one of the questions asked during feature design.
- Shorter feedback loop. Since the team builds statistics for most of the key features we are able to discuss feature impact with the Client based on the data we see. We are also able to better understand what we can improve very quickly.
- Metrics are more centralised so we make less mistakes while implementing them.
- We learn about the system more with every new metric.
After small research I found really interesting tool called cube.js . Why does it fit my needs?
* It does not mess with the backend code because it has a direct read-only connection to the production database*
* It is a self-hosted tool with little maintenance required. Easy to setup on Google Cloud.
* It has two separate modules, one for database connection and other for fronted which allows me to integrate it directly with the existing admin panel
* It supports a few most post popular charts frameworks
* Its front-end framework supports socket connection, so you will see data updates in real time
* It has a built-in caching system, which helps you avoid unnecessary load of database
After a really quick setup I’m able to interact with the database using the Cube.js framework. The good thing is that you can use plain SQL or predefined queries to build your own data sets. So as I mentioned before combining this with the one of the chart frameworks gives you possibility to develop metrics at the speed of light.
*In my case it connects to the database replica which is automatically synchronised thanks to Google Cloud replication mechanism
Originally published at https://www.bernad.co on May 22, 2020.