项目地址如下 github.com/mamashende/…
基于Cloudflare workers的可多端同步的todolist web应用
Cloudflare workers的新手教程里有一个最简化版的todolist应用，它的数据存储只基于Cloudflare KV，实现了对于每一个用户（或者是设备）单独存储一份todolist数据 dash.cloudflare.com/cbc516f6ae8…
我在这个应用的基础上，做了许多改动，将数据存储改为Cloudflare D1 SQL，并重构了它的后端。使其实现了对于任何访问用户，存储共享的一份todolist数据，如果只有单个用户的话，这个应用就是最简单的实现todolist数据多端同步访问的方法。实际上我的设计目的也正是此。
如何部署在自己的Cloudflare workers上
具体细节可以参考CF家的官方workers教程，如下：developers.cloudflare.com/workers/
部署过程
简而言之，可以通过新建一个workers实例，将其中内容清空（因为workers现在还不支持从git仓库直接拉取源代码），然后将上述仓库中的三个主要文件内的代码覆盖原有代码。然后将workers实例绑定自己的D1实例
这里⚠️注意将index.js中的const db = env.<your env>修改为自己的D1数据库env变量
数据库的表名及结构
关于具体的D1数据库教程请参考：developers.cloudflare.com/d1/
数据库表名为todolist
结构如下：
| 列名 | 数据类型 | 描述 | 备注 | |
|---|---|---|---|---|
| id | INTERGER | 待办事项 ID | 不需要自增 | |
| todo_title | TEXT | 待办事项标题或者分类 | ||
| todo_content | TEXT | 代办事项具体内容 | ||
| todo_status | INTERGER | 此项任务的完成情况 | 完成和未完成用1和0来表示 |
基于控制台的建表语句如下：
CREATE TABLE todolist (
id INTEGER,
todo_title TEXT NOT NULL,
todo_content TEXT NOT NULL,
todo_status INTERGER
);
这是一个非常简陋的web应用，将其直接暴露在外部网络中存在一定的风险，请各位在使用时做好防护，保护好个人隐私信息，本人对此应用遭受潜在的网络攻击后造成的一切损失不负任何责任。
完全从0开始搭建是一个非常费力不讨好的过程
如果整个项目完全由我目前原计划的方法去搭建，那么成为我最大阻碍的问题将是部署时的服务器/域名/HTTPS证书问题，而这个小的应用其实并不值得投入那么多时间精力在这些非关键技术上。因此最终我放弃了完全从0开始构建这个项目的想法，包括已经写完的后端。
软件开发的第一要务是确保在规定时间内能够正常交付
是的，能够让程序跑起来是第一位的，技术是第二位的 再花里胡哨的技术，如果没法快速有效地解决问题，都是偏离了核心要求
目前解决方案中存在的问题
目前的解决方案是基于cloudflare workers的原生javascript作为后端，D1为数据库，不涉及任何框架以及组件库，为我解决了应用部署存在的上述三个问题，更重要的是，这是免费的服务
目前最大的问题：cloudflare workers的本地开发环境搭建困难，由于网络以及各种适配问题，本地开发仍然非常困难
其次就是前端与后端的交互非常原始，效率低下 最简单的例子就是使用时前端交互延迟非常非常大，虽然其中一部分原因是网络问题，但是没有提供更好的异步解决方案也是一个问题，例如todo的添加后的渲染需要等待后端返回数据，删除操作同理，这种渲染应该以前端交互的实时性为第一位。
再者就是功能不够丰富，未来需要开发的功能包括编辑todo,当前日期时间，todo回收站（实现todo的回收在利用），todo优先级排序(包括手动排序),tag,ddl时间，可折叠展开的列表，后端连接状态组件，访问限制（网关）
未来的迭代计划
首要解决的是前端交互的实时性，也就是在做添加操作时不需要等待后端返回渲染时需要的id，当后端返回时再更新id即可，删除时同理，总之渲染应该与请求同时进行
优化网页加载速度
其次是考虑是否要使用框架重写整个应用（需要考虑workers的负载能力）
