Introduction

First thought that probably comes to your mind is “What’s wrong with his first brain?”

To answer that, my first brain is fine (AFAIK). Despite the brain in my head working fine, I depend on a second one in the form of Linear as part of my workflow. Agentic programming changed SWE, any single engineer can effectively act as a whole team and the implications of that are massive.

What used to be one engineer, working on one task for hours/days with full context in their heads and regular repetition to drill the details in memory is now multiple parallel tasks which need to be completed today. Compound this by the need to align with team members, review implementation, explain decisions etc, you quickly realize your memory cannot hold everything.

You can only hold so much in memory when handling multiple tasks. Chances are you forget alot - to test an edge case you considered, a specific reason behind an implementation decision, a compromise the team agreed to, the commit/PR where the feature started from, etc. Even if your memory was a steel-strap, you’re only one person, with a fixed amount of time/energy. If you held all context, across a growing number of implementations in your head alone, you would become a bottleneck to other team members who need context for their work. God forbid you fall sick and your business logic heavy service goes down.

My workflow

Any new work I start, begins with a clarification session between me and my favourite coding agent (Claude Code right now). During this we’re making sure I have enough context to create a solution - issue reproduction, high level feature scoping, clarification questions etc. Once this is clear, I ask Claude to create a issue on linear using the linear mcp tool based off this conversation.

Once the issue has been created, I work through it - create an implementation plan, review plan rigorously, implement, review implementation, get feedback, repeat as needed till I’m satisfied with the work that has been done. During this process I note decisions I and the team (via feedback conversations) made, insights that surfaced etc

Finally, when an implementation is ready to go out, I do my best (still working on it) to add those notes I took during implementation to the Linear issue, add screenshots from my local development environment if relevant and just try to put as much useful information as possible on Linear. Doing this dramatically reduces the cost of getting context on this work, both for other team members and future me.

Recently, I was wondering why an implementation I made was missing in production. Working with Claude, I was able to pull context from Linear, identifying the disconnect that led to that outcome in minutes!

That’s it. My process is still a work in progress but I can already see the benefits.

Have you ever played on a giant playground full of exciting games, where you can make your own rules and create your own adventures? Well, what if I told you there's a massive playground just like this, but it's hidden inside our computers and smartphones? This incredible playground is called Ethereum.

Ethereum is kind of like your favourite online game. You know, the one where you can play with friends, trade special items, and even build your own virtual world? Just like a bunch of friends playing an online game together, Ethereum is actually made up of many, many computers from all over the world, all playing together at the same time.

And the most exciting part? Each of these computers has its very own game console! In the world of Ethereum, we call this special game console the 'Ethereum Virtual Machine', or 'EVM' for short. Each EVM can run lots of different games, help players trade items, and even keep score!

So, are you ready to dive in and learn all about this incredible playground and its game consoles? Let's get started on our adventure in Ethereum, the biggest playground in the world inside our computers!

1: The Game Consoles (EVM) in Every Computer

You know how when you're playing with your game console at home, you can play all sorts of different games, right? Maybe you like to race cars in one game or hunt for treasure in another. And sometimes, you just want to play a simple game like checkers.

Now, let's think about our giant playground called Ethereum. This playground is super cool because every computer connected to it has its own special game console! We call this unique game console the Ethereum Virtual Machine, or EVM for short.

Like your console at home, these EVMs can run lots of different games too. But the games they play are called 'smart contracts'. Each smart contract is like a different game, with its own unique rules and objectives. One smart contract might be like a treasure hunt game, while another one might be more like trading cards with your friends.

But that's not all! These game consoles (EVMs) also do simple tasks, just like your game console can do more than just run games. Have you ever sent a message to a friend through your console, or maybe traded a game item with them? The EVMs can do something similar. They can move virtual coins from one player's account to another, just like how you might send a friend some game items.

Isn't that amazing? Thousands and thousands of game consoles, all playing different games and also doing simple tasks, all at the same time! And even though the games might be different, and the consoles are in different computers, they all work together to make the Ethereum playground a fun and fair place for everyone.

2: The Games We Play (Smart Contracts)

You know when you're playing a video game, how each game has its own rules and challenges? Maybe one game has you rescue a princess, and another has you build the tallest tower. Well, the Ethereum playground has games like that too, but we call them 'smart contracts'.

Each smart contract is a special kind of game with its own set of rules. For example, one smart contract might be a game where you can trade virtual pets with your friends. Another smart contract could be a game that helps you save your virtual coins.

And guess what? All the people using Ethereum are like players in this big playground. They use their game consoles (the EVMs we talked about) to play these smart contract games.

Just think about it - you want to trade a shiny virtual dragon for your friend's cool virtual unicorn. You'd go to the 'Pet Trading' smart contract game on your EVM console, and your friend would do the same on theirs. You follow the game's rules, and voila! You've got a cool new unicorn, and your friend now owns a shiny dragon.

But it's not just about trading pets. There are tons of different smart contract games that do lots of fun and helpful things. Some might let you start a virtual lemonade stand and keep track of how many customers you have. Others might let you send virtual birthday presents to your friends.

Fun stuff!

3: Playground Rules (Protocols)

Every fun and safe playground has rules, right? Rules like taking turns on the swings, or not running too fast to keep everyone safe. In our giant Ethereum playground, we have rules too! These rules are called 'protocols', and they're super important to make sure everyone plays fairly and has fun.

You can think of protocols like playground rules that tell everyone how to play the games. So, no matter what game you're playing on your game console (EVM), the protocols make sure the game works the same way for everyone. That way, whether you're trading virtual pets, saving virtual coins, or sending virtual gifts, you know the rules will be the same no matter where you are or who you're playing with.

And guess what? These rules, or protocols, are followed by every game console (EVM) in our Ethereum playground. Whether the console is in your computer, your friend's computer, or a computer on the other side of the world, they all follow the same rules. This is what makes the games fair, and what makes our Ethereum playground a great place for everyone to play in.

Just think about how amazing that is! Thousands and thousands of game consoles (EVMs), all playing different games (smart contracts), but all following the same playground rules (protocols). This makes sure the games are fun, fair, and work the same way for everyone in our Ethereum playground!

4: Powering the Consoles (Gas)

Do you remember how your game console at home needs power to work? You might have to plug it into a wall socket, or maybe it runs on batteries. Without power, you wouldn't be able to play any games. In our Ethereum playground, the game consoles (EVMs) need power too! But instead of electricity or batteries, they use something called 'Gas'.

Gas is like the power that keeps all the game consoles (EVMs) running and the games (smart contracts) playing. But Gas isn't just about keeping things running; it also makes sure that everyone plays fair. By needing Gas to play a game or do something on Ethereum, it stops anyone from hogging all the game time.

Imagine if someone tried to play all the games in the playground without stopping, leaving no time for anyone else. It wouldn't be much fun, right? Well, Gas prevents that from happening in our Ethereum playground. Since everyone needs Gas to play the games (run smart contracts), it makes sure that everyone gets a turn, and that the game consoles (EVMs) don't get too tired.

Just like how a big, complex video game might use up more of your console's power, some tasks or 'games' in our Ethereum playground need more gas to run. That means when someone wants to do something big or complex in Ethereum, they need to pay more gas.

For example, if you're playing a simple game like checkers, your game console might not need much power. But what if you're playing a big, exciting adventure game with lots of characters and levels? That might use up a lot more power!

In the same way, if you're doing something simple on the Ethereum playground, like sending your friend a virtual coin, it might not need a lot of Gas. But if you're playing a more complex 'game', like trading a hundred different virtual pets all at once, that might need a lot more Gas! And because it's a bigger task, you would need to pay more Gas to get it done. You can read more on gas here.

So, the next time you're playing a game on your console at home, think about how it needs power to run. And remember, in the Ethereum playground, all the game consoles (EVMs) and the games (smart contracts) they run also need power - that power is Gas! And the more complex the game, the more Gas you'll need to pay to play!

5: Remembering the Games (Blockchain)

Imagine you're in a giant game arcade, full of many different game consoles. You and your friends are playing games, and there's a big scoreboard that keeps track of all the scores. But in this special arcade, whenever a game is played on one console, all the other consoles in the arcade play the same game too, to double-check the score. This is a bit like how Ethereum works!

In Ethereum's big playground, whenever a game (transaction or smart contract) is played on one game console (EVM), all the other game consoles (EVMs) in the playground run the same game too. They're all double-checking each other to make sure that every game is played correctly and the scores (transactions) are right.

This might sound like a lot of work, but it's very important because it makes sure everything is fair and nobody is cheating. Just like how referees in a game make sure that all players are following the rules, in Ethereum, all the game consoles (EVMs) are making sure every game is played correctly.

But how do all the consoles agree on the scores? Well, after all the game consoles have run the same game, they talk to each other. They all agree on what the scores are and write them down in their copy of the big game diary (blockchain). This process is called consensus, and it's a bit like when you and your friends agree on what the score is after a game.

So, the Ethereum blockchain is like a giant scoreboard or game diary that keeps track of all the games that have been played in the playground. But it's not just any diary; it's a diary that every console in the playground helps write and agree on! This keeps our playground fair, fun, and open for everyone to enjoy.

