看维护的人力。我们小公司都在一个仓库里，然后不同目录。CI 、CD 不同 pipeline

第一个还是还是看复杂程度和开发时间，比如我们之前开发的系统原本设计只有两个固定的角色，后来角色越来越多，权限这块全部放在同一个权限处理层做掉了，压根就不需要分多个 api 。根据 restful api 和 url 本身的定义，你在请求一个资源，如果是同一个资源，他就是同一个 url，具体怎么判断是不是同一个资源我们之前的依据是数据结构是不是一致

第二个 80%的业务不用考虑，直接返回所有的字段，如果是因为权限问题，回到问题一。这个也就是 restful api 的缺点之一，也催生了后面的 graphql 的出现。软件设计过程中就是在做各种取舍，在效率和开发时间上，做好平衡

@Arlene666 如果求职，最好还是你自己去看看招聘岗位和薪资水平，这个才是硬道理。如果你可以领导公司技术路线，那当我没说

如果你是想自己做点东西，两者相差不是很大，都可以依托丰富的生态很快出一些成果。如果你是为了找工作什么的，react native 可能更好一点，移动端不行了可以找找其他 react 的。两者设计理念很像，但是走的路线不一样，flutter 在各个平台实现了渲染，react native 还是依托 javascript 那套。

一次性迁移还是要支持增量同步，还有一些什么延迟要求什么的。小公司建议直接花钱，阿里云 DTS 买了操作一下就好了。

需要理解一下 context 的概念

Celery 和 Flask 都是独立设计的，你可以理解为两个职业不同的人在一起协同工作，A 要分配任务给 B，是需要通过发一份邮件之类的东西给 B，而不是把 A B 缝起来让他们成为连体婴儿。g 和 request 都是设计在 flask 内部的，对于 celery 是透明的，而开发上要做的是设计这样一份 邮件

python 本身不是瓶颈，团队里的人才是瓶颈

题外话，这种东西最好就是 搭建 /用 Saas，多租户的平台，毕竟是一个眼科诊所，不是信息技术公司。应当可以抽离出一些通用的流程 /模块

openresty 试试

grafana
把日志和报警分开
grafana 可以设置 es 为 datasource，然后 webhook 到钉钉