上篇中大概阐述了一下我们之前碰到过的一些应用开发中的痛点：
- 现有的云数据库起步使用成本较高
- 应用开发对团队的起步要求较高
- 现有云数据库配置复杂
这些痛点当然不是我们先发现的，也不是我们先要尝试解决的。Google早在2014年就收购了firebase，或许是对这些痛点认可的最佳佐证。
就在前两天，InfoQ上发布了一篇翻译文章：未来会怎样构建Web应用程序，这其实是作者的副标题，原标题是Database in the Browser, a Spec，文章写的挺有意思。不论是web应用还是移动app，数据库的使用都是一个绕不过去的话题，作者从一个新颖的切入点来描绘了未来web应用开发的新思路，其中一些观点跟我们正在做的事情不谋而合。
言归正传，上篇我们抛出了3个问题，下面一一应答。
即用即付
即用即付，不用不付。 对于开发者来说，这应该是云服务最理想的使用方式。 大多数应用在最初甚至很长一段时间内用户增长是比较缓慢的，有些应用甚至就专门是给自己、家人和伙伴使用的，我们希望这些应用也能随时随地的使用我们的数据库云服务资源。 memfiredb.com的数据库云服务会采取即用即付模式，包括后续推出的各种服务，我们都将尽最大可能以即用即付的模式进行交付。并且每个月都会赠送较大额度的免费套餐，对个人开发者来说，免费资源应该是比较充裕的。
后端服务
围绕数据库开发的应用，有的时候大多数后端业务逻辑都是在进行CURD操作，是否可以将CURD操作抽象成REST API，直接供前端业务开发人员调用呢？
如果我们是在开发一个互联网应用，除了数据库操作之外，还有哪些是不能放在前端的呢：
- 用户注册、登录认证、鉴权
- 图片等的存储（比如头像、商品展示）
对于移动应用可能还需要：
- 消息推送
对于一些更复杂的应用可能还需要：
- 邮件服务
- 短信服务
- 云函数
- ......
以上这些功能组件具有很强的独立性，都是可以抽象成公共服务直接开放给应用开发人员的，有了这些基础的轮子，相信web和app开发人员可以更专注于自己的创造上。
我们会从最小可用功能集开始，逐步迭代这些服务组件。
专注易用
从数据库的创建开始，我们希望把复杂的东西隐藏起来，把各种服务组件以最简单直接的方式呈现给开发人员。 - 数据库：一键创建，按需使用，动态扩容。 - 服务：提供方便易用的SDK，开发更便捷。
由衷的希望这些云服务组件能为应用开发带来不一样的体验，你可以基于现有的技术栈使用MemFireDB的云数据库开发自己的服务，也可以基于新的组件服务直接构建你的app。
