之前主要说的是，我是如何产生这个圈子小程序的想法和如何上线的。有兴趣的朋友可以回去参考前面两篇文章。这次来给大家讲讲，在技术上是如何实现的。

如何快速把想法变成产品

分享作为独立开发者经历和一些上线经历

技术栈

前端主要是基于Taro Typescript dva框架实现的，后端基本上是以Ruby on Rails为主。

这里说下为什么要做这样的技术选型，关于技术选型，在《奔跑吧，程序员》一书中有很详细的分析，后面我会我在我的读书笔记系列把这本书做一次分享。

这里主要说下技术选型主要判断，如果是快速成型的项目，应该选择更加轻量的语言和有大量社区组件支持的，另外一个就是自己熟悉的。

前端

为什么用Taro？主要是以往自身经历决定的，以为本身我做了13年技术研发，虽然后面几年自己动手的时间少了，但也算在一线工作。前几年React Native刚兴起的时候，对于有着js开发经验和安卓开发经验的我很快就上手。借着之前饿了么做hybrid和移动端动态模板渲染的经验，让我迅速理解了React的设计理念和原理。

所以这次就顺利的用了以React为主的Taro前端开发框架，虽然uni-app大名鼎鼎，但毕竟要重新了解vue。原先redux那一套回忆起来相对比较快。这里不去争论对错，能让你舒舒服服的快速完成，那么就是对的。

说回Typescript，记得以前写js碰到最大的问题是无法提示，对于我们这种全栈开发来说，切换太快了，所以会花很多时间查他下面有哪些方法等，为了节省代码量，有段时间还疯狂的写coffee script。虽然项目里写的还不是很规范，但确实解决了我很大一块问题。

看到这里肯定有人想说，那是你没用对。就好像Vim、Emacs一样，很多人觉得太方便了，为此我还专门花了时间去学vim的快捷键。但是最后用起来还是习惯不了，切换模式dd删除，我还是比较喜欢在VS code里用`command x` 来当删除用，十几年的习惯，不是说改就改的。

还是那句，没有对错，只有你自己习惯就好。

后端

其实这几年写的比较多少的还是Java，但这里就不多说了，现在的项目也没做过太大的压测，但如果用户量大到扛不住，那么再说甜蜜的烦恼问题。重新花时间调研了下Ruby on Rails，发现新增了很多特性，如Job、ActiveStroge、Webpack、turbolinks等等，对于全栈开发来说支持越来越好了。

最重要的是Ruby on Rails对测试的支持非常好，我个人习惯就是如果代码没有测试覆盖，我很容易改出问题，因为时间久了或者对这块业务不熟悉了，很容易有问题出现。

小程序

项目结构

先丢张基本的结构图让大家了解下

• pages 是小程序所有主页面的目录
• models 是数据层，负责获取远程数据和处理数据的
• components是组件层，主要是一些组件和放复用页面的
• services是网络层，主要是各种api调用的
• utils是各种帮助类

大概的流程是这样的，这里不做过多讲解，有兴趣的朋友自己去看dva框架和redux。

下面主要这次开发圈子小程序碰到的一些问题和我解决的思路和方式，如果你有更好的，欢迎找我交流。

登录

说真的，登录是非常烦人的一件事。之前一直有一定的概率出现**Error: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt**，后来在官方的文档中找到：

在bindgetphonenumber 等返回加密信息的回调中调用 wx.login 登录，可能会刷新登录态。此时服务器使用 code 换取的 sessionKey 不是加密时使用的 sessionKey，导致解密失败。建议开发者提前进行 login；或者在回调中先使用 checkSession 进行登录态检查，避免 login 刷新登录态。

所以后来我调整成

1. 在进入页面后，会进行一次login，然后把获取的code保存起来
2. 当用户点击登录按钮，会再一次进行checkSession检查，避免登录态失效
3. 然后把获取到的`code`, `encryptedData`, `iv`全部提交到服务器进行解密和校验

Textarea穿透问题

圈子小程序里有个功能，用户可以评论某个人的帖子，然后会导致一个问题，就是底层的输入框会在弹层上层。具体可以参考下面这张图，我当时没截图。无论你怎么设置z-index都没用。

