Article summary
Great apps aren’t stuck in the mud. They change with the times. They float like oak leaves along a wide river of user expectations, business requirements, fashion trends, and platform changes.
To keep floating, leaves 🍂 apps need a watchful team of developers to walk the muddy banks nudging them back toward fast water whenever they beach on rocks or swirl into murmuring whirlpools of chat bots. Some apps flow safely with only occasional nudges from a small team of developers, while others need a broader team to guide them along the waters safely.
Educational apps, for instance, need the help of a boatful of content authors to craft and maintain curriculum documents over time. Those documents often take the form of JSON files, which are pretty great at representing structure information like workflows and curricula in a human-readable(ish) way, but tough to work with as they get bigger. Writing JSON in Visual Studio Code with code folding and a thorough JSON Schema to guide IntelliSense can be a fine experience, close to pleasant even, if you squint. But we can do better.
We can build exquisitely user-tested curriculum editors that use all the latest technologies. They’re super-fun to build, and most developers would gladly trade the code-sinking muck at the edge of the river for a chance to build a custom web app that will only ever be used by a handful of people, on an internal team, using the latest evergreen browsers on computers built within the last year. It’s a developer’s dream.
But every minute your dev team spends building an editor is a minute that they don’t spend building the leaf 🍂 app that powers your business. For many companies, it makes more sense to defer the custom editor until later, when your business is booming and your accountant pesters you to save less and spend more. That’s the time for the custom editor.
For now, we’re going to pull out our duct tape and (stainless steel) drinking straws and build just enough infrastructure to help your content authors move quickly without breaking the bank.
Enter VSCode, TypeScript, and AWS λ
For our latest engagement, we built a curriculum editor out of Visual Studio Code, TypeScript, and AWS λ. The leaf 🍂 mobile app was built with TypeScript and React Native, and the cloud backend was distributed by AWS, so the combo was natural for our dev team.
If your ops engineer is painting through their Azure period, or your developers just learned themselves a Haskell, fear not. These ideas can be adapted into basically any development system. If you need a hand, I know where to find a bunch of really nice developers.
Our editor begins with a TypeScript type declaration that describes, in precise algebraic detail, the exact shape of our curriculum. We needed this part for the mobile app anyway, so we spent a grand total of $0 building the custom curriculum type.
Next, we needed a tool to make editing TypeScript easy and (almost) fun. Visual Studio Code fit the bill nicely. It was really easy to set up a sample TypeScript project that exported a single object describing our entire curriculum. We were even able to jumpstart our content author’s experience by including a list of recommended VSCode extensions in the sample project. Neat. And cheap too. We spent maybe an hour setting up a sample project and getting it ready to go.
Thanks to deep TypeScript integration, our content authors get instant feedback as they work, and the nerdier ones can even use all the power of a full programming language to automate their work.
With a fancy editor secured, we needed a way to safely and reliably compile the curriculum object that our TypeScript project produced into an oar 🛶 a JSON document. So we turned to AWS Lambda.
Because λ is fully managed, we didn’t have to worry about configuring a Linux server or giving our client something new to maintain. In a few more hours, we had packaged up the TypeScript compiler (it’s just another Node module) and some supporting JavaScript into a Node.js-based λ that would watch an S3 bucket for changes to a TypeScript project. On every change, it would compile the TypeScript into JavaScript, execute that JavaScript to produce a curriculum object, stringify that object into a JSON document, and write back to the S3 bucket.
Total investment so far: maybe a day of development time for one developer, including lots of testing and experimentation.
With the system in place, we had, for the price of about one developer day, produced a document-authoring system that helped our content authors keep their boat and the app floating down the river, while freeing the development team to walk the river banks again, gently guiding our 🍂 app away from the logjams of framework upgrades and the placid doldrums of flat design.