V2EX › wunonglin 的所有回复 › 第 39 页 / 共 154 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 35 36 37 38 39 40 41 42 43 44 ... 154

❮

❯

2022-01-17 15:37:57 +08:00

回复了 timedivision 创建的主题 › 汽车 › 老丈人开卡宴，丈母娘开宝马 7 系，我 10w 首付应该买啥车？

建议还是特斯拉吧。不然就 bba 咯

2022-01-17 14:16:32 +08:00

回复了 windfarer 创建的主题 › 推广 › Go 微服务框架 Kratos 线上直播年会，等你来围观！

太棒了。我就是跟着你们源码学的微服务

2022-01-17 14:14:26 +08:00

回复了 fengchen0vr 创建的主题 › 问与答 › 阿里云盘大于一百兆下载要装客户端了，这私有没有扫盘

@mxT52CRuqR6o5 #44 存二进制文件自己做非对称加密就行了

2022-01-17 11:37:14 +08:00

回复了 justNoBody 创建的主题 › 微信 › 2022 年了，微信能更好的实现云备份了么？

@justNoBody #2 电脑微信有备份功能，同一个局域网就行了

2022-01-17 11:31:41 +08:00

回复了 justNoBody 创建的主题 › 微信 › 2022 年了，微信能更好的实现云备份了么？

。。。那么重要的东西不另外存着？微信不是说要推出云存储聊天记录的功能了么，等等呗。

每日一句：微信垃圾

2022-01-17 11:27:06 +08:00

回复了 gongquanlin 创建的主题 › macOS › 请问为啥 mbp2021 插着电源，就不会休眠呀？

盒盖即休眠。插电状态下开盖的话是不会休眠的。

2022-01-16 20:24:51 +08:00

回复了 fengchen0vr 创建的主题 › 问与答 › 阿里云盘大于一百兆下载要装客户端了，这私有没有扫盘

？？？改什么吃屎，不是一直在吃？

再说，不会有人以为不会走百度的老路吧？不会把不会吧？想什么呢。真要没限制的去用 oss

2022-01-16 17:34:45 +08:00

回复了 smartwusir007 创建的主题 › 问与答 › 前端组件大家是怎么做的

1 、组件不符合需求就自己写一个。组件库只能覆盖 70%的场景，选一个自定义程度高度组件库就行，element 和 ant 耦合度很高，建议要用这种库的话就优化需求以符合组件库即可。
2 、好好学。

2022-01-15 23:00:23 +08:00

回复了 zorn 创建的主题 › Node.js › 基于 Express 和 TypeScript 写了一个快速开发的 API Server

这不就是 nest 么。。。

2022-01-15 22:06:54 +08:00

回复了 shinsekai 创建的主题 › Apple › Apple pay 银联卡码合一难产了？

谁的码合一了？

2022-01-15 22:03:42 +08:00

回复了 JL1990 创建的主题 › 问与答 › golang 中 json 如何解析不同的结构体

@JL1990 #7 那为什么不把字段都做在一个 struct ，然后再判断那些有值不就行了么？

https://s2.loli.net/2022/01/15/4f1JIzoFEKeDp8g.png

2022-01-15 20:38:13 +08:00

回复了 zbzzh 创建的主题 › 宽带症候群 › steam 官网部分地区疑似被墙

@ZztGqk #11 不在工信部备案的网站“按理”都不能打开，这不是我决定的[doge]。所以被墙了毫不稀奇。还有博主说想反抗😄，建议先开个群大家都加进去反抗。反正到时候谁先进去我就不知道了

2022-01-15 20:24:45 +08:00

回复了 JL1990 创建的主题 › 问与答 › golang 中 json 如何解析不同的结构体

分别解析 V1 、V2 不行？你写的这个 parse 和直接调用 unmarshal 有啥区别

2022-01-15 15:30:19 +08:00

回复了 DinnyXu 创建的主题 › MacBook Pro › 大家使用 M1 感受如何？

太快了。不习惯

2022-01-15 15:25:15 +08:00

回复了 zbzzh 创建的主题 › 宽带症候群 › steam 官网部分地区疑似被墙

很稀奇么？

2022-01-14 18:38:59 +08:00

回复了 firhome 创建的主题 › 程序员 › 请教后端同学这种写接口的方式对不对？

@hhjswf 这看你业务来着。我自己预想的是订单这个整体是一个服务

2022-01-14 17:51:49 +08:00

回复了 firhome 创建的主题 › 程序员 › 请教后端同学这种写接口的方式对不对？

@linglin0924 #89

我认为是因为 lz 习惯了 bookinfo 一股脑带出来可以直接渲染，页面不用太多异步逻辑，加上以前单服务的时候是可以 join 起来也方便，所以直接返回也没什么问题。这是 ok 的，因为那时候大家都这么做的。

但是到现在新微服务架构后，两个服务分开了，分别提供了 curd ，就没必要再加一个聚合的 bookinfo 接口，因为确实没必要。

这个构架不用考虑握手太多的问题。人少对系统没压力，人多接口分细了反而能降低系统负载，前端也可以用中间件做 ttl 缓存。问题很好解决，或者说压根不是问题。

时代变了呀~

2022-01-14 16:54:40 +08:00

回复了 firhome 创建的主题 › 程序员 › 请教后端同学这种写接口的方式对不对？

@wupher 他这个已经是微服务架构了。不同业务直接不要直接操作，更何况在不在同一个库都不一定

2022-01-14 12:53:44 +08:00

回复了 firhome 创建的主题 › 程序员 › 请教后端同学这种写接口的方式对不对？

@wunonglin #41

网站人流量多的可以在前端用用中间件做 ttl 缓存，网站人流量少的你也不用考虑多次请求带来的负载。

每个模块都有 curd 了，那就没必要再给你搞一个聚合接口，你说可不可以，当然可以，只是没必要而已。

2022-01-14 12:50:18 +08:00

回复了 firhome 创建的主题 › 程序员 › 请教后端同学这种写接口的方式对不对？

两者都合理，具体还是看业务场景。

但第二种明显更好，毕竟你是获取 bookinfo ，其他东西没必要带给你，你再根据 bookinfo 里面的外键 id 去其他对应的接口查询即可。

这样的话再根据各个客户端的需求，去做就好了。比如页面需要一次性显示，app 不需要，那这样接口拆分的就很合理

再者就是可以“渐进式显示”，打开 bookinfo 页面，先显示 bookinfo ，然后再去请求 order ，这样用户就能先看到页面，不至于要等全部数据出来才显示。

比较复杂的例子：一个 bookinfo 里面，可能有 tags 、orders 、images 、comments ，如果全部给你，数据多的话体验会很差。那我可以先显示 bookinfo ，然后再根据用户点击的 tab ，再去加载对应的数据（懒加载）那体验会好很多，这样系统负载也会小很多，毕竟可能有的用户只是想某几个模块而已

1 ... 35 36 37 38 39 40 41 42 43 44 ... 154

❮

❯