How we built a product public servants might want to pay for
From customising WordPress to node.js APIs — under the hood of Apolitical Plus+
During the upheavals caused by Covid-19, we were proud to launch Apolitical Plus+, our first paid product, in October 2020. Let’s take a look under the hood at some of the technical details and challenges unique to Apolitical as a GovTech startup.
How we’ve evolved our platform in 2020
Hi, this is John from Apolitical’s Engineering team.
As technical-minded followers of Apolitical may know, our platform began life as a heavily customised WordPress theme. We’ve been steadily migrating to a service-oriented architecture as we’ve built out the platform, on a feature-by-feature basis. Plus+ is no exception.
The Apolitical platform is constantly evolving. It’s currently a mix of a customised WordPress content management system (CMS); node.js APIs built with Express.js , elasticsearch, sequelize and awilix; Python APIs using waitress, and a couple of bespoke components in Rust.
Our front-ends are built in React using atomic design and re-usable component libraries, such as our open source Styleguide. In parallel, our Data Science team also build services, data services and pipelines, Colab notebooks, and similar goodies — mostly in Python and semantic reasoning RDF technology.
Code is mostly hosted in Gitlab; their CI / CD pipeline support is a big win for us — and deployed to Google Cloud Platform, using Google Kubernetes Engine (GKE), Cloud SQL (MySQL for the old soldier WordPress, PostgreSQL for newer services), Cloud Functions, and other features. We also use some third-party SaaS such as Hubspot for customer relationships, and Auth0 for authentication.
Customer signup
The Apolitical platform is a high — trust network aiming to empower public servants. This means our customer needs are different than a standard consumer product.
For example, our customers (public servants and similar stakeholders) can sign up to the platform and access personalised Apolitical content, hear about upcoming Apolitical events, and so on. However, we need to verify their status as public servants first.
Our bespoke user funnel was largely rebuilt on the road to Plus+ (around when Covid-19 struck 😬 ) to handle both scale and variety of signups. So a customer can be auto-approved if their work email is associated with a known organisation. They can also be manually approved if they prefer — for example, if they want to use a personal email address, accompanied with a LinkedIn profile.
Either way, we verify their ownership of an email account when we activate their Apolitical account.
As my colleague Renzo wrote about recently, we’ve built a People API to handle personal information. We also built a signup-api and approvals-api, to meet our customer’s needs for the bespoke signup functionality — for example, communicating with Auth0 to auto-approve a public servant’s signup request. These were all built in node.js.
Payments and onboarding
Plus+ is our first paid offering. We sell it directly to government organisations, to public servants themselves, and through other institutions we partner with. We needed to rebuild how customers signed up to the platform in order to both simplify this process, and also enable us to take payments — either during signup, or as an upgrade for customers already with with an Apolitical account.
Public servants can get Plus+ accounts either pro-actively as individuals, or from a partner institution (such as Employment and Social Development Canada). If it’s the latter, your Plus+ membership may be paid for on their behalf by their institution. We’ve selected Stripe Payments for our payment infrastructure. major factors in this decision were their developer tooling, customisable integration and support for coupons.
When you buy Plus+, either as an existing or new Apolitical member, you’re directed to the Stripe checkout. After purchase, we use Cloud functions along with Stripe webhooks to update our platform, including a few PUTsto the People API as you subscribe to a given course.
Microcourses
The heart of Plus+ is bite-sized learning offerings made specifically for public servants— Apolitical’s microcourses — bespoke, with a variety of social learning activities (articles, worksheets, pairing exercises, etc.). These can be purchased individually, as an unlimited package, or through institutions.
To render these, we’ve built another repo called (surprise!) microcourses. Learning from experiences building out other platform features, for example migrating our solution articles from WordPress and our first steps with content internationalisation, we’ve continued to use React for our front-end technologies.
Microcourse content is researched, drafted and compiled by our talented journalists and editors in the Content Team. They then upload microcourses into WordPress, using the wp-adminfamiliar to many, adding further metadata through the customized interface.
However, the microcourses aren’t rendered via WordPress — instead, the metadata and textual content are served by our platform (currently the Rust-based articles API), with the WordPress workhorse, wp-uploads, serving media.
Yet rendering isn’t sufficient — we also need to support customer engagement as our learners progress and complete their courses, as well as contact them on completion (everyone loves certificates, right?). So as well as the people-api, we’ve also built the new people-engagement-api; to improve separation of concerns, platform components interact with this API rather than, for example, contacting Hubspot directly.
Performance, stability, monitoring
But that’s not all — there’s little point building a world-changing GovTech platform if our customers can’t use it.
To that end, we’ve been steadily improving our platform’s stability and scalability throughout 2020. Part of this has been adopting Helm, to improve pod autoscaling within GKE, and introducing terraform, to configure monitoring and alerting for critical workloads, preferring automated infrastructure-as-code over a manual point-and-click configuration. We’ve also rolled-up our sleeves to track down, isolate, and fix bottlenecks during periods of high usage — for example APIs or database capacity initially designed for 5,000 members, when by end of 2020 we’d scaled to over 100,000 Apolitical members.
There’s scope for technology like terraform to define and scale our infrastructure further, and in turn support Apolitical’s mission by meeting growing needs of public servants.
Well, that wraps up that Medium post
That concludes our whistlestop tour of some of the technical work and improvements to the Apolitical platform in 2020.
We’ve achieved a lot of technical work this year, closely aligned with our customer needs and business model; much of it during the pandemic.
And I didn’t even get mention our work on accessibility, search, personalisation, A/B testing, and other goodies (though, I just did, right?)
You can also get a taste of microcourses even if you’re not yet an an Apolitical Plus+ member — take a look at How to build a digital government service, for example.
What aspects of Apolitical Engineering are you most interested in learning about? Why not let us know in the comments. Thanks for reading!
Thanks to Tom Jeffrey for proofreading and the Engineering team for feedback.
