去年开始杭州感觉就明显和前年不一样了
招聘信息前年每天在群里刷不断 去年和今年寥寥无几

先回答问题
beego 官网里有个地方叫 产品案例 里面有一些开源项目

然后之前用 beego 写过 现在在用 gin,你也可以看看上面推荐的 echo

@orvice 看大家评论,也不完全是懒,也有很多无奈的地方.app 和 web 还是不太一样,ios 要过审什么的所以很多只能放服务端

礼物这种嘴上要了感觉总变味了..

@learnshare 是的 现在我就是只有两层 想慢慢分出来 被坑到了..

@Limius 嗯 这个问题之前没有很重视 的确很重要

@kaka8wp 比如我附加的说明?你看下是不是这个意思

@ideascf 唉 工作环境没这么理想化呢,我也想有个文档,写代码的时候只要动手动眼别动口.没办法

@crashX 刚好想到这个问题,应该问题也在我分层不是很清晰.前期规划的问题.对于这个事情上我自己看来问题也很大,准备慢慢解藕

@helloccav 这个问题感觉又很难完全有个标准.按页面有按页面的好处,按数据也是.前者连接数是会少,后者更加灵活和容易维护.扯到最后又要扯到具体需求了,不过这种我觉得可以灵活的定,但是可以有一个侧重面

@wizardoz 会有这个可能,主要用户量不上来,很多问题不愿意也可能都想不到,光凭嘴巴说服不了很尴尬

@ideascf 很同意你的说法 应该面向数据而不是页面, 做着做着就做到页面的误区了.回头想了下,主要应该是一般开发没文档,都是看着页面+口头问需求的原因...

@helloccav 明白你的意思了 这种会影响业务逻辑的改动 的确需要考虑进去 学习了

@Exin 是的 的确有发现这个问题 扁平化管理的缺陷

@rockyou12 主要不是在业务逻辑上,业务逻辑因为很多涉及到安全问题,基本都放服务端了,很多问题是在展现逻辑上,这个数据要帮他们整理好,这个数据帮他们拼接好等等,但是其实是可以从 A 接口和 B 接口里获取自己整合,现在需要给他们新写一个 C 接口,我就不太愿意,一个是增加维护成本,一个就是没复用性

@helloccav 可以说下你们客户端的想法...我看看我们逻辑差在哪里

@ytmsdy 对于 1,可能我自己太理想话了,想把性能上的问题在开发时候能考虑到的顺手都做了,客户端的意思是现在不用考虑这么多,等流量大了服务器啥的就多了,说不定客户端代码都重写了云云,我不知道怎么说服,三观不是很和. 2 我同意你说的,我思路主要和 1 一样,开发时候想到的想顺手做,这个优化的确可以滞后. 3 明白你的意思,对于事务操作肯定是放一个 api 处理了,这边主要是指的 get,数据整合类的逻辑,有时候需求数据可以从几个基础 API 获取自己整合,客户端不是很乐意

我也就吐槽下,他们想省力我也不是很有办法说服他们多写代码...

@minbaby ...我现在正在遇到这个问题,大佬们心情好点就少说我两句,帮我分担点,一般都是我这边都处理掉了

@dangyuluo 的确有这个问题...有时候我在表达我的想法,客户端大佬们觉得我想偷懒,少写点代码...我是觉得应该做的都会去做不会推卸,不应该做(意思是不应该放在服务器处理的)就不是很乐意做,不过最后都会妥协..因为项目组 ios+安卓有 2 个大佬,而服务端就我一个小弟,百口莫辩啊