Zero To Production #2: Learn By Building An Email Newsletter

Zero To Productionis a book that I will be writing in the open, publishing one chapter at a time on this blog. If you’d like to be notified when an episode comes out you can subscribe to the mailing list:

Chapter #2

1. • 1.1. Problem-based learning
   • 1.2. Course-correcting
2. What Should Our Newsletter Do?
   
   • 2.1. Capturing requirements
3. Working In Iterations

1. Our Driving Example

The Foreword stated that

Zero To Production will focus on the challenges of writing cloud-native applications in a team of four or five engineers with different levels of experience and proficiency.

How? Well, by actually building one!

1.1. Problem-based learning

Choose a problem you want to solve.

Let the problem drive the introduction of new concepts and techniques.

It flips the hierarchy you are used to: the material you are studying is not relevant because somebody claims it is, it is relevant because it is useful to get closer to a solution.

You learn new techniques and when it makes sense to reach for them.

The devil is in the details: a problem-based learning path can be delightful, yet it is painfully easy to misjudge how challenging each step of the journey is going to be.

Our driving example needs to be:

• small enough for us to tackle in a book without cutting corners;
• complex enough to surface most of the key themes that come up in bigger systems;
• interesting enough to keep readers engaged as they progress.

We will go for an email newsletter - the next section will detail the functionality we plan to cover.

1.2. Course-correcting

Problem-based learning works best in an interactive environment: the teacher acts as a facilitator, providing more or less support based on the behavioural cues and reactions of the participants.

A book, published on a website, does not give me the same chance.

I truly appreciate feedback on the material - please reach out to [email protected] or send me a DM on Twitter .

Providing feedback is, at this stage, a tangible way to contribute to Zero To Production .

2. What Should Our Newsletter Do?

There are dozens of companies providing services that include or are centered around the idea of managing a list of email addresses.

While they all share a set of core functionalities (i.e. sending emails), their services are tailored to specific use-cases: UI, marketing spin and pricing will differ significantly between a product targeted at big companies managing hundreds of thousands of addresses with strict security and compliance requirements compared to a SaaS offering geared to indie content creators running their own blogs or small online stores.

Now, we have no ambition to build the next MailChimp or ConvertKit - the scope would definitely be too broad for us to cover over the course of a book. Furthermore, several features would require applying the same concepts and techniques over and over again - it gets tedious to read after a while.

We will try to build an email newsletter service that supports what you need to get off the ground if you are willing to add an email subscription page to your blog - nothing more, nothing less.

2.1. Capturing requirements

The product brief above leaves some room for interpretation - to better scope what our service should support we will leverage user stories .

The format is fairly simple:

As a …,  I want to …,  So that …

A user story helps us to capture who we are building for ( as a ), the actions they want to perform ( want to ) as well as their motives ( so that ).

We will fulfill three user stories:

• As a blog visitor, I want to subscribe to the newsletter, so that I can receive email updates when new content is published on the blog;
• As the blog author, I want to send an email to all my subscribers, so that I can notify them when new content is published;
• As a subscriber, I want to be able to unsubscribe from the newsletter, so that I can stop receiving email updates from the blog.

We will not add features to

• manage multiple newsletters;
• segment subscribers in multiple audiences;
• track opening and click rates.

As said, pretty barebone - nonetheless, enough to satisfy the requirements of most blog authors.

It would certainly satisfy mine for Zero To Production itself.

3. Working In Iterations

Let’s zoom on one of those user stories:

As the blog author,  I want to send an email to all my subscribers,  So that I can notify them when new content is published.

What does this mean in practice ? What do we need to build?

As soon as you start looking closer at the problem tons of questions pop up - e.g. how do we ensure that the caller is indeed the blog author? Do we need to introduce an authentication mechanism? Do we support HTML in emails or do we stick to plain text? What about emojis :scream:?

We could easily spend months implementing an extremely polished email delivery system without having even a basic subscribe/unsubscribe functionality in place.

We might become the best at sending emails, but nobody is going to use our email newsletter service - it does not cover the full journey.

Instead of going deep on one story, we will try to build enough functionality to satisfy, to an extent , the requirements of all of our stories in our first release.

We will then go back and improve: add fault-tolerance and retries for email delivery, add a confirmation email for new subscribers, etc.

We will work in iterations: each iteration takes a fixed amount of time and gives us a slightly better version of the product, improving the experience of our users.

Worth stressing that we are iterating on product features, not engineering quality: the code produced in each iteration will be tested and properly documented even if it only delivers a tiny, fully functional feature.

Our code is going to production code at the end of each iteration - it needs to be production-quality.

3.1. Coming up

Strategy is clear, we can finally get started: the next chapter will focus on the subscription functionality.

Getting off the ground will require some initial heavy-lifting: choosing a web framework, setting up the infrastructure for managing database migrations, putting together our application scaffolding as well as our setup for integration testing.

Expect to spend way more time pair programming with the compiler going forward!

Zero To Productionis a book that I will be writing in the open, publishing one chapter at a time on this blog. If you’d like to be notified when an episode comes out you can subscribe to the mailing list:

Book ToC

The Table of Contents is provisional and might change over time. The draft below is the most accurate picture at this point in time.

• Who Is This Book For
• What Is This Book About

1. Getting Started
   
   • Installing The Rust Toolchain
   • Project Setup
   • IDEs
   • Continuous Integration
2. Our Driving Example (this blog post)
   
   • What Should Our Newsletter Do?
   • Working In Iterations
3. Sign Up A New Subscriber
   
   • Application Scaffolding
   • Our First Integration Test
   • Reading Request Data
   • Adding A Database
   • Persisting A New Subscriber
4. Publish A Newsletter Issue
   
   • Writing A REST Client
   • Mocking Third-Party APIs
5. Logging
   
   • The Facade Pattern
   • Logging Levels
   • Log Setup
6. Reject Invalid Subscribers
   
   • Result
   • Modeling With Types #1
7. Survive Delivery Failures
   
   • Simulating API Errors
8. Tracing
   
   • Structured Logging
   • Spans
   • OpenTelemetry
   • Jaeger
9. Send A Confirmation Email On Sign Up
   
   • Migrating Your Database
   • Modeling With Types #2
   • Handling Confirmations
   • Send Newsletter Only To Confirmed Subscribers
10. Metrics
    
    • Prometheus
    • Grafana
11. Send Emails Asynchronously
    
    • Adding A Message Broker
    • Enqueueing Tasks
12. Fulfilling Email Tasks
    
    • Adding An Actor Queue Worker
    • Basic Retries
    • Failure Injection
    • Idempotency
13. Benchmarking
    
    • Cargo bench
    • Criterion
    • Load testing