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.