Killing PHP Took a Year and a Half
We’ve recently closed Series A funding and are interviewing developers who’d like to work with us on our new code-base towards our goal of furthering classroom equity.
Kiddom used to be very different. We changed in response to teacher feedback, quickly creating the product for which we’re known today.
Kiddom originally made standards-aligned iPad games for younger students.
The games hit a sweet spot with teachers, and we rushed to develop new features they requested as they pulled us into their classrooms. Our architecture grew organically (i.e. bloated), until we found ourselves unnerved by the monstrous system supporting our growing user base.
In every state, teachers were trusting and relying on us with their classrooms, but the code propping it all up was not aging well. We had to change it without interrupting their service.
This month, we resolved the last of our technical debt that resulted from how quickly we pivoted and expanded our offering (it’s awesome).
Most startups struggle and eventually die trying to find product-market fit. We had the opposite problem: having hacked solutions however we could to satisfy the needs of a voracious and traditionally under-served user-base, we’d accidentally created a monster we now hated working on.
Our monolithic PHP, jQuery, Vanilla JS beast worked… but just barely. Having paid off our technical debt, we’re now thrilled to share the priorities we followed and decisions we made.
Frontend: single-page architecture, Webpack, host on S3 with multi-zone redundancy.
Along the way, we were affected by several infrastructure level system outages (Feb 2017, Oct 2017) that affected most of the web. Our teachers understood, but we wanted a way to weather these incidents safely on their behalf.
Webpack allows us to upload a compiled app to S3, which we configure with multi-zone redundancy (and failover DNS) for survivability.
It loads fast (now under 3s, was 8). Navigates instantly. Allows us to code with the newest, most fun es6 and es7 tools, and should be hard to kill (as of writing this, we’re still migrating to S3. Currently on Heroku).
Backend: Proper RESTful API, and GoLang … as a recruiting tool?
Our PHP API was built to prioritize “1 endpoint per screen.” This helps mobile apps for whom network requests are more costly, but was impossible to grow as we wanted. We’ve since prioritized RESTful design.
We’d chosen Go to replace PHP for its typed interface and first class support for testing that we felt would help write more reliable code.
We also knew Go was rare, and a significant influence on our decision was the assumption it could serve as a forcing function for filtering new hires. We thought:
- Folks who knew Go already were curious and actively learning.
- Folks who didn’t would join knowing they were expected to learn it, and thus would only be willing to join if they were open to the same.
These are qualities our growing engineering team values.
Tests. Tests everywhere.
We aren’t 100% TDD, but we are dang close.
Today, we monitor code coverage, won’t merge changes that bring it down, and lobbied Kiddom’s non-engineering teams to recognize time spent writing tests as part of the time required to build any new feature.
Better organized code resists bugs, and allows faster development of new features.
Using SCSS, including its advanced features
Our styles follow a BEM pattern to isolate rules and keep rendering performant on mobile. Pretty standard. Artur is writing a more detailed analysis of our styles.
But the source code itself makes heavy use of variables, modules, mix-ins and extensions. It’s the nicest CSS I’ve ever touched.
All this to benefit the teachers and learners using our app.
Teachers that stuck with us, despite bugs and sometimes slow external progress, are about to be rewarded. Our code is more stable than ever. Bugs are rarer, and get fixed faster. We’ll be building new features faster, supporting more complex workflows with confidence, and iterating faster than ever before.
What’s next: it takes a village.
We built stable code so we could ship a redesigned app that gives students unprecedented access to (and ownership of) their own data and progress (more on why student ownership matters). But teachers and students aren’t the only members of the school community. How might the entire village, along with teachers and learners, use Kiddom? How does everyone collaborate for the sake of bettering student outcomes? How might Kiddom best support these processes? We believe the best is yet to come.
We’ve recently closed Series A funding and are interviewing developers who’d like to work with us on our new code-base toward our goal of furthering classroom equity.
