Trinkle23897/tuixue.online-visa

api design new proposal

BenjiTheC opened this issue · 5 comments

BenjiTheC commented

这两天在想关于之前讨论组里关于api endpoint的设计问题

一个get当前时间，一个get连续一段时间内的变化范围（每天的最早、最晚、众数），一个get一整天的原始数据

目前的api设计（/backend/global）在接收请求的时候，接收的是region + sys，再在api内部计算出embassy/consulate列表。现在看起来这其实是一个很不flexible的设计，因为在数据库层面visa status是按照(visa_type, embassy_code, Optional[write_date])这个二（三）元组存储的，那么后期如果加region/sys或者其他的分类方式，这整个route都要重写。所以我觉得可以优化一下这一块的设计。

大体思路是，把如何分类/组合这个比较多变的逻辑交给前端，和数据库查询有关的route只接收visa_type，embassy_code和其他与pagination有关的query。前端页面加载时会先AJAX一个请求给后端读取像region/embassy_lst这类meta data，然后通过default值再AJAX一个请求读取具体的visa status数据。React（或者其他带AJAX的现代JS前端框架）的一个优势就在于，当浏览器通过网络请求从数据库读取数据的时候，用户不会看到一个空白页面，而是会有部分已经加载好的信息显示在浏览器了，所以我觉得虽然会有两个AJAX request，UX/UI这一块应该是okay的。

这里的我现在想的是，所有和GET签证可预约时间有关的endpoints都以/visastatus起头，具体如下：

  1. /visastatus/meta
    读取包括region/embassy_lst在内的meta data，通常来自global_var.py，这样的好处是前端代码库不需要定义这些变量，只用维护后端global_var就可以。
  2. /visastatus/earliest?visa_type={vt}&embassy_code={ec}&since={dt}&to={dt}
    相较于之前的/backend/global的query，把region和sys这两个query param移除，增加了embassy_code，这样的话这个（和后面的一些)endpoint的逻辑基本上就可以保持不变了，分页的话我现在觉得改成since和to来申明具体的时间跨度会比较好，分页的逻辑可以在前端从数字（之前的skip & take）转化为UTC string，FastAPI会自动转换成python datetime object。
  3. /visastatus/latest?visa_type={vt}&embassy_code={ec}
    获取 签证类型x领事馆 的“当前”，这个endpoint和上面的"最早"endpoint分开的考虑主要是在实现逻辑（both api and database）上都更简单，不容易buggy。而且在前端我们可以频繁ping这个节点（e.g. 页面加载后，每一分钟重新请求这个节点的数据）来更新前端页面。
  4. /visastatus/{visa_type}/{embssy_code}?since={dt}&to={dt}
    这个节点默认GET一个 签证类型x领事馆 的所有历史数据，可以通过since和to来限制数据量。事实上如果抓取所有历史数据后端的计算压力是很大的，因为新写入数据不保序（记得之前讨论过）所以会涉及排序。但是如果能够限制查询的数据量到一天的话就还好，而且考虑到这个endpoint相较于前两个可能不会有那么大的访问量（纯yy有待实践检测），所以为了flexibility选择了这个默认设置

P.S.：上面的这些route里visa_type和embassy_code都可以做成接收list

Trinkle23897 commented

1很赞
2把since改成from比较好点？以及直接返回三元组，每天的（最早，最晚，众数），反正这个结果应该是要cache的（于是得把earliest换成别的名字）
3没意见
4我觉得把dt range改成dt吧，看连续好几天的详细数据，即使渲染出来也看不出啥……？还不如渲染2的那张表

BenjiTheC commented

2把since改成from比较好点？以及直接返回三元组，每天的（最早，最晚，众数），反正这个结果应该是要cache的（于是得把earliest换成别的名字）

from也okay的，目前数据库没有存每天的最晚以及众数，这里我可以直接把当前数据库的earliest_date这个collection改成比如visa_status_overview（之类的。但是我们目前还没有用cache哦，这里是要cache到redis里吗（不知道2G内存架不架得住lol

4我觉得把dt range改成dt吧，看连续好几天的详细数据，即使渲染出来也看不出啥……？还不如渲染2的那张表

好

Trinkle23897 commented

不是，我意思是最早最晚这些variable专门维护，存到数据库里面以后直接查，不用每次都动态查之类的（就是把结果给存下来

z3dd1cu5 commented

我觉得API设计当然是没啥毛病，这网站就这么几个功能，不管怎么设计也就这么几个endpoint。

在前后端分离的架构里，后端API是为前端服务的。现在前端代码的雏形都还没有，这个时候纠结API里的几个参数就显得没什么意义了。只有真正开始写代码的时候，你才会知道你想要的是什么。所以我觉得API这样就可以了，作为一个初版完全OK，后续可以根据需要再调整。

也不用太担心后端服务器性能的问题，解决办法其实有很多，比如
加钱换个好点服务器
换个轻量级数据库
租个云数据库
使用各种姿势做缓存
为不变动的内容开启CDN
把一部分计算挪到前端js进行

优化的问题可以等第一版做出来再考虑。说不定这个网站就没人看呢优化什么性能（跑

In short, 快写前端啊大兄弟

BenjiTheC commented

我觉得API设计当然是没啥毛病，这网站就这么几个功能，不管怎么设计也就这么几个endpoint。

在前后端分离的架构里，后端API是为前端服务的。现在前端代码的雏形都还没有，这个时候纠结API里的几个参数就显得没什么意义了。只有真正开始写代码的时候，你才会知道你想要的是什么。所以我觉得API这样就可以了，作为一个初版完全OK，后续可以根据需要再调整。

也不用太担心后端服务器性能的问题，解决办法其实有很多，比如
加钱换个好点服务器
换个轻量级数据库
租个云数据库
使用各种姿势做缓存
为不变动的内容开启CDN
把一部分计算挪到前端js进行

优化的问题可以等第一版做出来再考虑。说不定这个网站就没人看呢优化什么性能（跑

In short, 快写前端啊大兄弟

K, cool