Skip to content
averasko edited this page Apr 24, 2014 · 21 revisions

Already aware of what is ACRA ?

Alright then, here's what you might be looking for:

Every enhancement idea is welcome. Pull requests are appreciated too.

What is Acralyzer

Acralyzer is a project aiming at offering a free, independent, open source backend for ACRA reports.

ACRA is a lightweight open source library enabling Android applications to send detailed crash reports to a number of free backends with the help of provided generic senders or custom made ones.

Lots of android developer start with ACRA and the default Google Doc spreadsheet because the solution is free, reliable, and does not require any technical knowledge to setup.

The inconvenience is that the spreadsheet user interface is not ideal for analytics needs and tends to become slow as hell when thousands of reports are stored. Moreover, when a spreadsheet reaches its limit (a bit more than 11000 reports), it can't be opened anymore.

In addition, Google teams are now asking ACRA users to stop using Google Forms for automatic crash reporting. Not only because it is a hack, but also because a new 'refreshed' version of Google Forms has been launched and ACRA won't be able to post reports on these forms anymore.

Third party backend have been developed, offer rich user interfaces with free plans. There really are nice solutions... but, they are not open source, not independent, and can't be self hosted.

First version goal

Acralyzer is the project started by ACRA's creator, Kevin Gaudin, to define and implement a backend with these constraints:

  • free and open source
  • self hostable to keep your crash data private
  • secure
  • simple to install and deploy
  • scalable (should be able to handle very large numbers of reports)
  • provide features to sort, search, filter and visualize reports and stats

This Wiki is proposed to the ACRA users community as a place to define and prioritize the features that should be implemented in this backend. It is open to your contributions to help create the app that fits your needs.

As a starter, let's define the first set of features that an early version of Acralyzer should provide. This would be the list of feature that would let you get rid of the GoogleDoc spreadsheet without losing any convenience in your daily work to enhance YOUR android app. Please create feature requests in the issue tracker for each idea.

Proposed architecture

After examining various technical options, here is a first architecture proposal

Storage engine: CouchDB

ACRA reports contain lots of data. Most of them are key/value pairs, and the structure of a report can vary from one app developer to another. Given this nature, it looks obvious that a NoSQL storage engine could be the best fit for our needs.

Apache CouchDB™ is a database that uses JSON for documents, JavaScript for MapReduce queries, and regular HTTP for an API

Among many NoSQL solutions, the selection of CouchDB as the storage engine is based on:

  • its native HTTP RESTFull API: storing data (a report) in CouchDB is as simple as sending an HTTP PUT request with a JSON body
  • its scalable nature: CouchDB is designed to handle many concurrent requests and can easily be deployed on clustered servers
  • its opened source and Apache Software License. This means that there is no ties with a single (cloud) hosting service. You can deploy it on your own server(s) if you want to control your data.
  • its ability to serve apps (CouchApps, see below)

Application server... CouchDB (CouchApp)

CouchDB is able to store and serve static files, enabling the creation of html + JavaScript web applications called CouchApps.

Thanks to the full regular HTTP API, the CouchDB code footprint is very low. We can code a webapp retrieving data with simple ajax GET requests, moving to a different storage engine would only require to modify the URLs of these requests and the users management code.

As CouchDB is serving both data and webapp... there are no same domain policy issues with browsers, there are no need for a server side bridge between the webapp and the data repository.

Server-side code only consists of:

  • a set of Map/Reduce javascript functions (most of them are REALLY simple)
  • a validation function executed on each report creation to check authentication and normalize some data

WebApp: AngularJS + d3js

AngularJS is a trendy JavaScript framework developed by Googlers with a really interesting design. It aims at extending HTML to make it the dynamic application templating language it should have been.

Its 2-way data binding and extensibility are the 2 main features leading to its selection.

D3.js (Data-Driven Documents) is JavaScript library designed to manipulate and visualize data sets. Each crash report contain lots of data and the aggregation of stats about all crash reports for an application can give a great insight of the evolution of your application quality. Visualizing both data about single reports and global stats could be helped by D3.js.

Wrapping it up

With this architecture, we can build a tool which:

  • can be hosted anywhere, including some CouchDB dedicated hosting services like IrisCouch or Cloudant which have free plans depending on your usage (API calls and data storage volume).
  • can be hosted anywhere, including your own servers if having full control of your data and service is important to you.
  • depends on a single server component, CouchDB, which is an Apache Software Foundation project, open sourced, documented, efficient and reliable.
  • is simple to deploy, with the help of couchapp tools like Erica.
  • offers a frontend built with standard HTML+JS components, using cutting-edge framework and visualization libraries.
  • is not subject to any vendor locking.