导致这个问题的原因是，Textarea是原生组件，层级会高于网页组件，所以我是这样解决的。

1. 当Textarea失去焦点后，把内容存储到内存里
2. 隐藏Textarea，并显示一个View
3. 填充之前缓存的内容

不过这样做又会导致另外一个问题，有可能因为焦点问题，缓存里没内容，用户直接点了发送按钮，这个时候就需要判断提交的内容里有没内容，有就直接提交，没有就用缓存里的。都没有就做非空提示。

还有就是有同学提到，输入框会被键盘盖住的问题。类似下图

这里解决方式也相对比较好解决，参考官方文档这个属性

dva-model-extend和model层

往往在实现逻辑的时间发现很蛋疼的问题，就是几个页面逻辑差不多，但有有点不太一样，然后这个页面又耦合了一些其他模块的逻辑。最常见的例如下面这个。

上图里面几块业务就涉及了圈子、帖子、用户、赞、评论逻辑，还有自己页面的一些逻辑，那么我们应该怎么去划分呢？大家可以参考下图

业务基础类

主要是负责通用逻辑实现的，比如获取用户相关的baseUser，帖子相关的basePost等等，但他们没有自己的namespace，不能直接调用，只能作为基类存在。

业务类

就是负责通用业务真正被调用的，比如用户类userModel、帖子类postModel等等。这样做有什么好处，那就是任何页面都可以去调用。

比如我想在帖子列表的页面里获取每个人的用户信息，那么我可以直接dispatch一个user的type。他的逻辑相对标准。

界面类

就是为每个页面提供特性服务的类，比如上面图里，我有定制对帖子的返回内容要单独存一个state，那么我就可以继承基础业务类，然后更改他的reducers

的action实现。并且每个界面类都会关联一个page。

数据类

为什么数据类单独的？这有什么用。在前端，我们碰到的很大的一个问题就是，比如A页面用了用户信息，B页面也用了用户信息。如果按照以往的做法，每个页面单独维护一个用户信息，然后通过eventbus来更新到每个页面，这样做的问题是大量的冗余数据放在内存里，然后event满天飞，最后也不知道这个页面的数据被哪个地方触发改变了。

所以需要以前数据层来维护，有点像前端的内存关系型数据库，界面拿到一堆ID，然后在要显示的时候才会去数据层查询具体的数据，然后渲染界面。

数据渲染

上面提到，以往我们都是直接渲染数据的，然后通过eventbus改。这样还会碰到一个很麻烦的问题。

还是圈子小程序的例子，如果我要删除一张帖子里的评论，我需要怎么做？

1. 找到帖子该帖子的数据
2. 找到帖子里的评论数据
3. 因为评论可能是子评论，还需要在先找到上级评论后再找到当前评论。
4. 防止其他页面数据未更新，发送事件通知其他页面也需要重复一次以上操作

最开始一度让我很奔溃，根本没有办法继续持续下去，而且还很容易出问题，测试的工作量也倍增。

然后我找到了前端神器normalizr，这个库可以帮我们完成上面数据层说的工作。具体流程可以参考下图。

为节约篇幅，这里不做过多解释。因为所有页面都是引用性质，所以一旦数据发生变化，所有页面都会跟着变化。并且处理数据只需要处理一层的关联，不需要处理多层的数据结构，因为它帮你把数据进行扁平化处理了。

总结

上面分享了项目的基本结构、逻辑分层、数据处理的一些思路，相信应该对大家开发小程序有一定帮助。

后端

说完前端的基本架构，现在来说说后端。对于初期的项目来说，前端只要处理好数据和逻辑的架构，其他都是一些界面的问题和css相关体力活和不断的多设备兼容调优。

后端的事情比较了多了，比如监控、数据处理、微服务、容灾等等，这些年或多或少接触了一些，但作为新项目，这些东西反而不是最重要的。

实现一个新项目，最重要是如何更快的迭代和提供新接口。crud仔的名声不是随便说说的。

从早年的WebService到现在的微服务，概念一直在更新，但本质上没有太大的改变。都是希望降低风险，早年我在小秘书的时候就开始做SOAP和WSDL，但对于创新业务来说，技术不应该作为阻碍效率的存在。

