This tutorial covers the whys and the hows of building a serverless, event-driven, Slackbot that answers questions about Pokémon characters. Now that’s a lot for just one tutorial so let me explain…
What I love about coding is that there’s always so much to learn. What I hate about learning code are the endless code snippets. My kids build things out of lego blocks but I can’t build a useful application out of code snippets so I favour tutorials that give me a big picture. Big pictures are big, they take time to complete (and far longer to write). There’s no obvious right or wrong, they’re more art than engineering and art is much harder to explain.
This is my story about creating just one big picture. It’s not the only way to build a Slackbot but I chose the serverless, event-driven way because, as big pictures go, it’s one that covers skills that many of us will need in the coming years.
Why Serverless ?
With serverless I get to see my code running in production straight away, not only do I save time not building servers, not building images and not configuring Kubernetes but I also save money not paying others to do these things.
I’m an optimist, I assume people want to use the apps I build. Serverless scales massively, instantly and seamlessly without me having to manage instances, load balancers or scaling groups.
It’s very low cost. In addition to all the money I’ve saved not building servers, serverless apps typically cost less than 10% the compute cost of running servers 24/7.
Serverless apps are robust they communicate via message queues so it’s hard to lose data should anything go wrong.
I need to run code. 20 years ago servers in the basement ran my code, then servers in the cloud ran my code, then virtual servers and more recently images run my code. I will always need to run code but servers are a commodity and all commodities get cheaper and more convenient with time. Nothing says cheaper or more convenient than not being needed at all….
Why Event Driven ?
Sometimes it feels like my entire career has been battling monolithic architectures and their inevitable decay into technical slime. The ‘event driven way’ makes me want to think small and stay small.
Event driven systems are naturally decoupled like brains in jars. You can add components, remove components and update components the rest of your application won’t know and won’t care.
Why a Slack Bot ?
When I’m communicating with colleagues, friends and family I tend to use language rather than drags, drops and clicks. To talk effectively my friends don’t need to expose a great user interface (some aren’t even that responsive) but plain old text is still the best way to get your point across.
I don’t need any design, UX, HTML, CSS or Javascript skills to return the text ‘How are you ?’.
Why Pokemon ?
I have two six-year old boys that live and breath Pokemon. The types, the ‘attacks’ and stuff I just can’t remember. I’ll be using the pokeapi as light hearted way of giving our Slackbot something fun to do and hopefully learning one or two things about Pokemon during the journey.
Still interested ?
If you’ve read this far I’m guessing that I’ve got your attention. As a quick heads-up the application is written in Ruby but whether you code in Ruby or not, this tutorial is much more about the art of building a distributed, event-driven application in production than it is about code, syntax or any particular language. Actually, there’s not a lot of code and, as you’d expect from microservice based system, the little there is is very easy to follow. When I get time I’ll replicate it in Python.
The Pokebot Tutorial is a work in progress that I hope to complete by end of 2020. Thank you for reading & feel free to reach out, Steve Creedon.
Contents:
- Building a serverless, event-driven slack pokebot.
- What does a Pokebot look like ?
- Setting up for Slack, AWS and serverless.
- Build the gateway lambda
- About Messaging
- Build the controller and response services then DRY them up.
- Build the Poké-service see the app running
- Add the Responder service.
