You can become a serverless blackbelt. Enrol in my course Learn you some Lambda best practice for great good! and learn best practices for performance, cost, security, resilience, observability and scalability. By the end of this course, you should be able to make informed decisions on which AWS service to use with Lambda and how to build highly scalable, resilient and cost-efficient serverless applications.
If you enjoy reading these exercises then please buy Crista’s book to support her work.
Style 11 – Letterbox
You may also know this style as message passing, or SmallTalk style (or Objective-C for that matter). It was also what Alan Kay had in mind when he coined the term Object Orientation all those years ago ;-)
- Larger problem is decomposed into things that make sense for the problem domain
- Each thing is a capsule of data that exposes one single procedure, namely the ability to receive and dispatch messages that are sent to it
- Message dispatch can result in sending the message to another capsule
The things that we end up with in this style is very similar to that of the Things (or OOP) style from the last post:
The difference here is that, each of these things exposes only a Dispatch method.
Let’s look at the DataStorageManager first, a faithful translation of Crista’s example would look like this:
Compared to the DataStorageManager implementation in the Things style, there are some notable differences:
- we lose type safety as we have to combine init and words into a single Dispatch method
- what ‘functionalities’ the things can provide is implied through the tagged arrays that the Dispatch logic is happy to accept
- the return types have to be unified to obj
- data has to be mutable
- consequently words also has to become a function
Given the strongly typed nature of F# we also need to explicitly cast every result to obj. This, of course, is not an issue in dynamically typed languages such as SmallTalk and Python. But, we’re in F# so let’s make the type system work for us rather than against us.
We can easily unify the different messages a Thing can accept into a union type:
Whilst we could also add a union type for the results, such as:
type DSManagerResult = Init of unit | Words of string
I don’t consider it to be much better because as a consumer of this API I still find it ambiguous. The signature Dispatch : DSManagerMessage -> DSManagerResult would suggest that you can always get either Init of unit or Words of string for any DSManagerMessage, which isn’t true.
If you know of a better way to add type safety to the return type in this case, please let me know via the comments section below.
Moving on to the StopWordsManager, we can apply the same approach:
And the same goes to the WordFrequencyManager:
And lastly, the WordFrequencyController:
in the init function here, we’ll initialize the various dependencies and instruct each to initialize accordingly:
in the run function, we’ll connect the various Things together by dispatching messages to them in a pipeline:
To get the answer, we’ll have to send some messages to an instance of WordFrequencyController:
Wait, all these message dispatching business look an awful lot like actors, couldn’t we have implemented the Things using F#’s mailbox processors instead?
There’s actually a subtle difference here in that actors are characterised by an internal message queue (which is outside the scope of the constraints here) and messages are sent asynchronously. If you’re a fan of mailbox processors then worry not, the Actor style comes later on in this series.
You can find the source code for this exercise here.
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.
Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!
Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!
Are you working with Serverless and looking for expert training to level-up your skills? Or are you looking for a solid foundation to start from? Look no further, register for my Production-Ready Serverless workshop to learn how to build production-grade Serverless applications!
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are wrong about serverless and vendor lock-in
- You are thinking about serverless costs all wrong
- Just how expensive is the full AWS SDK?
- Many faced threats to Serverless security
- We can do better than percentile latencies
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong
- Top 10 Serverless framework best practices