BaaS & Headless CMS

Headless CMS

介绍
资源
商业产品
- https://www.contentful.com/，推荐试用，headless cms产品的老大
  - 优点
    - 文档非常完善，把整个产品设计描述得比较清晰，例如data model部分（https://www.contentful.com/developers/docs/concepts/data-model/）
    - 编辑content时，可以编辑内部关联的content，并且带有状态
    - 多语言管理（英语/法语）
    - 支持全文搜索，有es的插件
    - 编辑插件直接自己定制
    - ref可以关联多种类型，不仅仅包含一种（解决了group+group array的问题）
    - 提供预览的api，自己的服务可以通过一定的规则来匹配预览的content
    - 支持es类似语法的全文搜索，以及martketplace支持es，https://www.contentful.com/developers/marketplace/
    - env支持开发、测试、正式的数据分离
    - 支持多人协作时的comment
  - 缺点
    - 没有workflow管理，只有简单的draft+published
    - ref只有1-n或者1-1，没有n-n
- https://kontent.ai/，推荐试用
  - 优点
    - 编辑体验比较干净，带拖拽
    - 自定义workflow
    - 单独针对web的优化（seo meta，https://docs.kontent.ai/tutorials/develop-apps/optimize-for-the-web/creating-seo-friendly-urls）
    - 整个功能的完善度要比contentful更高，目前为止见到最完善、最友好的headless cms
    - 文档非常完善
    - comment功能
- https://prismic.io/，推荐试用
  - 优点
    - slice的设计，让内容编辑者可以创建动态内容（在同一块内容的地方，挑选一种group进行设置）
    - 编辑内容的理解上，比较细腻（link、embed等一些type；image还有size设置）
    - content中tab的设计，估计是做页面内容分块使用的（https://user-guides.prismic.io/en/articles/764589-how-to-prepare-your-content-for-seo）
    - schema编辑支持json+ux的方式，因此可以复制json来生成schema
    - 对于richtext，支持html tag的支持
    - preview sdk+live edit button（https://prismic.io/docs/reactjs/beyond-the-api/in-website-edit-button，https://prismic.io/docs/reactjs/beyond-the-api/in-website-preview）
    - sdk提供得比较非常完善，前后端都有
  - 缺点
    - 没有workflow+role/permission的管理
- https://graphcms.com
  - 优点
    - schema field type支持比较丰富
    - ref支持完整的几种类型（sql like）
  - 缺点
    - permission和workflow的功能暂时还没有
- https://buttercms.com
  - 优点
    - 专门提供了blog类型的page，带有seo的设置
  - 缺点
    - 似乎没有update page/collection 结构的操作
    - get的api，collection没有nested查询出来，需要进行额外二次查询
    - blog的格式非常固定：meta+seo+title+body，author、category、tag的编辑不够灵活可编辑
- https://www.contentstack.com
  - 优点
    - 文档特别完整，关于产品使用和说明都很完善，基本可通过看文档知道是怎样的一个产品
  - 缺点
    - 需要request demo，没有可运行的demo
- https://www.sanity.io/，只是一个headless cms，需要本地运行服务来启动数据编辑，比较不友好
- https://www.storyblok.com/，The Only Headless CMS with a Visual Editor
  - 优点
    - 预览的实现，相当于在preview的html上加了sdk，hack元素，当点击元素时，触发editor进行编辑对应元素的content
    - workflow & branch的setup都很有参考价值
  - 缺点
    - page结构部分和dapt比较类似，难以理解
- https://craftcms.com/
  - 优点
    - data model的设计可参考
    - 预览的UX比较棒，输入完成后重新刷新
    - 设置模板，带有一些简单的模板指令
    - 可以自己进行安装部署，https://github.com/craftcms/cms
  - 缺点
    - 核心概念比较复杂
    - 允许自己部署但是基于php
开源项目
- https://strapi.io/，基于node.js
  - 优点
    - headless cms的基本功能都包含
    - 提供多种db的adapter（包括pg）
    - 代码结构设计比较好，基于插件系统
  - 缺点
    - 数据模型没有保存在db，而是存成本地json，每次修改需要重启server，可能无法部署多台服务
    - 没有过多的sdk和api，restful api只是针对简单的登录、数据curd
    - 没有workflow的设计
    - role & permission的设计，只是针对功能，没有对具体数据实体的操作权限描述
    - relation的实现，多对多的关联表用了id作为主键，而不是用外键的组合作为主键
