In 2010 I put a game online. Triviosity, a daily trivia game with occasional specially crafted challenges, has been online for over 8 year. It’s a game that people play on a regular basis and it’s always held a piece of my heart. When I originally wrote it I had full intent to make it a mobile app. An iOS app specifically. The original was built with Zend Framework 1, had a clunky API back-end with intent for the mobile app, and quite frankly it was rock solid. It ran without issues. Unfortunately the iOS app never happened, and as other frameworks and tools blossomed, ZF1 became outdated and not worth the time to build upon it.
On thanksgiving weekend in October 2017 I decided it was time to rewrite my old game. It was time to switch up the technology and actually make the mobile app. At first glance I thought it was going to be a very daunting task. Switching from ZF1 to Laravel 5.5 seemed like it was going to be a huge undertaking. But it wasn’t. My data models from the original game were so awesome that porting the “beef” of it (I like to work with fat models) only took me a few days.
I sat on that small victory for months. Enter the void of hesitation. Was it too easy? Was I going about it all wrong? Was I doing this the right way? Is anyone new even going to play this rewrite?
If there’s one thing I absolutely detest it’s doing something over. I had to do this, but I hated doing this. There was a necessary evil at play – I want to build the new mobile apps. But I need to redo the old game to get there.
Then I got rolling. I don’t know what changed. I got about 90% complete then I stopped.
Who’s going to play this thing? Why am I doing this? Question, doubt, rinse, repeat.
Then the tidal wave hit. Frack it. “I’m putting this live.” It’s “good enough” and I can fix the missing parts. As a matter of fact, once I put it live, my desire to finish it and make it better went up exponentially.
On July 30, 2018 the unscheduled launch of the new Triviosity happened. A few hundred error emails later, and a bunch of random fixes, the dust had settled. And it’s alive.
There are two things that take precedence in my work. Security and Performance. Without going into too much detail about security (I can’t give away all my secrets) the new API includes request signing, encryption, and wonderful third party oAuth based authentication.
For performance, It was critical that I make this as fast as I possibly can while still leveraging my old (affordable) web servers. After launching you can see a substantial drop in load times and render times. (This isn’t just the home page either, it’s all pages.)
The kicker was simple. Use the tool-set you have properly. As I mentioned, this was being built with Laravel 5.5 (and upgraded to 5.6 before my actual launch). As such, there’s one hell of a generally under-utilized tool-set available to me to use. So here’s a simplified rundown:
- Cache – Cache all the things you can. Cache your config files, routes, database queries. There are pages (score listings) that have a substantial amount of queries of data that doesn’t change often. Caching this turned render time from 500ms to 100ms.
- Compile / Minify CSS and JS – Laravel has a webpack config that utilizes a basic Laravel Mix out of the box. It has many nifty plugins to do everything you need. I only really needed the sass compiler, minifier, and JS minifier. This task is often overlooked and it yields some of the greatest performance boosts. The production build tool is A+.
- Offload to the Queue! – Using an asynchronous queue to handle things that don’t need to happen for the end user to continue is also a huge boost to performance. Things that can happen in the background: big database updates, sending emails, generating images – all done without the user feeling the slightest bit of a slowdown.
- Use the F’ing Framework – Far too often (I’m guilty of this too) I see code that “uses” a framework, but then it doesn’t actually use the framework. Laravel and it’s dependencies have been built up over the years to do a lot of the repetitious work. If I told you the code for the game controller was only 230 lines, you probably wouldn’t believe me. I leverage the framework’s models and view renderer to do the majority of the work. For reference, the old game play code was almost 1000 lines. Less code, same game, more efficient.
- Ditch The Cruft – I don’t use any external third party JS on this site with the exception of Google Analytics and Google AdSense (non blocking). Facebook, Google, and Twitter authentication is completely via server side redirects. The share buttons are just good old fashioned native links (which, as a bonus, launch the native apps on most mobile devices).
This is how you get a double A’s on speed tests.
Now that I have successfully released the best performing site of my life, I can finally work on the native mobile apps. I have no direct timeline for these. I’ll be building them as 100% native apps (Swift for iOS and Kotlin for Android) and not using some goofy cross-platform build tool so that will have some affect on the time frame. But they’ll be fast. They’ll be secure. They’ll be just as awesome and performance ready as the site itself.
Now with an even more rock-solid foundation I can build on this. We can all expect more curated challenges with great features.
It took me about 10 months to complete the rewrite. But in reality only 40 days. It kicks ass. It’s fast. It’s great. The mobile versions are coming soon.
Now go play some Triviosity. And let me know if you break something.