当我听到为了一张表而专门创建一个服务的时候，我反而觉得是为了微服务而搞微服务。当我想改一个问题的时候，我需要从网关一路改到最后层的服务，明明几分钟能解决的事情，在调试上硬花了一整天。

每个人观点不一致，技术没有对错。面对不同的背景，每个人选择不一样。我见过很多技术架构很好，但迭代慢死掉的公司。也见过很多内耗很严重，但依然发展很好的公司。

前面稍微说的有点偏题了，回到主题。初创项目主要处理好几件事情。当然你有其他观点，欢迎讨论。里面有些地方参考了ruby-china的源码，非常感谢。

• 接口及响应模板
• 错误捕获及告警
• 权限校验
• 部署和测试

接口及响应模板

怎么理解接口及响应模板呢？说白了就是你的接口能返回数据。

这次我没有采用Grape的Gem，而是直接使用了Rails Api和Jbuilder的渲染模板。

首先我创建了一个父级渲染模板

# app/views/layouts/api/v1/application.json.jbuilder

json.code 200

json.message @message.blank? ? ‘’ : @message

json.data JSON.parse(yield)

也就是无论如何都会返回code，message，data这三个key，data可能为Array或者Object

然后在application_controller.rb里指定父layout

layout ‘api/v1/application'

然后在application的目录里为每一个实体做一个通用的模板，如_user.json.jbuilder,通过参数判断是简易还是复杂对象。

比如你在列表里user可能主要3个值,nick_name,id,avatar，当你具体查看某个人的资料时，你可能需要知道他的其他信息，例如age,gender,cellphone等等。

然后相应的接口渲染可以参考下面的

json.partial! ‘user’, user: @user, detail: true

基本上你接口的响应就到这里就结束了。补充一点，如果你是使用Rails Api的话，使用Jbuilder需要加入以下引用

class ApplicationController < ActionController::API

include ActionView::Layouts # if you need layout for .jbuilder

include ActionController::ImplicitRender # if you need render .jbuilder

错误捕获及告警

这里分为几块

错误码

你可以选择新建一个专门的类来维护错误码

module Api

module V1

module Code

module HttpBase

HTTP_FORBIDDEN = 403

HTTP_INTERNAL_SERVER_ERROR = 500

HTTP_UNAUTHORIZED = 401

HTTP_BAD_REQUEST = 400

HTTP_UNPROCESSABLE_ENTITY = 422

HTTP_NOT_FOUND = 404

HTTP_BAD_GATEWAY = 502

HTTP_OK = 200

HTTP_CREATED = 201

HTTP_NO_CONTENT = 204

HTTP_METHOD_NOT_FOUND = 405

end

module HttpExtend

INVALID = 10000

end

end

end

end

错误消息

这里就不提了，我直接新建了一分api.zh-CN.yml的I18n来维护错误消息

错误类

这里稍微讲一下，主要是分成3种三类别

1. 系统错误类别，比如系统宕了，数据库查询报错，参数判断为空这类系统异常类，由系统抛出，捕获处理就好了。
2. 另外一种是业务异常，比如这个人查不到，输入的东西包含敏感词等
3. 第三种就是远程调用异常，这种属于后端调用错误，可能包含重试

因为不包含复杂数据对象，所以错误直接render json就好了。

权限校验

这里用了`cancancan`，具体使用大家自己去github上看吧。这里讲下怎么应用的。主要分两块，第一块是后台业务逻辑的权限判断。

后台业务权限

if @user.blank?

roles_for_anonymous

elsif @user.admin?

can :manage, :all

end

elsif @user.normal?

roles_for_members

elsif @user.blocked?

roles_for_anonymous

else

roles_for_anonymous

end

可以参考上面，分为以下几种情况

• 未登录 – 允许部分只读
• 管理员 – 允许所有操作
• 普通用户 – 按权限划分
• 禁用用户 – 允许部分只读

这里说下roles_for_members权限，里面会有更详细按照各个业务进行划分，业务的权限会有接口级别的权限条件判断。

前端业务权限

