四种方法打造自己的APP

导读

原文：Four Ways to Build Web Apps
作者：Tom Hummel
地址：https://tomhummel.com/posts/four-web-apps/
本文为部分翻译加精简，内容用作学习交流

1.Hugo静态框架 + 渐进式网页应用程序

尽管JAM Stack技术让人们对静态网站关注度的有所改观，但是静态网站始终是被低估，没有被充分利用的。
静态网站的持续运营成本几乎为0，配合CDNs运行良好，简单易上手，如果你想开始你的APP部署，静态网页是一个很好的起点。
此外，渐进式网页应用程序(Progressive Web App)可以让静态网页在移动端运行的如同原生程序，你可以不需要传统后端来叠加互动程序和尊重隐私的数据持久化存储（原文：privacy-respecting persistence）。

供应商：Cloudflare Pages, AWS S3, Vercel, Netlify.
基础投入：免费
适合于：多读少写应用（high-read, low-write applications），内容网站，博客，文档展示网站
不适合：多写应用（high-write applications）
样例：
https://oldgames.win/
https://wordle.tomhummel.com/
https://www.nytimes.com/games/wordle/index.html
https://nomie5.pages.dev/

2.Cloudflare Workers

Cloudflare Workers的serverless模式让你简单建立你的独立网站应用。
只需在Cloudflare Pages git仓库的根目录下添加一个/functions目录，那么这些函数就会自动与你的静态网站一起部署。比如，在/functions目录下的form-submission.js脚本将会被部署在/form-submission/路径下。

基础投入：免费试用或者每月五美元给额外的数据存储服务
适合于：
自定义响应头信息
注重隐私的使用分析
用户身份验证/授权
处理表单提交
触发事务性邮件发送
动态构建JSON负载数据
与存储系统（Cloudflare或第三方）进行交互
构建A/B测试及特性开关功能
尽可能地在全球范围内靠近消费者建立存在点以实现更快访问速度
不适合：
复杂路由方案或非常大型的应用程序
需要更重型框架和高级功能的应用程序
需要更先进或功能丰富的运行环境的应用程序
多提供商架构（身份认证和网络配置可能会变得繁琐或脆弱）
样例：
https://github.com/tphummel/braden-looper
https://github.com/tphummel/bobby-witt
https://github.com/tphummel/nick-swisher

3.独立linux服务器

选择你的runtime（node.js, ruby, go, python），操作系统系统和代理程序，将数据存入数据库，不需要负载均衡、集群、节点发现、节点追踪以及外部数据库等一些列复杂概念，系统越简单，故障越简单。

供应商：AWS EC2, OCI Compute, Azure Compute
基础投入：一些供应商有免费试用，之后5美元一个月基础服务，额外的网络带宽和存储服务等另需收费
适合于：
需要对操作系统、运维工具/代理、应用程序运行时环境和框架进行全面定制的项目。
将主要数据存储与应用程序代码共同部署在同一进程中，以便简化数据库连接。
尽可能最大程度地降低每次请求的成本。
力求99.9%的可用性。
服务器集中在一个地理位置。
利用IaaS提供商提供的身份认证和网络基础组件，同时避免不可逆地绑定于该特定提供商。
不适合：
不希望承担管理哪怕是一台Linux服务器开销的团队——包括安全补丁更新、备份和灾难恢复方案等工作。
力求99.999%或更高的可用性要求。
工作负载可能会超出垂直扩展上限（注：这个上限实际上非常高）的情况。
如果你需要全球多地的接入节点（即全球分布式的服务能力）。
注意：单个服务器存在数据丢失风险，避免的方法则是利用如litestream、fluentbit、prometheus或其他类似技术，或者是诸如honeycomb或datadog这样的SaaS提供商。
样例：https://github.com/tphummel/CaNFlySLO

4.PaaS平台上的容器

选择一个PaaS服务提供者，将你的服务运行在容器中，但不包括使用诸如EKS、AKS、GKE或OKE这样的Kubernetes托管平台。这些“托管”的服务方案伴随着显著的运营成本，并且不利于控制项目复杂性。

供应商：
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_cluster
https://registry.terraform.io/providers/oracle/oci/latest/docs/resources/container_instances_container_instance
https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-shared.html
基础投入：一些供应商有免费试用，之后3美元一个月基础服务，额外的网络带宽和存储服务等另需收费
适合于：
需要比Cloudflare Workers提供的更为定制化的运行环境，但又不想管理服务器的项目。
需要横向扩展应用层的项目。
可以接受在无状态应用层与持久化数据层之间增加网络跳转的项目。
追求99.999%及以上可用性的项目。
需要全球存在的项目（请注意，将应用程序推送到边缘相对容易，但将数据推送至边缘更具挑战性）。
利用IaaS提供商的身份认证和网络基础构建优势的项目。
不适合：
不愿意投入构建容器CI/CD部署管道的团队。
不愿管理分布式系统复杂性的团队。
样例：https://github.com/aws-samples/twelve-factor-app-ecs-blog
参考连接：
https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-shared.html
https://docs.aws.amazon.com/eks/latest/userguide/security.html

总结

以上建议囊括80%的需求，具有一定规模的组织可能会从平台所提供的有偿的部署工具/服务中获益（那种可替代Nomad或者Kubernetes功能的）。
复杂性是难以被去除的，但是可以将其过度给他人，比如，静态网页一般不需要apache或者nginx，云供应商将提供这些能力，并将其商业化，随之而来的是成本的降低。
IaaS的认证功能和网络功能通常被低估，它其实可以优雅，简单，安全的满足大部分人的需求。
私网终端：从私网访问云供应商的平台API
主体身份认证：通过授权一个身份去管理其他的秘密令牌，密码