[Feature Request]: 日志
Opened this issue · 26 comments
关联到 bangumi/dev-docs#1 的 Stage 2
SQL Schema:
- https://github.com/bangumi/dev-env/blob/master/un-processed/chii_blog_comments.sql
- https://github.com/bangumi/dev-env/blob/master/un-processed/chii_blog_entry.sql
- https://github.com/bangumi/dev-env/blob/master/un-processed/chii_blog_photo%20(2).sql
模块：
-
枚举日志
a} 在 /user/{uid}/blog 中枚举
b} 在 /{category}/blog 中枚举与仅好友可见相关功能
-
新增日志 /blog/create
-
修改日志 /blog/{id}/edit
-
删除日志 /erase/entry/{id}
-
展示日志 /blog/{id}
日志的 url 放到 /p/users/{uid}/blogs 和 /p/blogs/{id} 吧
新增修改删除这些用不同的http方法
也就是说严格按照RESTful写法，收到
现在其他的 path 都是这么组织的
不过倒也没这么严格，比如前端的登入登出都是全post方法的
dev-env中相关数据库内容是我自己造还是
之前是用树洞账号生产然后导出的…现在树洞账号被封了= =
明天我用小号发几篇日志导出一下吧
噔噔咚，好，我今天先看看现有代码结构
现在代码结构有点问题，web/handler 除了验证输入和输出以外做的事情太多了，我正在把这些迁移出来。不过还没弄完。
老板你这文件结构看的我一愣一愣的，我得花时间消化一下，我这写C#写习惯的突然看到这个目录结构实在没反应过来（（（
越看越迷糊（老板你有空给我指点一下吗（（（为什么全部终结点都在同一个文件夹下面（
现在是把初始化好的 repo 都绑在在 internal/web/handler.Handler 上面，所以新加方法也是在 Handler 上面定义一个新方法。
然后 go 要求同一个结构体的方法都在同一个目录里面，所以就这样了。
下面的repository纵向切分了，但是handler没切
有什么办法可以让结构更好看一点吗
比如？
比如把Handler拆分一下然后让目录结构以api路由结构存放
不过同一个结构体的方法都在同一个目录里面，这一点确实让分目录比较困难
我暂时想不到什么更好的分类方案，但是把所有终结点全部放在同一个目录下面确实有点难受
日志数据导出到dev-env了
晚点我拆个common出来
话说我们的用户认证服务是OAuth2吗
是旧站提供的oauth2
这边的话session (/p/) 或者access token (/v0/)请求都有可能，有中间件处理，router里面不用管。
access token也可能不是oauth2生成的，是在这个页面直接生成的 https://next.bgm.tv/demo/access-token/create
暂时先等一下吧，我重新考虑下其他的讨论贴部分怎么做…（
那我就先慢慢等了（
好像也没啥要改的 ，就先这样吧
比如把Handler拆分一下然后让目录结构以api路由结构存放 不过同一个结构体的方法都在同一个目录里面，这一点确实让分目录比较困难 我暂时想不到什么更好的分类方案，但是把所有终结点全部放在同一个目录下面确实有点难受
同意，目前这个架构个人感觉有点难受，建议新开个issue调整下
比如把Handler拆分一下然后让目录结构以api路由结构存放 不过同一个结构体的方法都在同一个目录里面，这一点确实让分目录比较困难 我暂时想不到什么更好的分类方案，但是把所有终结点全部放在同一个目录下面确实有点难受
同意，目前这个架构个人感觉有点难受，建议新开个issue调整下
好啊，有建议的话可以开个issue讨论一下。
我最近比较忙，暂时没空写代码。
比如把Handler拆分一下然后让目录结构以api路由结构存放 不过同一个结构体的方法都在同一个目录里面，这一点确实让分目录比较困难 我暂时想不到什么更好的分类方案，但是把所有终结点全部放在同一个目录下面确实有点难受
同意，目前这个架构个人感觉有点难受，建议新开个issue调整下
应该说目前handler是有一定程度的划分的...