Conclusion: Adventure in the Ethereum Playground

Let's recap what we've learned about our amazing Ethereum playground:

• Ethereum is like a gigantic playground that's not in a park or a garden but inside our computers and smartphones!

• Inside this playground, each computer has its very own game console called the Ethereum Virtual Machine, or EVM for short.

• These EVMs are incredible! They can:

  • Play lots of different games, each with its own rules and challenges. These games are known as 'smart contracts'.

  • Perform simple tasks, like moving virtual coins from one player to another.

• Just like a game console at home needs power to work, the EVMs also need power. In Ethereum, this power is called 'Gas'.

  • Gas not only keeps the EVMs running and the games playing but also makes sure everyone gets a turn to play.

  • The more complex the game (smart contract), the more Gas it needs.

• Lastly, let's not forget about our giant game diary, the blockchain. This diary keeps track of every game played and every score made in our Ethereum playground.

  • All the EVMs help write this diary and agree on what's written. This keeps the playground fair and fun for everyone!

Isn't it exciting to think about? A massive playground inside our computers, filled with game consoles (EVMs) playing different games (smart contracts), all powered by Gas and all following the same playground rules!

But our Ethereum adventure doesn't end here. There's so much more to discover and explore:

• You can find new games (smart contracts).

• You could create your own games (smart contracts).

• You're not just a player in the Ethereum playground; you're also part of creating this world.

So, keep exploring, keep learning, and most importantly, keep having fun in the world inside our computers - Ethereum!

1. Introduction

Today, my friends, we're diving into the mind-boggling world of Automatic Market Makers, or as the cool kids say, AMMs. Now, you might be scratching your head, going, "What the hell is all this about?" Well, hold onto your seats because we're about to demystify the whole damn thing!

In the simplest terms, AMMs are like your friendly neighbourhood shopkeepers, but for the cryptocurrency world. They're always there, waiting with open arms, ready to trade any combination of assets at any time of the day (or night). They don't judge or discriminate - whether you want to swap Ether for DAI, BAT for USDT, or any other trade you can dream up, they're there to help make it happen.

But how do they do it? Well, they utilize a mathematical formula to automatically determine the price of trades. No haggling, no lengthy negotiations, just quick and straightforward transactions. Sweet, right?

So where do AMMs fit in the grand scheme of things, you might ask? AMMs are dead centre in the world of decentralized exchanges, they've brought a revolutionary change to asset trading.

Before AMMs, trading could be a bit of a drag. You needed a buyer for every seller, a matching pair for every trade. Now, with AMMs, that's a thing of the past. They act as a constant party on the other side of the trade, providing liquidity and enabling trades to happen smoothly. Think of them as the fuel that keeps the DeFi engine running!

But don't worry, we'll dive deeper into all these topics in the coming sections. Ready?

2. The Problem with Traditional Exchanges

Let's imagine you're in a bustling marketplace. The air is filled with the noise of people haggling, cash registers ringing, goods exchanging hands - it's a vivid picture of supply meeting demand. This is what traditional exchanges are like. They operate on an order book model, where buyers and sellers list their desired prices and quantities. When a buyer's price matches a seller's, voila, a trade occurs!

Allow me to illustrate:

In a bustling marketplace, imagine you're a vendor with apples priced at $1 each, while a buyer is bidding $0.90 per apple. The mismatch, known as the 'spread', prevents a trade. However, a new buyer enters, willing to match your $1 ask price, and the trade occurs. This scenario epitomizes traditional exchanges operating on an order book model, where trades are based on matching a buyer's bid price with a seller's ask price, creating the dynamic and lively environment of the marketplace or financial exchange.

While this system has been serving us pretty well for quite a while, it does have its quirks and hitches. Centralized exchanges such as Binance, Coinbase, KuCoin and so on, for example, have often been likened to traditional banks. They act as middlemen, holding users' assets and managing trades. This centralized model, however, has several drawbacks. It's vulnerable to hacks and other security issues. It can also be a bottleneck during peak trading times, slowing down transactions and affecting the overall user experience.

On the other hand, decentralized exchanges (DEXs) eliminate the middleman, allowing peer-to-peer trades using smart contracts. This gives users more control over their assets and enhances privacy. But traditional DEXs also face challenges. Liquidity can be a major issue, especially for less popular tokens. If there's not enough interest on both sides of a trade, it could be tough to get your transactions through.

Here's where AMMs come in. Remember our marketplace analogy? Well, imagine now a marketplace that never sleeps, where you always find a willing buyer or seller, regardless of how rare or popular your goods are. Sounds amazing, right? This is the kind of environment AMMs create.

AMMs turn the concept of an order book on its head. They do this in two ways:

1. Instead of waiting for a buyer's price to match a seller's, they use a pre-set formula to determine the price of a trade, no matter when you want to make it. You could think of AMMs as vending machines. They always have a set price for their goods, ready to trade anytime, any day!

2. AMMs allow anyone to become a liquidity provider by depositing assets into a pool. In return, these liquidity providers earn transaction fees, incentivizing more people to contribute and, thereby, solving the liquidity problem we often see in traditional DEXs.

To sum it up, AMMs address the limitations of traditional exchanges by offering constant liquidity and enabling peer-to-peer trades without the need for an order book.

3. Understanding Liquidity Pools

Imagine a big, community chest where people throw in their spare coins. It's always available, and you can take coins out whenever you want, as long as you replace them with something of equal value. This, my friends, is a liquidity pool in a nutshell - a shared pot of tokens that powers an AMM.

Here's how it works. In an AMM, you're not directly trading with another person. Instead, you're trading with a smart contract, a piece of code that runs on a blockchain network (like Ethereum). This contract, powered by the liquidity pool, will always take your trade, no matter the hour or the demand.

The size and composition of this pool matter a lot. A larger pool means more liquidity, which in turn means you can make bigger trades without significantly affecting the price. In the world of DeFi, we love this thing called 'slippage' as much as a cat loves taking a bath. Slippage refers to the difference between the expected price of a trade and the price at which it actually executes. More liquidity equals less slippage and less slippage equals happier traders!

Now, where does this pool come from? Well, that's where our unsung heroes - the Liquidity Providers (LPs) - step in. LPs are regular folks like you and me who deposit their tokens into these pools. In essence, they're saying, "Here you go, AMM! Use my tokens to facilitate trades."

But why would anyone want to lend their precious tokens to a smart contract? What's in it for them? Well, by becoming LPs, people can earn passive income in the form of transaction fees. Every time someone makes a trade, a tiny fraction of it is taken as a fee, which then gets distributed among the LPs. It's like a reward for keeping the DeFi machine well-oiled and running.

However, providing liquidity isn't all sunshine and rainbows. It comes with its own set of risks, such as impermanent loss, price slippage, and so on.

4. The Constant Product Market Maker Model

Remember AMMs use a mathematical formula to automatically determine the price of trades? While there are variations of this formula, the constant thing is they make sure the total assets locked for trading remain constant.

This group of functions are referred to as constant function market makers (CFMMs), examples include: Constant Product Market Maker (CPMM), Constant Sum Market Maker (CSMM), Constant Mean Market Maker (CMMM).

Now, onto one of the most widely used mechanisms - the Constant Product Market Maker Model (CPMM).

So what's this fancy term, you ask? It's simpler than it sounds.

Imagine a seesaw, perfectly balanced. As one side goes up, the other side goes down. That’s basically what the constant product formula does, but with token prices instead of kids on a playground.

Let's break it down. The Constant Product Market Maker Model is based on a simple formula: x*y=k, where x and y represent the quantities of the two tokens in the liquidity pool, and k is a constant value. This constant, k, in theory at least, must always remain the same – hence the term "constant product". In practice, however, deviations can occur due to the dynamics of trading. These small variations in k are considered acceptable as long as they remain within an acceptable range and do not significantly impact the market's liquidity or stability.

Sounds a bit abstract, right? Don't worry! Let's break it down with a concrete example.

Let's say we have a liquidity pool with 100 ETH and 2000 DAI. Applying our formula, k would be 100*2000 = 200,000. This means that no matter how our token quantities change through trades, their product should always equal 200,000.

So, if someone comes along and buys 1 ETH for 20 DAI, our pool would have 99 ETH and 2020 DAI. If we do the math, 99*2020 = 199,980, which is close to our k, but not exactly equal. The difference here, my friends, is due to something we call "slippage", which we've touched on earlier.

This model is great for keeping our AMM fair and balanced, but it does influence the price of tokens. How, you might ask? Well, the price in this model is essentially determined by the ratio of the tokens in the pool. If we go back to our previous example, initially, the price of 1 ETH is 20 DAI (2000 DAI/100 ETH = 20 DAI/ETH). But after that trade, the price becomes 20.40 DAI (2020 DAI/99 ETH = 20.40 DAI/ETH). So, you see, the act of buying ETH with DAI raised the price of ETH.

Here's a simple way to remember how this works:

