yukai08008的博客

APIFunc.DataBase的第一版有一个监控一直在做agg,造成数据库的无谓消耗，所以一定得修补。这样，使得ADB(APIFunc.DataBase)的应用更贴近实战，我觉得短期内应该不必再修改了。既然后端的流转和监控逻辑可以固定下来，那对应的前端也应该进行整理，从而不必再为每个新的实例去单独写前端。每分钟的任务吞吐量>=2万条(测试峰值 6万条)，所以保守估计一个核一天也能处理3千万数据，应该是足够了。并且整个过程不再对mongo造成压力。

后端交互数据的机制上一篇已经实现了编辑器，现在就要打通前后端。做到前端编辑的结果自动传输到后端保存，这样就能确保了在线编辑“不掉链”。

对于我来说，代码的编辑量是比较大的。传统方式是使用文件方式：创建文件夹，创建文件，然后使用VSCode之类的编辑器来编辑代码。传统方式最大的好处是简单，任何人都可以使用。缺点在于很笨重，而且没法用算法加持。在项目之间有时候还会重复拷贝很多份代码，看起来是比较眼花缭乱的。我没仔细统计一天写多少代码，但是平均的估计下来也不会少于1000条吧，各种大大小小的项目应该有数百。在这个量级的累积下，基本就没办法很好的利用、回溯以前的成果了。所以，我想借助现有的全栈基础，再加上前端，彻底改变文件方式。通过数据库和算法来进

继续给表格来加一些小功能。

拳不离手，曲不离口原理通了不代表完成，还是需要不断的练习和完善。

将上一篇提到的内容进行了实现，整体上还算是比较符合预期吧，但并不是完美。这既和我的需求比较“妖”有关系，也和前端的确不太熟有关。但不管怎么样，反正实现了功能。1 实现自动为表格增加有序值字段方法（这个应该是做过的，要挪移一下） ~ 1 Hour - 符合预期2 将上述的脚本和对应视图进行检查和封装。~ 2 Hour - 超过预期1个小时，主要是因为建立了主键索引，当重复插入时会报错。我还以为是自己的工具有问题，调试了好一会。3 增加自动根据数据库服务名创建连接的方法。

虽然还是没有太多时间花在前端上，不过已经开始走上轨道，时不时做一些小东西了。有的时候我太过追求抽象化，通用化，在这个阶段是不太对的。做模型也好，搞架构也好，一方面是我搞的时间够多，另一方面是因为他们的本质的确是需要抽象的。在前端，尤其是刚开始没搞多久的时候，我觉得做起来更重要。在完成了功能之后，可以「顿一顿」，做一些小总结。

在进行下一步之前，还有一个重要的测试要做：参数化。其实目前进度基本上9和10已经ok了。

上一次做到本地的增删改已经ok,现在要使用下拉框来进行选择和触发。接下来就简单了（之前已经实现过），使用多级下拉框来选择不同的服务器、数据库和表。唯一一个要注意的就是不同表的主键问题：大部分主键是不同名的。当然也不是所有表都需要/允许编辑。约定：每个可编辑的数据表都有一个整型的主键id，名字叫task_id,这个我已经有一个可手动开启的worker来长期运行。所以如果要将某个表转为可编辑状态时，启动这个worker去守护这张表就可以了。

1 使用tabulator初始化表格后，增加监听函数2 监听函数将增删改变化和后端视图进行交互3 后端视图将变化同步到数据库并给前端反馈进度1 启动本地Flask服务及组件测试2 依赖文件本地化3 在本地建立远端数据库的句柄4 页面载入时加载参数进行表格初始化(前端一个模板、后端一个视图）5 页面载入并初始化一个可读表格(暂时不用分页）-> 这个是为了展示一些数据，同时不想这些数据被编辑。

这里对003做一个修补，就是单元格编辑后和后端的互动。

接下来做6，比较重要的一步是前端页面把变化同步给后端。

上次开了个头，这次完成3，4，5。

因为工程化的步骤比较多，所以用系列文章的方式记录一下。

技术的终点是前端我是从模型/算法作为起点的,顺着工作的需要和自己的兴趣，慢慢的逐步走到了前端。