应用规模和人员配伍：
| 应用规模 | 主业务流程个数 | 系统分析支持 | 开发人员规模 | 测试人员规模 | 管理难度 |
| 小 | 0-1 | 少 | 1-2 | 2 | 低 |
| 中 | 2 | 1-2 | 2-3 | 3 | 中低 |
| 大 | 3以上 | 每人一个主业务 | 主业务个数+1 | 主业务个数 | 随业务个数增高，最低为高 |
前端技术框架的选择：
| 框架名称 | 作用范围 | 适配应用 | 架构难度 | 开发难度 | 特别注意事项 |
| 原生js | 前端 | 多框架混合、遗留系统 | 高 | 低 | 1、需要资深架构 2、需要技术水平扎实的开发 |
| jQuery | 功能级或事件级 | DOM改变快 | 低 | 中 | 1、需要提供公共事务处理的架构 2、需要技术水平扎实的开发 |
| Vue | 前端 | 小型CURD | 中 | 中 | 1、应用规模扩大后架构难度剧烈提升 2、需要开发人员有较高学习、应用能力 3、要有好的需求人员控制业务边界 |
| React | 前端 | 普适扩展 | 中 | 中 | 1、适合较大规模切不确定业务规模的 2、需要开发人员有较高的学习能力 3、需要有好的需求人员控制业务边界 |
| Bootstrap | 视图 | 普适 | 低 | 中 | 1、需要低等烈度的架构支持 2、开发人员可支持基于视图的开发 |
| 小程序 | 独立小型应用 | 小型 | 中高 | 中 | 1、需要独立的小型架构支持 2、开发人员有较高的学习、应用能力 |
| AngularJS | 前端 | 中大CURD | 中 | 中 | 1、需要有面向对象的思想 2、需要开发人员有较高的学习能力 |
应用规模和人员配伍、前端技术框架的选择等均是不完整的不具体的，需要根据实际情况去做权衡浮动。
现在的应用系统基本上都是业务驱动型的，应用系统的选型基本上依赖于业务规模。如果是新的系统的化，在技术选型之前先评估应用的访问频次，可以参考相近类型应用的访问量，然后按照业务人员评估市场规模和增长幅度，确定一个大约的访问量曲线。如果是旧系统升级的话，先从旧系统提取访问量数据，然后参照业务推广，预估业务访问量提升幅度，确定一个比较靠谱的访问量曲线。
拿着访问量曲线，确定各个业务是否存在访问瓶颈，架构设计的关键点就出来了。接下去就不在继续展开。