• When the amount of a token in a pool decreases (because it's being bought), its price goes up.

• Conversely, when the amount of a token in a pool increases (because it's being sold), its price goes down.

With all these moving parts, it might seem like there's a lot going on. But here's a summary to help you keep track:

1. The Constant Product Market Maker Model is based on the formula x*y=k.

2. The quantities of tokens in the liquidity pool can change, but their product (k) always stays the same.

3. The price of tokens is determined by their ratio in the pool.

Whew! That was a bit of a marathon, wasn't it? But guess what? You've now got a solid understanding of how the Constant Product Market Maker Model works and how it determines the price of tokens in a liquidity pool.

5. Popular AMMs: Uniswap, Balancer, and Curve

It's time to explore some of the most popular Automatic Market Makers (AMMs) in the DeFi landscape. While several decentralized exchanges employ AMMs, these three platforms are sufficiently differentiated in their approach to handling AMMs. Let's jump right in!

Uniswap: The Trailblazer

Uniswap is undoubtedly the pioneer of AMMs, capturing the hearts and minds of DeFi enthusiasts worldwide. Launched in 2018, it introduced the concept of liquidity pools powered by smart contracts on the Ethereum blockchain. What sets Uniswap apart is its simple yet powerful approach:

• Permissionless and Trustless: Anyone can participate in Uniswap without any intermediaries. No need for registration, KYC, or waiting for approvals. It's a truly open and permissionless platform.

• Constant Product Market Maker: Uniswap employs the Constant Product Market Maker Model we discussed earlier, enabling users to trade ERC-20 tokens directly from their wallets. The platform uses a deterministic algorithm to calculate token prices, ensuring fair and transparent trades.

• Liquidity Provider Incentives: Uniswap incentivizes liquidity providers by offering them a share of the trading fees generated by the platform. By staking their tokens in a liquidity pool, users can earn a portion of the trading fees proportional to their contribution.

Uniswap's simplicity and user-friendly interface have made it the go-to choice for many traders and liquidity providers, contributing to its immense popularity and liquidity depth.

Balancer: The Power of Customization

Next up, we have Balancer, an AMM that takes the concept of liquidity pools to a whole new level. Balancer introduces a unique feature: the ability to create customizable pools with multiple tokens and varying weights. Here's what makes Balancer stand out:

• Flexible Pools: Unlike Uniswap's 50/50 token ratio, Balancer allows users to create pools with different token compositions. For instance, you can set up a pool with 80% DAI, 15% ETH, and 5% MKR. This flexibility opens up a world of possibilities, enabling the creation of pools that cater to specific trading strategies.

• Smart Order Routing: Balancer optimizes trading by automatically splitting orders across multiple pools to achieve the best possible price. This feature enhances efficiency and minimizes slippage, providing users with more favourable trading experiences.

• Balancer Tokens: Balancer also introduces its native token called BAL. Holders of BAL tokens have governance rights, enabling them to participate in the decision-making process of the platform. These tokens can be earned by providing liquidity to Balancer pools.

With its customizable pools and advanced trading capabilities, Balancer offers a rich trading experience for users seeking greater control over their strategies.

Curve: The Stablecoin Specialist

Last but not least, we have Curve, an AMM designed specifically for stablecoin trading. As we know, stablecoins play a crucial role in the DeFi ecosystem, providing stability and serving as a reliable medium of exchange. Curve takes this concept to new heights:

• Low Slippage for Stablecoins: Curve is optimized for trading stablecoins, ensuring minimal slippage and reduced fees. By focusing on stable assets, Curve provides a reliable and efficient trading experience for users looking to swap between stablecoins.

• Low Volatility Pools: Curve utilizes specialized pool strategies, such as the StableSwap algorithm, to maintain low volatility. These strategies aim to keep the peg of stablecoins intact and minimize price fluctuations, resulting in a smoother trading experience.

• Enhanced Liquidity: Curve incentivizes liquidity providers with trading fees and CRV tokens, encouraging them to contribute to the platform's liquidity. This ensures ample liquidity for stablecoin trading, enhancing stability and reducing price impact.

Curve's dedication to stablecoin trading has made it a popular choice for users seeking seamless and secure stablecoin swaps.

6. Risks and Challenges with Automated Market Makers (AMMs)

While the advent of AMMs has fundamentally revolutionized the DeFi space, it's not without its risks and challenges. Let's take a look at some of these potential pitfalls, particularly impermanent loss, price slippage, and smart contract risk.

1. Impermanent Loss:

Impermanent loss can be an unfamiliar concept for those new to the DeFi space, but it's of paramount importance if you're interacting with AMMs. Imagine you're providing liquidity to a pool and the relative price of your tokens changes compared to when you deposited them. The "loss" comes into play when the current price divergence causes your stake in the liquidity pool to be worth less than if you had just held onto the tokens.

For example, you've contributed 1 ETH and 100 DAI (assuming 1 ETH = 100 DAI) to a liquidity pool. If the price of ETH rises to 200 DAI, the AMM would balance itself, resulting in fewer ETH and more DAI in your pool share. If you decide to withdraw at this point, you end up with less ETH than you initially put in, experiencing what's known as 'impermanent loss'.

2. Price Slippage:

In a nutshell, price slippage refers to the difference between the expected price of a trade and the actual price at which the trade is executed. This phenomenon is particularly prevalent in AMMs due to the algorithmic nature of price determination.

Imagine wanting to trade 10,000 DAI for ETH in a pool. If the pool’s liquidity isn't sufficient, the initial DAI you trade, say the first few hundred, will get you a reasonable amount of ETH, per the prevailing market exchange rate. However, as you continue trading more DAI for ETH, the pool's DAI supply increases while its ETH supply decreases. This imbalance causes the pool's DAI/ETH exchange rate to shift against you ('slip' effectively), in accordance with the AMM's pricing algorithm. As a result, for each subsequent DAI you trade, you receive incrementally less ETH.

3. Smart Contract Risk:

Smart contracts are the backbone of AMMs and, as such, they carry their share of risk. From potential bugs in the contract code to more malicious exploits, the automatic and immutable nature of smart contracts can pose a significant threat.

The infamous DAO Hack in 2016 was due to a smart contract vulnerability where recursive calls were exploited, leading to a loss of around $60M worth of Ether.

Mitigating AMM Risks

As intimidating as these risks may seem, the DeFi community is constantly innovating and developing strategies to counteract these issues.

1. Impermanent Loss & Price Slippage::

New iterations on the initial AMM models are emerging, models such as:

• Hybrid Automated Market Makers (HAMM)

• Dynamic Automated Market Makers (DAMM)

• Virtual Automated Market Makers (VAMM)

• Proactive Market Makers (PMM)

• Replicating Market Maker (RMM)

These new models apply different mechanisms such as reducing price impact, distributing liquidity better, and proactively moving the price curve in an attempt to combat impermanent loss and price slippage

Feel free to explore.

2. Managing Smart Contract Risk:

Smart contract risk is mitigated by robust testing, formal verification, and audits by reputable security firms. On top of this, some platforms are integrating insurance or bug bounty programs into their protocol to provide an additional layer of protection.

7. Conclusion

We've navigated quite a journey through the world of Automated Market Makers, haven't we? In our expedition, we explored several facets of AMMs, from their foundational principles to their influential role in the DeFi space. Let's revisit the key takeaways to solidify our newfound knowledge.

• AMMs are Game Changers: AMMs have introduced a revolutionary shift in how asset exchange works. By eliminating the need for order books and enabling seamless token swaps, they've undeniably made the DeFi space more accessible and efficient.

• The Power of Liquidity Pools: At the heart of every AMM, we find liquidity pools. These are fueled by liquidity providers who deposit pairs of tokens and earn trading fees in return, creating a self-sustaining ecosystem of decentralized exchanges.

• Modelling the Market: We delved into the Constant Product Market Maker Model, the mathematical magic behind price determination in a liquidity pool. The elegant simplicity of this model is a key reason for its widespread adoption.

• Variety of AMMs: We acquainted ourselves with notable AMMs like Uniswap, Balancer, and Curve. Each one brings something unique to the table, making the DeFi landscape more robust and diverse.

• Risk and Reward: Like all financial systems, AMMs come with their share of risks. Impermanent loss, price slippage, and smart contract risk are significant hurdles. However, innovators in the space continue to develop solutions to these challenges.

So, what lies ahead for AMMs and the broader DeFi landscape? Well, the potential is staggering. AMMs have just begun to scratch the surface of the possible disruptions in the financial world. They've already created a paradigm shift in how we trade and exchange assets, democratizing the process and making it more accessible to the masses.

However, as we peer into the future, the potential implications of AMMs extend beyond just trading. As the underlying technology evolves, we may see AMMs integrated into more complex financial instruments or operations. Imagine a world where complex derivatives or loans are handled completely by smart contracts and AMMs. The possibilities are truly endless.

In the grand scheme of things, we're still in the early stages of this exciting journey. As we continue to advance and innovate, AMMs will undoubtedly play a pivotal role in shaping the DeFi landscape and possibly the future of finance as we know it.

So, strap in and hold on tight. The future is looking mighty exciting, my friends, and I can't wait to continue learning, exploring, and sharing this journey with you all. Till our next exploration, stay curious and keep learning!

Hello, world! Welcome to the fascinating world of Ethereum, blockchain's answer to Disneyland. A platform that has turned the game upside down for decentralized applications and smart contracts. These contracts, with their superpowers, can be executed flawlessly based on predefined conditions, automating tasks and are revolutionizing how we handle money, how we govern, and how we trace supply chains.

The star player in the Ethereum arena is gas – the secret sauce that keeps the Ethereum engine running. It's the driving force behind all transactions and smart contracts on this network. By ensuring fairness and preventing resource-hogging or rogue code, gas safeguards the network's integrity and security. So, gas isn't just a mundane concept; it's the superhero of the Ethereum show!

2. Understanding Gas in Ethereum

Have you heard of "gas" in Ethereum? It's not the kind that powers your car, but the "energy" that makes things happen. Every operation, every transaction, every little thing you do on Ethereum needs some of this gas. It's like the tokens you put into an arcade machine to play a game - no gas, no fun.

Ethereum uses gas to keep everyone playing fair. It's a rationing system, ensuring everyone gets a turn on the Ethereum playground. But here's the kicker - gas isn't free. It's priced in Ether (ETH), Ethereum's native cryptocurrency, specifically in a smaller unit of Ether called Gwei.

Let's break it down with an example. Imagine you're sending 1 ETH to a friend. For that transaction, you might set a gas limit of 21,000 (that's how much "energy" you think it'll take) and a gas price of 20 Gwei. The gas limit here is like your guess of how much "energy" your transaction will require, while the gas price is what you're willing to pay for each unit of that "energy".

If the Ethereum network is not too congested, your transaction gets processed, and the total gas cost will be the gas limit times the gas price, which is 21,000 (gas limit) * 20 (gas price) = 420,000 Gwei. This amount is deducted from your ETH balance.

However, if the network is busy and many people are trying to transact at the same time, your transaction might not get processed unless you're willing to pay a higher gas price. It's a bit like an auction where you're bidding for the network's computational resources!

This concept can be represented in pseudo-code as follows:

function sendTransaction() {
  var gasLimit = 21000;
  var gasPrice = 20; // in Gwei
  var totalGasCost = gasLimit * gasPrice;

  if (totalGasCost <= yourCurrentBalance) {
    // go ahead, send the transaction
  } else {
    // sorry mate, you need more Ether
  }
}

So that's the lowdown on gas in Ethereum - it's all about keeping the network running smoothly, ensuring everyone gets a fair go, and making sure you pay for what you use. And remember, the key is to find that sweet spot of gas price that gets your transaction through without emptying your Ether wallet!

3. The Role of Gas in Smart Contract Execution

Let's dive into the juicy part - how gas plays its part in smart contract execution. Imagine gas as the juice that powers up each action in your smart contract. You got it, every function you call, every operation you run, it all needs some gas to make it happen.

Think of it like a game arcade. If you want to play a game (run a function), you gotta put in some tokens (gas). Now, not all games (operations) in this Ethereum arcade cost the same. Let's break it down into categories:

• Reading Operations: Reading data from the blockchain is like playing the simplest arcade game, let's say a round of air hockey. Doesn't cost much gas because all you're doing is checking out data that's already there. You're not changing anything.

• Arithmetic Operations: Doing some math in your contract, like adding or subtracting numbers, is like your old-school Pac-Man. Still pretty affordable in terms of gas, but a tad bit more than just reading data.

• Storing Data: Now, if you're storing data or creating new contracts - that's like the deluxe VR game in the corner. Storing data means you're actively changing something on the blockchain. And that, my friend, will cost you a bit more gas.

• Complex Operations: Then there are some operations that are the equivalent of that flashy, new racing game everyone's lining up to play. These could be things like calling other contracts or using loops in your functions. These will be the most gas-hungry operations.

Before you start playing (run a transaction), you need to estimate how many tokens (gas) you'll need. That's your gas limit. If you run out of tokens before you finish the game, it's game over! In Ethereum, we call this an "out-of-gas" error. And just like in the arcade, there's no refunds or do-overs. Your tokens (gas) are spent, and you'll need more to keep playing.

In a nutshell, every operation in your smart contract is like a game in the arcade that costs a certain amount of tokens (gas). Choose your operations wisely, and always keep an eye on your gas limit!

4. Estimating Gas Costs

Alright, get ready, we're cruising into the land of estimating gas costs. Think of it like calculating how much gas you'd need for a cross-country road trip. You've got your destination, now you gotta work out the fuel.

So, how do you do it? Well, there are a few ways. Some folks use online platforms like Etherscan or ETH Gas Station to check out average gas costs. Others might go for MetaMask, a browser extension that estimates the gas for you when you're about to make a transaction. It's like having a buddy who's great at mental math in the passenger seat.

But if you really wanna dive under the hood, there's the 'estimateGas' function in web3.js, Ethereum's JavaScript API. This nifty tool is like your car's onboard computer. You give it the details of your journey (the transaction), and it calculates the fuel you'll need (the gas). Here's a quick peek:

web3.eth.estimateGas({
    to: "0xSomeAddress",
    data: "0xSomeData"
})
.then(console.log);

So, what's going on here? Well, you're asking 'estimateGas' to take a look at a hypothetical transaction to a certain address ('0xSomeAddress'), with certain data ('0xSomeData'). It runs the numbers and then logs the estimated gas cost.

But here's the twist: the gas estimate doesn't give you the exact cost in Ether. Nope, it's more like a puzzle piece. You'll need to multiply the gas estimate by the current gas price (in Gwei) to get the actual cost in Ether. It's like calculating the total bill at a restaurant – the menu tells you the price per dish, and you do the math to get the final bill.

Let's take a look at a practical example to make things crystal clear:

const gasEstimate = 50000; // Gas estimate received from a tool
const gasPrice = 20; // Gas price in Gwei
const actualCost = gasEstimate * gasPrice; // Actual cost in Ether

console.log(`The estimated gas cost is ${gasEstimate} units.`);
console.log(`To calculate the actual cost, multiply it by the gas price (${gasPrice} Gwei).`);
console.log(`The total cost will be ${actualCost} Ether.`);

But remember, it's like a weather forecast. It's a pretty good guess, but always bring an umbrella just in case!

5. Optimizing Smart Contracts for Lower Gas Consumption

Time to dive headfirst into the world of crafting lean, mean, gas-efficient smart contracts! We've got some tips, cool tools, and real-world examples to help you ace the game of gas optimization. So, buckle up and get ready for a wild ride!

Here are some best practices that can work wonders in writing efficient smart contracts:

• Minimize those pesky storage operations, just like tidying up your room to make it neat.

• Avoid those never-ending loops that gobble up gas like the plague. Opt for elegant algorithms to keep things running smoothly.

Now, let's explore some handy tools to analyze and optimize gas usage in smart contracts. These tools are like superheroes that can save the day:

• Gas Analyzers: They're like Sherlock Holmes, investigating your code to uncover any gas-hogging culprits. Some examples include: EthGasStation, GasNow, Blockscout, Gas Price Monitor, Gas Tracker, etc

• Profilers: Think of them as personal trainers, helping you shed unnecessary gas weight and build leaner contracts. They work by running your contracts and collecting data on the gas used by each function. This data can then be used to identify areas where your contracts are using more gas than necessary. Some examples include: Remix IDE, Truffle Suite, Tracer, EthVM, Gasper

But wait, there's more! Let's take a look at some optimized smart contract code to get your gears turning:

// Voting System Example

contract Voting {
    mapping(address => bool) public hasVoted;
    uint256 public totalVotes;

    function vote() public {
        require(!hasVoted[msg.sender], "You've already cast your vote!");

        // Voting logic here

        hasVoted[msg.sender] = true;
        totalVotes++;
    }

Voting System: By using a mapping to track votes and avoiding redundant storage updates, you can create a lean and efficient voting contract.

// Token Transfer Example

contract Token {
    mapping(address => uint256) public balances;

    function batchTransfer(address[] memory recipients, uint256 amount) public {
        for (uint256 i = 0; i < recipients.length; i++) {
            balances[recipients[i]] += amount;
        }
    }
}

Token Transfer: Optimize token transfers by using batch operations and reducing the number of external calls. It's like sending a bunch of gifts in one go instead of individual parcels.

6. Conclusion

And just like that, we've reached the end of our gas adventure! Now, you're not just a casual Ethereum user, you're a gas guru! You know what gas is, why it's important, and how it's used in Ethereum. You're no stranger to gas prices and limits, and you know how to make your smart contracts as gas-efficient as possible.

Here's a quick recap of what we've covered:

• We learned about what gas is, why Ethereum uses it, and how it relates to Ether. Remember the car and fuel analogy? Gas is like the fuel that powers every operation on the Ethereum network.

• We talked about gas in the context of smart contracts. Like how every operation in a contract requires gas, and how running out of gas can lead to an "out-of-gas" error.

• We delved into estimating gas costs, with cool tools like web3's estimateGas function. It's like your gas gauge, telling you how much gas you'll need for a particular transaction.

• And finally, we talked about optimizing smart contracts to use less gas. Because who doesn't like saving money, right?

Remember, the world of Ethereum and smart contracts is always evolving. So keep exploring, keep learning, and keep optimizing. Who knows, maybe you'll be the one to come up with the next big gas-saving technique!

So, keep on cruising, fellow Ethereum enthusiast. The road to blockchain mastery is long, but with your newfound gas knowledge, I have no doubt you'll go far!

7. References

Well, you've made it to the end of our Ethereum gas journey, pal! But hey, the learning doesn't stop here. I've got a bunch of resources to keep you fueled up on your blockchain quest. Check these out:

1. Ethereum Whitepaper: The OG guide to Ethereum. A bit heavy, but worth the read. Check it out

2. Ethereum Yellow Paper: This one dives deep into Ethereum's technical side. Keep this one handy. Have a look

3. Ethereum Gas Station: A site dedicated to real-time gas prices in the Ethereum world. Pretty cool, huh? Take a peek

4. Solidity Documentation: A complete guide to write smart contracts. It's a must-have for every coder. Give it a read

5. Etherscan: Check out Ethereum transactions, contracts, and everything else on the blockchain. Here you go

6. StackExchange Ethereum: Stuck on a problem? Chances are someone else has been too. Find your answers here. Go on, ask away

Remember, the blockchain world is always changing. So, keep up, stay curious, and keep learning. You're on your way to becoming a true Ethereum champ!

Let's talk DB design.

What is Relational Database Design?

Relational Database(DB) Design organizes data in a database into relations, which are one or more tables of columns and rows, with a unique key identifying each row. Rows are also called records or tuples. Columns are also called attributes. Generally, each table/relation represents one "entity type" (such as customer or product). The rows represent instances of that type of entity (such as "John" or "chair") and the columns represent values attributed to that instance (such as address or price).

What is DynamoDB?

Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database designed to run high-performance applications at any scale. It promises consistent single-digit millisecond performance at any scale. DynamoDB charges for reading, writing, and storing data in your DynamoDB tables so it is Pay-as-you-go which means you only pay for exactly what you use.

This performance along with its pricing model is among the factors which make DynamoDB so attractive. The tricky part with DynamoDB is what comes next.

Unlike the relational DB model where each entity gets a separate table and joins are performed to group related data across tables and fetch them together e.g fetching all the products bought by a customer, DynamoDB does not support joins. To tackle this issue, a common design pattern is the single-table model.

What is the Single-Table Design?

In single-table design, all the entities in the DynamoDB database use the same table and by making use of certain structures unique to DynamoDB, individual entities can still be fetched and several common relational access patterns can be performed.

Enough talk! Let's see some modelling

Entities

Let's take three entities to model. These entities could be part of an e-commerce application. They are: customer, product and order. The relationship between them can be defined as such:

• A one-to-many relationship exists between the customer and order entities.

• A many-to-many relationship exists between the order and product entities.

Modelling a Relational Design

To represent this in relational design, we'd have something like this:

Here we have the classic schema with a different table for each entity and a join OrderProduct table for modelling the many-to-many relationship between the Order and Product entities. With this, we can get all the information we need about the various entities and perform joins to retrieve information about the relationship between entities like the names of products in an order, the orders a customer has made and so on.

Modelling DynamoDB's Single-Table Design

Unlike relational design where we start by representing the entities in tables and figure out the queries we need to retrieve the data from the table when modelling in DynamoDB, we need to first know the queries we need before creating the table. This is crucial in allowing us to perform queries efficiently because of DynamoDB's query structure.

• Listing data access requirements: Of course, you don't have to write out every possible access pattern your application might need, you just want to identify the core access patterns. Since these entities are being used in the context of an e-commerce application, a few queries we might need are:

  1. Get all orders that belong to a customer.

  2. Get information about all the products in an order.

  3. Get all the orders made for a particular product.

  4. Sort a customer's orders by price.

In a real-world application, there would be much more access patterns depending on what the business requirements are but these three will do for now.

DynamoDB's query structure

DynamoDB tables consist of items that are themselves a collection of key-value pairs. The keys of the items are referred to as attributes, examples of attributes on an item could be; name, price, date etc. For the most part, like most NoSQL databases DynamoDB doesn't enforce strict conditions when creating tables save for a few rules.

One of the important conditions though is the primary key. Let me explain, the primary key of an item uniquely identifies it among other items in a table and you specify what the primary key of items in a table is when you create it. The primary key can either be:

• a simple primary key which consists of an attribute specified as a partition key, or

• a composite key which consists of two attributes, a partition key and a sort key.

When querying the data in a table, you can use a key condition expression to specify criteria to match the primary key on and an optional filter expression to further refine the results based on other attributes items might have. In DynamoDB, the pricing on a query depends on the number of items that match the key condition expression, regardless of how many items you decide to then filter out with a filter expression as such it becomes important to structure our data such that we can perform most if not all our access patterns with key condition expressions.

Designing the DynamoDB table

The key entities can be represented in a single table using the pattern below. Where PK means partition key and SK means sort key:

ENTITYPKSK CUSTOMERCUSTOMER#[customer id]CUSTOMERINFO#[customer name] ORDERCUSTOMER#[customer id]ORDER#[order id] PRODUCTPRODUCT#[product id]PRODUCTNAME#[product name]

This table design allows us to get orders that belong to a customer by querying the partition key and sort key with the appropriate prefixes and the customer's id e.g with the key condition expression: PK = CUSTOMER#[customer id] and begins_with(SK, "ORDER#"), we can also get a customer's details by a combination of the customer's id and the CUSTOMER_INFO# prefix.

Having the entities represented here is nice but this design doesn't provide us with an efficient way of querying the orders made for a product or getting the details of products in an order per our required access patterns above.

To fix that we'll add an order-product representation to our table for the relationship between an order and a product. For the PK and SK we'll use the structures CUSTOMER#[customer id]#ORDER#[order id] and PRODUCT#[product id] respectively. This allows us to get the list of products in an order with the key condition expression: PK = CUSTOMER#[customer id]#ORDER#[order id] and begins_with(SK, "PRODUCT#"). An example of what our table looks like with some dummy data is shown below:

To fetch orders that a product is a part of, we need to be able to query the order-product representation by the product id directly. To do this, we add a Global secondary index (GSI) to the table. This allows us to create a partition key and a sort key different from those defined on the table. We can add new GSIPK and GSISK attributes to the order-product representation which will be the partition key and sort key for the new index respectively.

For the order-product representation, we'll store:

• PRODUCT#[product id] in GSIPK, and

• CUSTOMER#[customer id]#ORDER#[order id] in GSISK

Resulting in a new table that looks like this:

Now we can perform a query with the key condition expression: GSIPK = PRODUCT#[product id] on the new GSI. This fetches all the order-product entries with that product id. Visualizing the new GSI, we have:

Finally, to sort a customer's orders by price, we need to add a sort key on the price value of an order. This is because, by default, query results are always sorted by the sort key value and optionally ordered in either ascending or descending order. Currently, the order representation has a partition key CUSTOMER#[customer id] and a sort key ORDER#[order id]. To add a new sort key here, we need to create another index, this time a Local Secondary Index (LSI) on the orderPrice attribute.

While a GSI creates a new primary key (partition and sort key), an LSI only creates a new sort key on the preexisting partition key. This allows us to sort the item collections under a partition key based on several attributes, in this case, based on the orderPrice attribute. The query to fetch a customer's orders sorted by price would now be a key condition expression: PK = CUSTOMER#[customer id] on the new LSI.

Review

At the end of our modelling, our table has:

• a main composite key: PK and SK.

• a local secondary index (LSI): Partition key is PK and sort key is orderPrice.

• a global secondary index (GSI): Partition key is GSIPK and the sort key is GSISK.

Our access patterns have been handled:

1. Get all orders that belong to a customer.
   key condition expression: PK = CUSTOMER#[customer id] and begins_with(SK, "ORDER#")

2. Get information about all the products in an order.
   key condition expression: PK = CUSTOMER#[customer id]#ORDER#[order id] and begins_with(SK, "PRODUCT#")

3. Get all the orders made for a particular product.
   key condition expression: GSIPK = PRODUCT#[product id] on the new GSI

4. Sort a customer's orders by price.
   key condition expression: PK = CUSTOMER#[customer id] on the new LSI.

Conclusion

In conclusion, while relational database design keeps data normalized, DynamoDB isn't a slouch either. It does not allow for joins, but by modelling your data properly or using certain patterns like the single-table pattern join-like queries can be performed. There are certainly more hoops to jump through when designing an effective data solution for DynamoDB but the advantages once done can be considerable.

As such, if you're considering using DynamoDB over a relational database solution, like a lot of things in software engineering, it would depend on your particular use case, business requirements, access patterns, budget etc. So let me know in the comments, in which use cases would you favour DynamoDB over a relational database solution?

Cheers!

I find it fascinating how Telegram opens itself up to users and developers alike, its extensibility as a platform makes it possible to do so many things with it. Recently, I've been working on a bot of my own. It's a bit large and I've enjoyed working on it so I thought I'd write about building one. To that end, we're going to be building a Telegram food bot. Our food bot is going to do a few things:

• Show a list of available cuisines.

• Fetch recipes for a cuisine.

• Get preparation instructions for a recipe.

To accomplish these things we're going to be using the spoonacular API. The code for this tutorial is on github and the bot is deployed on Heroku if you want to check it out on telegram.

Prerequisites

To follow along with this tutorial, you need to have:

• Node v14.7.1 or above installed

• A good understanding of TypeScript

• Basic knowledge of Axios

Setup

Getting a bot token from botfather

Following the instructions on telegram's bot page, you'll need to create an access token for the bot:

Keep that safe you'll be needing it.

Getting an API key from Spoonacular

You need to first create an account on Spoonacular. Once logged in, you can get your API key under the profile section of your dashboard.

Bootstrapping a TypeScript project

Next, we have to set up a TypeScript project. Going into all the steps involved here would make this much longer so I created a project starter that we can just use instead. To get started you can clone this repo or if you're on a Linux terminal just run:

git clone https://github.com/RinwaOwuogba/ts-template-project.git
mv ts-template-project/ telegram-food-bot/
cd telegram-food-bot/
rm -rf ./.git
rm README.md

These commands clone the project locally and delete git files from the cloned repository.

We can then rename the folder. In this case, we're renaming it to telegram-food-bot. And I know that's a bit on the nose but hey, KISS.

Adding bot dependencies

We need to add the dependencies we need for this specific project.

yarn add telegraf telegraf-inline-menu axios express dotenv
yarn add -D @types/node @types/express

Add .env file

To load environmental variables in development, we're using the dotenv module. dotenv allows us to load environmental variables from a .env file. Create a .env file in the root directory of your project then add some of the variables we'll need:

BOT_TOKEN=[YOUR_BOT_TOKEN_FROM_BOT_FATHER]
SPOONACULAR_API_KEY=[YOUR_API_KEY_FROM_SPOONACULAR]
# if you decide to deploy
APP_URL=[URL_FOR_YOUR_BOT]

Create a configuration file

Create a src/config.ts file. I prefer to use a config file to reference environment variables. It keeps it so that any general changes to those variables happen in one place and not all over the codebase. We'll populate it with this:

import { config as dotenvConfig } from 'dotenv';

// loads environmental variables from .env file
// when in development
if (process.env.NODE_ENV !== 'production') {
  dotenvConfig();
}

const config = {
  appUrl: process.env.APP_URL,
  telegramBot: {
    token: process.env.BOT_TOKEN || 'xxxx',
    webhookUrl: `${process.env.APP_URL}${process.env.BOT_TOKEN}` || 'xxxx',
  },
  isProduction: process.env.NODE_ENV === 'production',
  port: process.env.PORT || 4000,
  spoonacular: {
    apiKey: process.env.SPOONACULAR_API_KEY || 'xxxx',
  },
};

export default config;

The structure of the config file is based on personal preference, the only thing here that might seem weird is the webhookUrl key which is a URL for Telegram to call when sending updates to the bot e.g new messages. Its structure is based on telegram's suggestions for security reasons.

Add basic types

Create a src/types.ts file. Here we'll define the custom type definitions we need for the bot.

import { Context } from  'telegraf';


/**
* All bot commands.
*/
export enum FoodBotCommands {
    showCuisines = 'show_cuisines',
}

/**
* Additional data passed in context
*/
interface  ISessionData {
    page?: number;
    itemCount?: number;
}

/**
* Custom context to contain additional context fields
*/
export  interface  IFoodContext  extends  Context {
    session: ISessionData;
    match: RegExpExecArray | undefined;
}

FoodBotCommands defines the list of telegram commands that the bot will make available to users, we only have one command but a larger bot would have a much larger list.

Telegraf creates a Context instance for every incoming update which like the name implies represents the context the update is coming from - details about the telegram user, message that triggered the update etc. IFoodContext defines additional fields that the bot is going to need but aren't available in the default Context type, more on it later.

The reason for the different casing styles in the FoodBotCommands enum is because of telegram's naming convention for bot commands which doesn't allow uppercase characters thus restricting us to snake case.

Setup command handlers

Messages sent to the bot trigger updates from telegram. We need to define handlers for those updates. Create a src/telegram/handlers.ts and populate with:

import { Telegraf } from 'telegraf';
import { FoodBotCommands, IFoodContext } from '../types';

// set up bot update handlers
const botCommandHandlers = (bot: Telegraf<IFoodContext>): void => {
  // Sends a default response to text that doesn't match
  // any registered commands
  bot.on('text', async (ctx) =>
    ctx.reply(
      `Hello! I'm SimpleCuisineBot. I know a ton ` +
        `of recipes, you just need to select a ` +
        `cuisine to get started: \n\n` +
        `/${FoodBotCommands.showCuisines}`
    )
  );

  // default error handler
  bot.catch(async (error: unknown, ctx) => {
    console.log('Bot error', error);

    await ctx.reply('Sorry, something went wrong while handling your message.');
  });
};

export default botCommandHandlers;

There are different handlers for different types of updates, the bot.on("text") is the default handler for any text message. Handlers are matched in the order they are defined so we'll add more specific handlers above it and leave messages that don't match any other handlers to it. In this case, we're sending a default message in the default handler.

bot.catch is the default handler for any errors that occur in the application. We'll add more error handling logic later.

Create session middleware

If you recall in src/types we defined IFoodContext, in which we added additional properties to the default Context created by Telegraf. Among them was a session property, to make sure that this property is available in all instances of Context in the event handlers we need to create a custom middleware to create in on every update. Create a src/telegram/middlewares/createSession.ts file. Add the following code:

import { MiddlewareFn } from  'telegraf';
import { IFoodContext } from  '../../types';

/**
* Adds session property to the user context
* whenever a request is received
* */
const  createSession: MiddlewareFn<IFoodContext> = async (ctx, next) => {
    Object.assign(ctx, { ...ctx, session: {} });

    return  next();
};

export  default  createSession;

Initialize the bot

Create a src/telegram/index.ts file. Here's where the telegram bot will be initialized. We're going to add middlewares, setup handlers for commands sent to the bot, send telegram a list of all the commands that the bot handles and set up the mechanism for receiving updates from telegram:

import { Telegraf } from 'telegraf';
import { BotCommand } from 'telegraf/typings/core/types/typegram';
import config from '../config';
import { IFoodContext, FoodBotCommands } from '../types';
import botCommandHandlers from './handlers';
import createSession from './middlewares/createSession';

// list of commands the bot will handle
export const botCommands: readonly BotCommand[] = [
  {
    command: FoodBotCommands.showCuisines,
    description: 'show available cuisines',
  },
];

export const bot = new Telegraf<IFoodContext>(config.telegramBot.token);

export const startTelegramBot = async (): Promise<void> => {
  // register middlewares
  const middlewares = [createSession];
  middlewares.forEach((middleware) => bot.use(middleware));

  // setup command handlers
  botCommandHandlers(bot);

  // register available bot commands on telegram server
  await bot.telegram.setMyCommands(botCommands);

  if (!config.isProduction) {
    // use polling mode in development
    bot.launch();
    console.log("Bot polling for updates..")
  } else {
    // use telegram webhookurl in prod
    bot.telegram.setWebhook(config.telegramBot.webhookUrl);
  }
};

The structure of each botCommand in the botCommands list is dictated by the BotCommand type. botCommands list is the argument to bot.telegram.setMyCommands which sends telegram the list of commands.

In order to receive updates from telegram such as new messages, we can either use polling mode or provide a webhookUrl for telegram to call whenever there's an update. We're going to use polling mode while building the bot locally and set a webhookUrl when in production (in case you want to deploy the bot).

Add webhook handler

Create a src/api/index.ts file:

import express from 'express';
import config from '../config';
import { bot } from '../telegram';

const app = express();

// webhook to handle updates from telegram in prod
app.use(bot.webhookCallback(`/${config.telegramBot.token}`));

export default app;

The path to the webhook handler is the same as config.telegramBot.webhookUrl since we're just adding a /config.telegramBot.token route to the base app URL.

bot.webhookCallback passes messages received from Telegram by calls to this route to the bot.

Start the project

In src/index.ts we'll add code to start the bot.

import  app  from  './api';
import  config  from  './config';
import { startTelegramBot } from  './telegram';

const  startProject = async () => {
    // initialize telegram bot
    try {
        await startTelegramBot();
        console.log('Bot initialized successfully');
    } catch (error) {
        console.log('Something went wrong while initializing bot');
        console.log(error);
        process.exit(1);
    }

    // start API server
  app
    .listen(config.port, () => {
      console.info(`Server listening on port: ${config.port}`);
    })
    .on('error', (error) => {
      console.error(error);
      process.exit(1);
    });
};

startProject();

If we encounter any errors while initializing the bot or starting the server, we terminate the process.

Since we're using polling mode for development, the API server will only be started in a production environment.

At this point the structure of your project should look like this:

├── .env
├── package.json
├── src
│   ├── api
│   │   └── index,ts
│   ├── config.ts
│   ├── index.ts
│   ├── telegram
│   │   ├── handlers.ts
│   │   ├── index.ts
│   │   └── middlewares
│   │       └── createSession.ts
│   └── types.ts
├── tsconfig.json
└── yarn.lock

Building the features

Show a list of available cuisines

From the Spoonacular API docs, I've gathered a list of the available cuisines so we'll be using that. Create a src/cuisineList.ts file for the cuisines:

const cuisineList: string[] = [
  'african',
  'american',
  'british',
  'cajun',
  'caribbean',
  'chinese',
  'eastern european',
  'european',
  'french',
  'german',
  'greek',
  'indian',
  'irish',
  'italian',
  'japanese',
  'jewish',
  'korean',
  'latin american',
  'mediterranean',
  'mexican',
  'middle eastern',
  'nordic',
  'southern',
  'spanish',
  'thai',
  'vietnamese',
];

export default cuisineList;

We'll use a telegram inline menu to display the list of available cuisines and to create the menus we are going to make use of telegraf-inline-menu to which we installed earlier.

First, we need to update our types in src/types.ts. We need an additional cuisines field in ISessionData, which will contain a list of recipes

interface ISessionData {
  cuisines?: string[];
  page?: number;
  itemCount?: number;
}

Also, we need to create a src/constants.ts file for a few constants that we'll be needing such as the API URL and the number of rows to display on each menu page. I set it to five here but you can make it any number you want:

export  const  SPOONACULAR_API_URL = 'https://api.spoonacular.com';

// maximum number of rows in any menu page
export  const  MAXIMUM_MENU_ROWS = 5;

Next, for the cuisine list menu itself, create a src/telegram/menus/cuisineListMenu.ts file:

import { Body, MenuTemplate } from 'telegraf-inline-menu/dist/source';
import { ConstOrContextPathFunc } from 'telegraf-inline-menu/dist/source/generic-types';
import { IFoodContext } from '../../types';
import cuisineList from '../../cuisineList';
import { MAXIMUM_MENU_ROWS } from '../../constants';

const cuisineListMenuLogic: ConstOrContextPathFunc<IFoodContext, Body> = (ctx) => {
  const { page } = ctx.session;

  // no of cuisines to skip in current menu page
  let offset = 0;

  // skip cuisines in previous pages
  if (page) {
    offset = (page - 1) * MAXIMUM_MENU_ROWS;
  }

  // list of cuisines to display for current menu
  // page
  ctx.session.cuisines = cuisineList.slice(
    offset,
    offset + MAXIMUM_MENU_ROWS + 1
  );

  // store total cuisine count to allow pagination method
  // calculate no of pages in current menu
  ctx.session.itemCount = cuisineList.length;

  const text = 'Select a cuisine to get recipes for';

  return text;
};

const cuisineListMenu = new MenuTemplate<IFoodContext>(cuisineListMenuLogic);

// add cuisines in list to menu
cuisineListMenu.choose('selectedCuisine', (ctx) => ctx.session.cuisines || [], {
  do: async (ctx, key) => {
    await ctx.reply(`You selected ${key} cuisine!`);
    await ctx.answerCbQuery();

    return false;
  },
  buttonText: (ctx, key) => key,
  disableChoiceExistsCheck: true,
  maxRows: MAXIMUM_MENU_ROWS,
  columns: 1,
});

// add buttons to paginate cuisine list over several
// menu pages
cuisineListMenu.pagination('cuisineListPagination', {
  setPage: (ctx, page) => {
    ctx.session.page = page;
  },
  getCurrentPage: (ctx) => ctx.session.page,
  getTotalPages: (ctx) => (ctx.session.itemCount as number) / MAXIMUM_MENU_ROWS,
});

export default cuisineListMenu;

Alright, let's talk about what the code above is doing:

We start by defining cuisineListMenuLogic which is a function to initialize the cuisineListMenu. This function is run whenever the menu is loaded or reloaded.

To keep the menu interface neat we're going to split the static list of cuisines over several pages and cuisineListMenuLogic is where we put the logic to determine the cuisines to be displayed on the current page of the menu.

In cuisineListMenuLogic we try to determine the current page we're on and using the current page number in addition to the number of rows to display per menu page we select the cuisines to be displayed on the current page. We then store the current list of cuisines to display and the total number of cuisines altogether in ctx.session to make it available to other functions in the menu.

const cuisineListMenu = new MenuTemplate<IFoodContext>(cuisineListMenuLogic);

Afterwards we instantiate cuisineListMenu .

The .choose method on a menu creates a group of buttons on the menu and attaches an action to be performed whenever any of the choices is selected. It takes an action prefix, a list of choices and options to configure the behaviour of this group of buttons respectively.

• action prefix: Every sub-menu, menu or group of buttons attached to a menu in telegraf-inline-menu requires an identifier, it can be anything but identifiers for all paths under a specific menu have to be unique. Here selectedCuisine is the action prefix.

• choices: Choices the user can pick from. The choices here are the list of cuisines on the current page.

• options:

  • do: is the action to be performed when an option is selected. Currently, we send a message containing the selected cuisine's name whenever a cuisine is selected by using ctx.reply. ctx.reply is a shorthand method for sending messages back to the chat in the current context. ctx.answerCbQuery is a shorthand method to let telegram know that the action for that choice has been completed so it stops displaying a progress bar for it. The return value of this function determines the behaviour of the menu after the action is completed, returning false makes the menu do nothing.

  • buttonText: is used to determine the text to be displayed on the buttons added to the menu. We use the key which is the name of each cuisine for its respective button text.

  • disableChoiceExistsCheck: telegraf-inline-menu tries to prevent choices not present from being selected. Since we build the choices dynamically by selecting a range of cuisines when the menu is initially loaded or reloaded then by the time a user selects a cuisine, the check for the choice would always fail since the cuisine list would be empty so we need to disable it.

  • maxRows: Number of rows to use in displaying cuisines on each menu page.

  • columns: Number of columns to use in displaying cuisines.

Next, we set up the pagination buttons for the menu by calling the .pagination method. .pagination takes an action prefix and pagination options. Let's go over the pagination options:

• setPage: Function to run whenever a page is selected

• getCurrentPage: Returns the current page the menu is on.

• getTotalPages: Used in creating the navigation buttons for a menu. We calculate the number of pages here by using the total number of cuisines and the number of rows to be used in displaying cuisines on each page.

To use this menu in the bot we need to create a menu middleware. Create a src/telegram/middlewares/menuMiddleware.ts file:

import { MenuMiddleware } from 'telegraf-inline-menu/dist/source';
import { IFoodContext } from '../../types';
import cuisineListMenu from '../menus/cuisineListMenu';

/**
 * Middleware needed to track and respond to inline
 * menu button clicks
 */
const menuMiddleware = new MenuMiddleware<IFoodContext>('/', cuisineListMenu);

export default menuMiddleware;

MenuMiddleware takes a root menu to render by default and a root path for that menu.

Register this middleware in src/telegram/index.ts:

import  menuMiddleware  from  './middlewares/menuMiddleware';

// register middlewares
const  middlewares = [createSession, menuMiddleware];

Finally, add a command handler to render cuisineListMenu. Let's add a new handler in src/telegram/handlers.ts.

import  menuMiddleware  from  './middlewares/menuMiddleware';

// show list of all cuisines
bot.command(FoodBotCommands.showCuisines, async (ctx) =>
  menuMiddleware.replyToContext(ctx)
);

.replyToContext sends a menu in response to a message. Since we didn't specify a path argument, menu middleware sends the default cuisineListMenu.

Start the bot locally by running:

yarn run dev

You'll see an output like this on the console:

Finding the bot on telegram

Messaging the bot we get:

Fetch recipes for a specific cuisine

Users should get a list of recipes when they select a cuisine. The list of recipes for a particular cuisine will also be displayed on a menu.

First, we need to update our types in src/types.ts. We need an additional recipes field in ISessionData, which will contain a list of recipes

interface ISessionData {
  recipes?: IRecipe[];
  cuisines?: string[];
  page?: number;
  itemCount?: number;
}

Add a few additional types:

/**
 * Recipe item returned by spoonacular
 */
export interface IRecipe {
  id: number;
  title: string;
  image: string;
  imageType: string;
}

/**
 * Spoonacular recipes search response
 */
export interface IRecipesResponse {
  results: IRecipe[];
  offset: number;
  number: number;
  totalResults: number;
}

IRecipe represents a recipe item returned by the spoonacular API.

IRecipesResponse represents the result of requesting a list of recipes under a particular cuisine.

Create a new src/telegram/menus/recipeListMenu.ts file. We'll define the recipeListMenu to display the recipes under a cuisine.

import axios from 'axios';
import { createBackMainMenuButtons, MenuTemplate } from 'telegraf-inline-menu';
import { ConstOrContextPathFunc } from 'telegraf-inline-menu/dist/source/generic-types';
import { SPOONACULAR_API_URL, MAXIMUM_MENU_ROWS } from '../../constants';
import config from '../../config';
import { IFoodContext, IRecipesResponse } from '../../types';

/**
 *  Fetch recipes from spoonacular
 */
const fetchRecipes = async (cuisine: string, page: number) => {
  const { data } = await axios.get<IRecipesResponse>(
    `${SPOONACULAR_API_URL}/recipes/complexSearch`,
    {
      params: {
        apiKey: config.spoonacular.apiKey,
        cuisine,
        number: MAXIMUM_MENU_ROWS, // number of recipes to return at a time
        // skip recipes in previous pages
        offset: page * MAXIMUM_MENU_ROWS,
      },
    }
  );

  return data;
};

/**
 * Logic for controlling recipe list menu
 */
const recipeListMenuLogic: ConstOrContextPathFunc<IFoodContext, string> =
  async (ctx) => {
    const { page } = ctx.session;
    const cuisine = ctx.match ? ctx.match[ctx.match.length - 1] : '';

    // check that selected cuisine is not empty
    if (!cuisine) {
      throw new Error('Cuisine not provided');
    }

    // fetch recipes list from spoonacular
    const data = await fetchRecipes(cuisine, page ? page - 1 : 0);

    let text = '';

    if (data.results.length === 0) {
      text = 'There are no recipes available for the selected cuisine:';
    } else {
      text = `Here are the recipes available for the selected cuisine '${cuisine}' :`;
      ctx.session.recipes = data.results;
      ctx.session.itemCount = data.totalResults;
    }

    return text;
  };

/**
 * Menu to list all recipes
 * */
const recipesListMenu = new MenuTemplate<IFoodContext>(recipeListMenuLogic);

// Add each available recipe to menu
recipesListMenu.choose(
  'showRecipe',
  (ctx) => {
    const { recipes } = ctx.session;

    // constructs choices list out of recipe ids
    return recipes ? recipes.map((recipe) => recipe.id) : [];
  },
  {
    do: async (ctx, key) => {
      await ctx.reply(`Recipe ID: ${key}`);
      await ctx.answerCbQuery();

      return false;
    },
    buttonText: (ctx, key) => {
      const { recipes } = ctx.session;

      const currentRecipe = recipes?.find(
        (recipe) => recipe.id === Number(key)
      );

      return currentRecipe ? currentRecipe.title : '';
    },
    columns: 1,
    disableChoiceExistsCheck: true,
    maxRows: MAXIMUM_MENU_ROWS,
  }
);

// Paginates recipes results
recipesListMenu.pagination('recipeListItem', {
  setPage: (ctx, page) => {
    ctx.session.page = page;
  },
  getCurrentPage: (ctx) => ctx.session.page,
  getTotalPages: (ctx) => (ctx.session.itemCount as number) / MAXIMUM_MENU_ROWS,
});

// enable navigating to previous and main menu
recipesListMenu.manualRow(
  createBackMainMenuButtons('previous', 'Back to cuisines list')
);

export default recipesListMenu;

That's a lot, let's go through what each section is doing:

To start with, fetchRecipes is a utility function that fetches a list of recipes for a particular cuisine from the spoonacular API. It uses Axios to make an HTTP request and we define the response data type as the IRecipesResponse type we just added to src/types.ts.

The /recipes/complexSearch endpoint takes a number of parameters which you can check on the offical docs but we're only using four of them for the purpose of this tutorial:

• apiKey: This is your API key from Spoonacular and is required for every API call.

• cuisine: Cuisine name to get recipes for

• number: Number of recipes to return at a time. We're making use of the MAXIMUM_MENU_ROWS constant we created earlier since the number of recipes we show at a time is limited.

• offset: Number of recipes to skip. We use this in addition to the number param to paginate the returned recipes list.

recipeListMenuLogic is the function that recipeListMenu runs when loaded. Remember that menus have identifier's? The full path to a menu is included in ctx.match and the selected cuisine is included in the path so we can get it from there. recipeListMenuLogic then fetches recipes for the selected cuisine from spoonacular and sets a message depending on the API response.

The arguments for recipeListMenu.choose are similar to cuisineListMenu with a few differences:

• For the list of choices, we return the recipe IDs instead of the recipe names because the full path to each choice is included in the callback data for each button representing a choice on the menu and Telegram limits the size of callback data to 1 - 64 bytes. Since some recipes might have really long names, using their IDs is more reliable.

• do: sends the recipe ID when a choice is selected

• buttonText: tries to get the matching recipe name for each recipe ID passed to it as a key.

We then add pagination to this menu and then manually create a new row of buttons on the menu using recipesListMenu.manualRow.

createBackMainMenuButtons create buttons to navigate to the previous menu if the previous menu is not the root menu and to the root menu directly. The arguments to it are the names to be shown on each button which are the previous menu button text and the root menu button text respectively. Since recipeListMenu is only one path down from the cuisineListMenu, only the root menu navigation button will be displayed.

Next, we have to connect cuisineListMenu and recipeListMenu such that when a cuisine button is selected, the recipes for that cuisine are displayed.

Update src/telegram/menus/cuisineListMenu.ts. Replace cuisineListMenu.choose with a new cuisineListMenu.chooseIntoSubmenu:

import recipesListMenu from './recipeListMenu';

// Show cuisine recipes when cuisine is selected
cuisineListMenu.chooseIntoSubmenu(
  'recipeList',
  (ctx) => ctx.session.cuisines || [],
  recipesListMenu,
  {
    buttonText: (ctx, key) => key,
    disableChoiceExistsCheck: true,
    maxRows: MAXIMUM_MENU_ROWS,
    columns: 1,
  }
);

Now, let's test the bot so far:

Get preparation instructions for a specific recipe

To display preparation instructions on selecting a specific recipe, we start by adding even more types to src/types.ts:

/**
 * Individual recipe instruction step
 */
interface IRecipeStep {
  number: number;
  step: string;
  ingredients: {
    name: string;
  }[];
}

/** Recipe instructions from spoonacular */
interface IRecipeInstructions {
  name: string;
  steps: IRecipeStep[];
}

/**
 * Full recipe information from Spoonacular
 */
export interface IRecipeInformation {
  title: string;
  image: string;
  extendedIngredients: {
    original: string;
  }[];
  analyzedInstructions: IRecipeInstructions[];
}

IRecipeInformation represents a part of the full details of a recipe that we're concerned with as returned by spoonacular. We've broken this information into several types simply to make it easier to reason about

IRecipeInstructions represents the preparation instructions for a recipe and IRecipeStep is each of the individual steps to be followed in order.

Next, we have to update src/telegram/menus/recipeListMenu.ts:

• Update the imports:

  import { IFoodContext, IRecipeInformation, IRecipesResponse } from  '../../types';
  

• Create a new function to send the recipe instructions rather than a simple message containing the recipe ID:

  /**
  * Show recipe information on telegram
  */
  const showRecipeInformation = async (ctx: IFoodContext, recipeId: string) => {
    const { data } = await axios.get<IRecipeInformation>(
      `${SPOONACULAR_API_URL}/recipes/${recipeId}/information`,
      {
        params: {
          apiKey: config.spoonacular.apiKey,
        },
      }
    );
  
    // format list of ingredients
    const ingredients = `Ingredients needed for this recipe are:\n\n${data.extendedIngredients
      .map((ingredient) => `- ${ingredient.original}`)
      .join('\n')}`;
  
    // format recipe instruction steps
    const instructions =
      `Steps to prepare:\n\n` +
      `${
        data.analyzedInstructions.length
          ? data.analyzedInstructions[0].steps
              .map((step) => `${step.number}. ${step.step}`)
              .join('\n\n')
          : 'No steps to display 😅'
      }`;
  
    // full message
    const message = `${data.title}\n\n${ingredients}\n\n\n${instructions}`;
  
    await ctx.replyWithPhoto(data.image);
    await ctx.reply(message);
    await ctx.answerCbQuery();
  
    return false;
  };
  

  In showRecipeInformation, we fetch the information for a recipe then concatenate the recipe name with its list of ingredients and instruction steps into a single message.

Then we send a picture of the finished recipe along with the concatenated message to the user.

• Pass the new function to do in recipeListMenu.choose:

  do:  async (ctx, key) =>  showRecipeInformation(ctx, key),
  

  Let's start the bot locally to test again:

And everything works fine!

We're almost done, we just need to update our error handling logic. Update bot.catch in src/telegram/handlers.ts:

• Update the imports

import { AxiosError } from  'axios';
import { CallbackQuery } from  'telegraf/typings/core/types/typegram';

• Update the function in bot.catch:

  // default error handler
  bot.catch(async (error: unknown, ctx) => {
   console.log('Bot error', error);
  
   // remove progress bar from menu button on error
   if ((ctx.callbackQuery as CallbackQuery.DataCallbackQuery)?.data)
     await ctx.answerCbQuery();
  
   // handle axios errors
   if ((error as AxiosError).isAxiosError) {
     const status = (error as AxiosError).response?.status;
  
     // handle daily quota limit error from Spoonacular
     // https://spoonacular.com/food-api/docs#Quotas
     if (status === 402) {
       await ctx.reply(
         '😅 Sorry, we seem to have reached our daily quota limit for the ' +
           'spoonacular API and cannot handle any more requests today'
       );
  
       return;
     }
   }
  
   await ctx.reply('Sorry, something went wrong while handling your message.');
  });
  

  We're dealing with two things here:

  • Remember that telegram uses callback data to handle menu logic? So we call ctx.answerCbQuery if an error occurs while handling a message that has callback data to notify Telegram to stop showing a progress bar for that menu item.

  • Spoonacular has daily quota limits for requests to its API. Once this limit is exceeded, all API calls are rejected with an HTTP status code402. So we need to handle that error when it occurs in an Axios request.

And that's all!