You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!
If you enjoy reading these exercises then please buy Crista’s book to support her work.
Style 19 – Plugins
- The problem is decomposed using some form of abstraction (procedures, functions, objects, etc.).
- All or some of the abstractions are physically encapsulated into their own, usually pre-compiled, packages. Main program and each of the packages are compiled independently. These packages are loaded dynamically by the main program, usually in the beginning (but not necessarily).
- Main program uses functions/objects from the dynamically-loaded packages, without knowing which exact implementation will be used. New implementations can be used without having to adapt or recompile the main program.
- External specification of which packages to load. This can be done by a configuration file, path conventions, user input or other mechanisms for external specification of code to be linked at run time.
We can derive a few design decisions from the constraints above:
- the plugins and the main program are to be in two separate assemblies
- the main program will load the plugins dynamically
- the main program will rely on external specification to determine which plugins to load
So, I added two new projects to the solution.
Style19Main will be the “main program” in this case, and the plugins will be defined in Style19Plugins.
First, we’ll define the contracts that these plugins must adhere to in Style19Main/PluginInterface.fs.
Notice that I have included a marker interface IPlugin, we’ll see how this comes in handy later on.
I have followed Crista’s example by splitting up the term frequency program into two stages – extract words from an input file, and finding the top 25 most frequent words.
Next, we’ll define the plugins that will implement these contracts.
I have neglected the supporting functions as they’re lifted right out of previous styles. The key point to take away here is that we have created two “plugins” that implement the aforementioned contracts.
Now we need to enable the “main program” to load these plugins dynamically at runtime. Back in the Style19Main project, let’s take a peek at MainProgram.fs.
Here, we’ll define the configuration that can be passed into the main program.
In the Config type above, we declared a PluginsDir field which tells us where to load plugins from. In the real world, this might be by convention – e.g. many popular apps have a plugins folder in its root folder.
Given an instance of this Config type, we will do the following:
- find all .DLL files inside the plugins directory
- dynamically load them
- for each assembly, find all the publicly visible types that:
- are concrete, non-abstract types
- implement the IPlugin marker interface
- construct an instance of each type (there’s an implicit assumption here that the type has a parameterless constructor)
- return the constructed plugin as a map (keyed to the names of the assembly and type)
Once we have loaded all the available plugins from DLLs in the specified folder, we can pick out the ones we need based on the configuration and execute them in turn.
The last thing we need is the “external specification”, which in this case will come from our Style19.fsx script file.
Here, we’ll simply construct the configuration and pass it along to the “main program”.
In this example I have included only one set of plugins, but the infrastructure is in place for you to add support for more plugins without having to recompile Style19Main (as per the constraints).
I find the plugins style a very useful tool in your toolbox and have used it with relative success in the past. Before you point it out to me, yes I’m aware of MEF, but I’m also not a fan of the amount of wiring required for it to work.
In general I prefer the reflection-based approach and find MEF introduces another layer of abstraction that adds more complexity than it hides.
You can find the source code for this exercise here.
Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.
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.
Skill up your serverless game with this hands-on workshop.
My 4-week Production-Ready Serverless online workshop is back!
This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.
We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.
If you enrol now you can also get 15% OFF with the promo code “yanprs15”.
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!
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.
- All you need to know about caching for serverless applications
- 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?
- Check-list for going live with API Gateway and Lambda
- How to choose the right API Gateway auth method
- CloudFormation protip: use !Sub instead of !Join
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- Guys, we’re doing pagination wrong
- Top 10 Serverless framework best practices
- How to break the “senior engineer” career ceiling
- My advice to junior developers