- https://ghost.org/，基于node.js
  - 优点
    - blog系统确实很简洁，速度也非常快
  - 缺点
    - 但只是管理blog类型的数据，并不能自定义数据结构，适用场景太窄
特性
- custom data model with relation
- assets management (files & images)
- management dashboard
- user & role & permission
- workflow
- reversion
- app & environment
- development
  - restful api
  - graphql
  - webhook
  - sdk
应用场景
- headless cms对标的是wordpress这些cms，主要管理一些类似blog类型的弱逻辑数据，服务的角色是developer和editor，大概工作流如下
  - developer在cms上定义数据模型
  - developer根据数据结构，使用cms提供的sdk/api，写应用的后端和前端代码，并部署应用
  - editor在cms平台上编辑content，content发布后，可以实时更新到应用上

(m)BaaS

介绍
讨论
产品
- https://parseplatform.org/，baas的鼻祖，之前被facebook收购了，但后面facebook又把项目停了（不符合公司战略），后续开源后是目前star最高的BaaS开源项目
  - 优点
    - 有大部分baas所需要具备的功能，文档、api、sdk的周边也比较完善
    - 支持pg和mongodb作为底层数据库；使用pg时，关系的处理和常规关系型数据库的处理基本一致
  - 缺点
    - user没有带phone register/login的逻辑，并且不支持多个email
    - 没有sms的服务
    - 自带的dashboard比较简陋
- https://firebase.google.com/，google的mBaaS平台，目前商用baas中比较火的
  - 优点
    - 除了baas的功能外，还有很多和mobile相关的功能，例如ads、analysis、crash-report、ML tool等
    - 有一套前端/app使用的ui lib
    - 对数据操作甚至提供了transactions
  - 缺点
    - 没有acl模块，如果需要权限控制需要自己写他的security rule
    - 文档关系的设计比较偏向于noSql，没有rdbms的方案
- https://aws.amazon.com/amplify/，aws近两年才推出的baas平台
  - 优点
    - 大部分服务都和aws的服务打通
    - 有一些VR/AR/ML/AI之类的一些功能
  - 缺点
    - 比parse和firebase更加cli工具化更加复杂，对于普通开发者而言上手成本更高
- https://www.leancloud.cn/，早期抄袭parse做的baas，功能和sdk设计上都和parse比较类似，有cn和海外版
  - 优点
    - 比parse多了一些功能，例如phone register/login、im/chat、hosting、sms、game等
    - 文档比较齐全，如果使用parse作为我们自己的baas，要补全哪些功能可以直接参考leancloud的产品实现
- https://www.back4app.com/，parse的托管服务
- https://www.sashido.io/，parse的托管服务
- https://backendless.com/，一个比较常规的baas
特性
- data
  - database
    - schema(less)
    - relation
    - realtime/observe
  - storage
  - cache
- service
  - auth
    - service
      - signup
      - login
      - forget password
      - device management
    - provider
      - email
      - username
      - phone
      - biometric
      - 3rd
      - anonymous
      - custom
  - acl
  - email
  - sms
  - chat
  - notification
- engine（cloud code）
  - function
  - application
  - cron
  - pub/sub
  - queue
    - https://github.com/Automattic/kue
  - hook
- other
  - config
  - image toolkit
  - ML toolkit
- app
  - crash
  - analystic
  - performance
  - dynamic link
  - ads
  - in-app message
- development
  - restful api
  - sdk
    - node.js
    - php
    - js
    - native
  - graphql
- deployment
  - docker
- hosting
应用场景
- baas平台把底层数据库、对象存储、缓存和一些高频使用的服务（用户、权限、推送等）都做了，可以让没有运维资源、云服务基础的开发团队快速开发应用，使用baas的角色主要是developer

BaaS vs Headless CMS

相同点
- 都有数据结构建模（字段和关系）的过程，部分BaaS的底层数据库mongodb这种schemless的noSQL数据库，甚至不需要建模就可以直接使用（运行时自动生成字段）
不同点
- BaaS在产品的定位上更加底层，作为应用开发的服务端基础，给developr使用，因此底层的功能要多很多
- headless cms的定位更上层，一般适用于blog类型的弱逻辑应用，在数据操作上没有过多的封装（联表查询之类的），给developer和editor使用，前者负责定义数据结构和写应用来消费数据，后者负责编辑和发布数据条目
- ** 一种比较理想的架构是，以BaaS作为底层，基于在BaaS的数据层打造headless CMS，把headless CMS看成是一种普通的应用

