Zerista Dev – Server

Development of the Zerista server started in the summer of 2006, two years before Zerista even existed! My original idea was to create a social mapping platform – looking back what I was aiming for was NextDoor. But that wasn’t quite so clear at the time, and our first customers were in the event business so we pivoted and Zerista was born.

Zerista’s backend is written in Ruby on Rails. Over time, as the app grew, I noticed when we onboarded new developers they tended to be overwhelmed by the size of the code base. Part of that was we tended to hire younger, less experienced developers. But part of it was we ended up with a pretty good sized app. One of the things we discovered about the events industry is you end up reimplementing a min-social network plus lots of other features. For example, we had messaging, meetings, recommendations, posts, sessions, exhibitors (ie.e, companies), attendees, schedule building, meeting scheduling, games (scan a QR code get a prize), campaigns/ads, banners, etc., etc., etc. In some ways, Zerista was LinkedIn+ for events.

To give an idea of the size of that app, here are source code statistics:

───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments    Code Complexity
───────────────────────────────────────────────────────────────────────────────
Ruby                      2980    215970    35777     10081   170112       8218
JavaScript                 445    123609    10055      9425   104129       7398
HTML                       308     32816      266        38    32512          0
YAML                       225    150464    24227       895   125342          0
Sass                       213     36741     3630      3825    29286         72
XML                        143     20996      327        12    20657          0
CSV                        130      5147      197         0     4950          0
TypeScript                  99      5594      666        30     4898        463
SQL                         79      6110      867       353     4890         67
CSS                         66      7606      954       582     6070          0
JSON                        20      1861        0         0     1861          0
SVG                         19      1852        0         7     1845          0
gitignore                   16       127        8         0      119          0
Plain Text                   9      1669      299         0     1370          0
Extensible Styleshe…         4       205       24         0      181          0
Rakefile                     4        36        5         3       28          0
Gemfile                      3       116       10         9       97          0
Batch                        2         5        1         0        4          0
Ruby HTML                    2        41       10         2       29          5
PHP                          1         8        0         0        8          0
Patch                        1        43        5         0       38          0
Python                       1        41        4         3       34          4
───────────────────────────────────────────────────────────────────────────────
Total                     4770    611057    77332     25265   508460      16227
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop $18,757,068
Estimated Schedule Effort 46.740512 months
Estimated People Required 47.536385
Estimated Years: 180
───────────────────────────────────────────────────────────────────────────────
* Statistics generated by scc (cost estimates are based on the COCOMO model so consider them wildly inaccurate)

The Zerista server ended up about three hundred thousand lines of code (the YAML files were test data) and counting. Assuredly that’s small compared to Airbnb, Github, or some other large Rails apps but I don’t know of any publicly available data for them.  But its actually not that much smaller than Shopify, Cookpad (a large Japanese website, roughly the 250th biggest website in world by traffic) and about 1/3rd the size of GitLab (which is open source so easy to measure).

And that was all done by a small team that ranged from 3 to 6 developers, but with 3 core developers among them (including myself).

Sometimes I’m asked why we didn’t split the application into microservices. The answer to that is easy – there wasn’t any business benefit to doing so and there wasn’t enough technical benefit to do so. We spent a lot of effort keeping the app in good shape:

  • We had almost 30,000 automated tests
  • The tests covered roughly 85% of the code base
  • We were always within 1 version of the latest Rails release (and in fact moved to Rails 6 over the summer)
  • We started introducing the idea of a modular monolith as time went on
  • We consistently dedicated time to reducing technical debt
  • We would not compromise the quality of the code base by doing one-offs hacks for specific customers (you rarely get back to fixing your hacks and then you have to find ways to live with them over time)

The bottom line – ten years in we still had a good foundation for continued development and maintainability.

Having said that, every year we spent time discussing how we could split the app into microservices. And with the adoption of recent privacy laws, such GDPR, there started to become a good business reason to do so. Some of Zerista’s European customers, particularly in Germany, wanted to make sure their data was stored in the EU. So that leads to splitting out user authentication (and authorization) into its own service that can be hosted in the EU while other parts of the app could be hosted in different geographic regions (preferably close to where a conference is taking place).

To wrap up – I’m proud of what a small, but dedicated, team was able to build.

Leave a Reply

Your email address will not be published.

Top