firebase 把，没有比这更快的了。。都不用写后端，只用管前端就行了。

多人协作需要 type hints 和 docstring，否则神仙难救。

可以在 linting 阶段加入 mypy 或者 pyre 这样的类型检查器，让大家尽量不全类型信息。

rancher?

我们在 aws 上的简单配置：
1. 多 EC2 实例部署 django 应用
2. 接个 ASG 保证 HA
3. 最前面再接个 API gateway

LZ 的问题听者像是数据库瓶颈的问题。如果经常需要做大量数据统计和报表的功能，一个是考虑优化一下 query 的性能；一个是可以考虑设置定时任务预计算一些常用的报表；另一个是考虑上 OLAP 的数据库，例如我们的 OLTP 用的 postgre，OLAP 用的是相关的 greenplum

创始人不拿钱合适。
早期员工不拿工资不合适。如果需要靠抹除人力成本才能拉长 runway，这个模式不可持续性太大了。

员工和创始人需要区别对待。

给开源项目交 PR，先搞几个 good first issue 上上手

@mywaiting django 更符合一些 python 的直觉，do one thing with one way 。老年人表示 django 比较友好

外包的外包？

因为 go 被设计出来的主要目的不是来写 cms，电商平台这类高度业务相关的程序的。

go 一直是作为一个 better C 被设计出来的。C/C++的使用成本很高，go 出来之前，比较正经的基础组件（数据库、中间件、网路、容器编排等）基本选择只有 C/C++。但这个模式不符合大厂的利益，因为能用好 C/C++的人太少，写出来的程序 bug 太多。go 被搞出来之后，即使是年轻的工程师也可以像老帮菜一样，写出质量较高，性能不错的各种基础组件了。这个才是对大厂生产力提高最多的地方，也是 google 为什么乐意持续投资搞 go 的原因。

至于传统的 web 后端，这个完全是语言流行起来之后的溢出效应。这个道理就和你问，为什么 C/C++写的 CMS 和商城系统这么少呢？非不能也，只是擅长的领域不一样。

你需要写测试和设计文档

hacktoberfest 骗 T 恤衫正常招数。

其实只要合并多个修改到一个 PR，并且注明是 fix typo only，这类 PR 也是没啥大问题。

这是传说中外包的外包？

我默认楼主需要的是类似数据仓库之流的东西，这方面运维成本很高，小公司自己做没经验的话会很痛苦。建议直接买云厂商的解决方案。例如阿里云的 maxcompute 。比较现代的解决方案一般是存算分离，存储一般用普通的 oss 。

在这个基本的仓库服务上，建议再酌情选择 数据治理，数据管道等组件。这方面可以开源和购买相结合。

CTO 不行 -> 同意
Rails 不行 -> 这锅 rails 不背。Github，shopify，Airbnb 怕不是都是用的垃圾语言和框架

i7 有点困难。服务器 CPU 的话，可以体验一下 oracle 的裸金属机器租赁服务 https://www.oracle.com/cloud/compute/bare-metal.html

没啥问题，使用了这样的方式已经一年多。


我不用 windows 和 RDP，只用 linux 和 SSH，对带宽要求小的忽略不计。

建议买个移动显示器，千八百的价格，使用体验完胜了这个。

这个模式很常见，interface-based 编程。

后端做 grpc 服务基本都是这么弄的。用 protobuf 先把 data model 和服务接口写出来； protoc 生成 client 和 server 端的教授叫代码；去 server 端填各种具体实现。

swagger-codegen 我的理解就是把 protobuf 替换成 swagger spec，code-gen 替换了 protoc，接口调用编程了普通的 http 调用；但整体思路是一样的。