本篇文章，我们将向我们自己的UniswapV2源码中添加核心的功能——swapping。Uniswap创建的目的就是能够实现去中心化的代币交换，我们一起来看看它是如何完成的。我们会依然专注于核心的配对合约，我们还没开始构建可用的前端交互界面，也并不会进行价格计算。

前言中间件（Middleware），一个听起来就很高级、很强大的功能。实际上也确实如此。使用中间件，你可以拦截并控制应用里的所有请求和响应。比如你可以基于传入的请求，重写、重定向、修改请求或响应头、甚至直接响应内容。

智能合约从技术角度实现了"codeislaw"，在智能合约的世界里，代码本身就是法律规则的体现。这一理念的核心是，智能合约是自执行的协议，由编写好的代码直接控制，无需中介或第三方干预。

路由处理程序是指使用WebRequest和ResponseAPI对于给定的路由自定义处理逻辑。简单来说，前后端分离架构中，客户端与服务端之间通过API接口来交互。这个API接口在Next.js中有个更为正式的称呼，就是路由处理程序。

CREATE2是Solidity中的一个操作码，用于创建新的智能合约。它是在以太坊的君士坦丁堡硬分叉中引入的。

Uniswap是一个运行在以太坊区块链上的去中心化交易所。它完全是自动化的、非托管的、去中心化的。它经历了多次的迭代开发。目前线上稳定运行的是第三个版本。之前关于UniswapV1的系列文章中，我展示了如何从头开始构建它并解释了它的核心机制。

在前面的两篇文章中，我们已经已经实现了Exchange合约的所有核心机制，包括定价功能、交换、LP代币和费用。看起来已经比较完善了，但是还缺少了一部分：工厂合约。本篇文章，我们就来实现它。

这是我们系列文章的的第二部分。在上一篇中，我们了解了Uniswap及其核心机制，并开始构建交换合约。该合约可以接受用户的流动性、计算输出相应的代币数量并执行交换。本篇文章，我们将完成UniswapV1的实现。

ERC191是以太坊上的一个代币标准提案，全称是"EthereumRequestforComment191"。

实际项目开发的时候，有的路由场景会比较复杂，比如数据库里的文章有很多，我们不可能一一去定义路由，此时该怎么办？组织代码的时候，有的路由是用于移动端，有的路由是用于PC端，该如何组织代码？