I love working on the full stack of technologies involved with developing an application. It’s satisfying to design and implement a feature on the backend and request the data from the frontend application to render out something awesome. It’s very rewarding but it can be a long process to set everything up. It’s often a boilerplate experience and I often find myself doing a lot more devops than development.

This got me looking for alternative ways to setup servers and systems that could alleviate this need to iterate on systems rather than programs. I looked into Serverless most recently and found a pretty low-ops solution to developing applications using on-demand server responses. However, major downsides include:

• No guarantee that every change will be run exactly once (changes must be idempotent)
• Sometimes there are spin-up times required to start an instance (user must wait if they happen to be the first one requesting in a while)
• Limits to duration of request mean that the frontend needs a different way to make long-running queries against the database rather than proxying through an API endpoint
• Difficult to debug systems

These and some smaller concerns kept my search going for an alternative. Recently I’ve stumbled over Event Source Systems and fell in love with how closely its architecture resembles other patterns I’ve recently adopted. It’s a truly exciting concept and one that I’m eager to share with you.

What are Event Source Systems?

Event Source Systems are systems that record and track events in order to change local state in a purely functional way. Recording the same event given the same state should always produce the same following state. At a conceptual level this will remind developers of functional programming using stores in Redux or the Elm Programming Language’s state system.

By tracking system events in a consistent way and storing the state within local memory, this pattern has a number of advantages:

• Systems are initialized by processing the history of every event making it easy to scale out new systems and distributing these systems
• Local memory reads are much faster than reads from another server
• Server rendered applications can render faster
• Time-travel debugging is possible thanks to a complete history of every event that changed state
• Logging is free and can easily cover all important events in the system that could impact state

Project Description

Since Event Source Systems haven’t been promoted to the extent that micro-services and serverless servers have been marketed, I’m not able to work from an existing example. Instead I’ll be developing my own ideas about how to build these systems and sharing my work to iterate upon feedback and evolve my own implementation and understanding.

I’d like to build a widget for my blog that I can use to highlight recent articles, books, movies, and video games that I’ve finished recently. Think Goodreads recently read feed for everything media. I want to be able to render this feed within my About page to highlight what I’m reading. I’d also like to hookup my Twitter so that this system will post a tweet whenever I finish something new.

I’m excited to show what I’ve been working on thus far. In the next post I’ll detail how I chose my technologies to solve this problem and work through the first implementation of an event source system. It’s going to be an exciting ride!

Continue to Part 2