BaaS vs 目前的开发方式

目前的开发方式
- 运维
  - ec2，应用服务器
  - elb，负载均衡
  - rds，数据库
  - s3，文件存储
  - ses，邮件服务
  - sns，推送
  - sms，短信
  - redis，缓存
  - elasticsearch，搜索
- 开发
  - 使用orm或者原生sql，来curd数据
  - 使用aws sdk，来调用aws的服务（s3、sns、ses）
  - 如果是用laravel这种大而全的框架，auth、acl等高频服务可以用插件的方式安装使用
  - 如果是node.js的框架，auth、acl、notification这类高频服务目前还没有，需要我们自己封装
    - 梳理服务需求
      - 把相关的一些saas（例如auth0）或者产品都review一遍
    - 设计数据库结构
    - 把代码组织成可快速复用的形式
      - 能跑通的样板代码，具体开发时根据用的框架和包进行改写
      - （统一）开发框架中的插件
      - （无语言依赖，无框架依赖，可独立部署）微服务或serverless function
      - （无语言依赖，无框架依赖，可独立部署）微服务的集合，类似于一个小的baas，不过只有service
使用开源的BaaS（Parse）
- 运维
  - 同上
  - parse的服务需要部署，可以和应用服务一起部署
- 开发
  - 使用parse提供的sdk，来curd数据
  - 使用parse提供的sdk，来调用服务
使用商用收费的BaaS（大概率不会使用）
- 运维
  - ec2，应用服务器
  - elb，负载均衡
  - 在BaaS上创建应用
- 开发
  - 使用baas提供的sdk，来curd数据
  - 使用bass提供的sdk，来调用服务
使用BaaS和目前的开发方式相比
- 优点
  - baas的数据方案，节省了一些数据的选型和设计的时间
    - relation data
    - realtime data event
  - * 部分高频service的封装，省去了开发维护的时间
    - auth
    - acl
    - notification
    - chat
  - 一些额外功能的集合（但这些功能对于我们目前来说使用频率比较低，或者可以用别的方式来实现）
    - serverless function
    - config
    - firebase在app和ml的功能
  - 如果使用的是商用的baas，节省了初始化运维和后续运维的时间
- 缺点
  - * 数据部分和使用db原生方案相比，可能没有那么灵活和强大
    - 事务、存储过程等一些特性
    - sql table join的便捷性
    - 性能优化
    - 字段约束
    - 数据库orm和框架打通
  - * 需要额外学习一整套sdk和api，有一定上手成本
    - 最常用是DB存储的sdk，和原生的db相比也只是sdk不同而已，如果把orm用熟了，使用哪个写差别并不大
    - 对于一些高频service的封装，可以自己整理好设计和需求后，自定义实现，或者找更好的方案，直接用parse的不一定好用或扩展性强；用parse的好处可能是免去了自己调研和设计这部分需求的时间
  - 对于开发者来说是一个黑盒，出现问题难以debug
    - 如果使用开源方案（parse），需要专门有人维护平台本身代码
    - 如果使用商用方案，遇到问题提工单，以及后续项目废弃的问题，存在风险
  - 定制化开发或扩展成本，主要依赖平台的支持程度
  - 增加应用的架构、部署、性能的复杂程度

Gig后续的发展

开发到目前为止，主要的功能为cms + search的数据管理工具，同时也沉淀了一套应用使用pg和es的最佳实践
如果继续往上层产品做，可能会是一个headless cms（search），但是headless cms的一个问题是使用场景的局限性，平台无法承载过多的自定义逻辑
如果继续往底层产品做，就是往BaaS的方向，把后续应用的存储管理（database、file、cache）和高频服务（auth、acl、notification）全部接走
- 先试用baas（parse）来开发应用，review一下这种开发模式是否合适
- 如果觉得baas这种模式合理，直接基于parse来做gig（headless cms + search）
  - gig目前的curd api设计，和传统sql开发相比，性能和使用的有效性上差别都比较明显，无法直接使用
  - 封装出parse级别的查询是比较麻烦的，还不如直接就用parse来做

BaaS & Headless CMS

BaaS & Headless CMS

Headless CMS

(m)BaaS

BaaS vs Headless CMS

BaaS vs 目前的开发方式

Gig后续的发展

results matching ""

No results matching ""