比如在前端的时候，每个人的状态是不一样的，比如我作为圈主，我可以删除自己圈子里一些用户发的帖子，但我不能删除其他人发的帖子。那这里是怎么做的？

在前端渲染的时候，每个对象都会带一个权限表，表明我可以对这个对象做什么？

if object && object.is_a?(User)

%I[ban report].each do |action|

json.set! action, can?(action, object)

end

end

比如上面就是，我点开某人的信息页，会返回我对这个人是否可以禁用或者举报。类似的还有对帖子是否可以删除，置顶扥等。

部署

对于部署来说，方式有很多。早些年容器化技术还没流行的时候，大家都需要配置环境，然后用Capistrano进行部署，或者用jenkins等等。

但是对于刚开始的项目来说，没必要搞那么服务，可能你的服务器一共就2个G，你还在上面折腾个jenkins，实在是不划算。所以这里主要是用

docker docker-compose来做。

大家可以看张图，方便理解

首先是Dockerfile

# Dockerfile

FROM ruby:2.6.5

RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add –

RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list

RUN apt-get update -qq && apt-get install -y build-essential nodejs yarn

ENV APP_HOME /app

RUN mkdir $APP_HOME

WORKDIR $APP_HOME

RUN gem install bundler:2.1.2

ADD Gemfile Gemfile.lock yarn.lock $APP_HOME/

ADD vendor/cache vendor/cache # 因为是开发机直接部署，没必要从服务器再每次拉一边，所以先缓存了下来

RUN bundle install

ADD . $APP_HOME

RUN yarn install –check-files

RUN bundle exec rails assets:precompile

然后是docker-compose.production.yml

version: ‘3’

services:

your_project_name-production:

image: #远程image

container_name: #容器名称

command: bundle exec rails s -e production

volumes:

– /app/log/#{your_project_name}-production:/app/log

ports:

– “7001:3000”

env_file:

– .env.production

network_mode: bridge

your_project_name-production-backup:

image: #远程image

container_name: #容器名称

command: bundle exec rails s -e production

volumes:

– /app/log/#{your_project_name}-production-backup:/app/log

ports:

– “7000:3000”

env_file:

– .env.production

network_mode: bridge

最后是我们的部署脚本deploy-production.sh

#!/bin/bash

export SERVER=‘#你的服务地址’

export service=‘#你的项目名’

# 先打包bundle gem

bundle package

# 1. 传输部署文件

scp .env.production $SERVER:/app/$your_project_name/.env.production

scp docker-compose.production.yml $SERVER:/app/$your_project_name/docker-compose.yml

scp Dockerfile $SERVER:/app/$your_project_name/Dockerfile

# # 2. 打包镜像

# 目前我用的是阿里云的镜像服务

docker build -t $镜像地址 .

# 3. push镜像

docker push $镜像地址

# 4. Pull镜像 && 启动

ssh $SERVER << EOF

cd /app/$your_project_name

docker-compose pull $your_project_name

docker-compose down && docker-compose up -d

docker-compose run -d $your_project_name bundle exec rails db:migrate RAILS_ENV=production

rm -rf .env.production

docker image prune -f

docker container prune -f

EOF

docker image prune -f

docker container prune -f

echo ‘deploy success!!!’

上面方式当然存在很多问题，比如部署失败他也提示成功等等。但是这个时候你也很容易到机器上去解决问题，或者更改配置进行镜像回滚。

测试

测试主要走rspec，具体各位自行去了解吧，有点写不动了。因为独立项目，所以没有人会帮你测试，你需要自己保证代码的健壮性。如果大家感兴趣，回头专门开一篇讲测试思路的文章吧。反正尽量保证你所有接口和核心类的测试用例覆盖就好了，像我的话代码放在github，直接接 Travis CI 就行了，保证你每次master分支的代码都能通过测试才发布。

最后

欢迎各位进行进行评论讨论，互相学习。近期很多朋友找我聊项目的一些背景和想法，只言片语无法讲清楚。后面会写篇关于我对社群的一些理解和商业模式的一些看法，欢迎继续关注我。

专注互联网创业分享，独立开发者。全网同名：卢灿伟