- 主题:4个月了,没找到工作,大龄了确实惨,学习C++都难投入
rpc不稀奇,自动推断类型的rpc我觉得比较稀奇。
你想啊,前端本来只有js,js本身没类型,所以根本不存在这个需求。近年来ts崛起,前端也有类型了,后端很多人用node做胶水层了,前后端一个语言,中间隔了一个http,rpc两头的类型连不起来。这就是我说的问题
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你说的不就是 RPC 吗?我十几年前搞 DOJO 的时候就用 JSON-RPC
: 我当时自己写了一下 RPC 框架,把 JAVA 端的 interface 暴露给 js. 服务端出错了,前端还能抛出异常。
: 当时因为缺少 Proxy,前端需要先读方法列表。现在有 Proxy 就完美了。
: ...................
--
修改:beep FROM 223.72.57.*
FROM 223.72.57.*
这倒是。。我一般用 es6,没注意到你说的是 ts.
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: rpc不稀奇,自动推断类型的rpc我觉得比较稀奇。
: 你想啊,前端本来只有js,js本身没类型,所以根本不存在这个需求。近年来ts崛起,前端也有类型了,后端很多人用node做胶水层了,前后端一个语言,中间隔了一个http,rpc连构图的类型连不起来。这就是我说的问题
--
FROM 60.188.58.*
我开头就说痛点是前后端typing怎么连起来。。。
你说的这种不支持自动typing的rpc,js里也有一大把,什么feathers之类的,我也用过两三年,而且很深度地参与了feathers项目的维护。后来ts兴起以后,就义无反顾走ts+graphql路线了。我是无类型不舒服斯基,最近写python都全加typing,求个心里安稳
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这倒是。。我一般用 es6,没注意到你说的是 ts.
--
FROM 223.72.57.*
这里面有个大背景,就是我感觉前后端分离的分工越来越不流行了。我参与的几个公司项目,都感觉是同一个小组负责同一个业务的前后端开发,也就是常说的全栈,效率是最高的。同一个业务逻辑的前后端代码经常应该是同一个人写的,从数据表设计,到node,到vue/react,一个人搞定。
事实上培训这样的全栈小孩不难,现在小孩也都非常积极主动想要学全栈,一个vue程序员不懂点mysql、mongo、nodejs,都不好意思出来混。
当然,如果后端业务复杂了,比如要上集群、复杂的消息队列、和已有的非nodejs的业务模块对接,等等,肯定还需要其他语言的人。但即便如此,nodejs胶水层也可以做很多的工作,这就是这两三年很火的“bff(backend for frontend?)概念。
因为这样的js前后端全栈越来越普遍,所以前后端ts类型一致性的问题就越来越急迫
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我开头就说痛点是前后端typing怎么连起来。。。
: 你说的这种不支持自动typing的rpc,js里也有一大把,什么feathers之类的,我也用过两三年,而且很深度地参与了feathers项目的维护。后来ts兴起以后,就义无反顾走ts+graphql路线了。我是无类型不舒服斯基,最近写python都全加typing,求个心里安稳
--
FROM 223.72.57.*
每天编程10小时,不可能4个月学不会
【 在 lushan5436 的大作中提到: 】
: 不知道各位大佬是怎么解决35+的问题。
: 看到C++11之后的牛鬼蛇神般的表演,真心难学会。co-routine 都来了,这个看到就头大,也不知道为啥有这个必要。
来自 M2003J15SC
--
FROM 114.245.112.*
。。。你觉得我是不会c艹么?
会是个什么边界,达到写库模板水平算会,我确实四个月也达不到。把c++11的各种类库模板用得溜,我也不行,当然我很多也用过。
但漫天的auto,根本不知道什么类型,尤其是里class类型返回还auto的,我也确实学不会。
【 在 jamwswallace 的大作中提到: 】
: 每天编程10小时,不可能4个月学不会
: 来自 M2003J15SC
--
FROM 117.136.0.*
大概看了一下,就是比 next.js 走的更远了一些,把数据层也加到 react 控件里了呗?
只不过传统 mvc 框架是用后端渲染 html/css/js,这个是把后端逻辑揉在前端代码里。我觉得两者本质上是没有差别的,不管前端后端哪个胖哪个瘦,都是尽量在一端来实现全部逻辑,只不过多了 ts 的类型自动推导而已。
这其实又回到老的问题上,为什么传统的 mvc 框架被 web/API 分离的方式取代。主要一个原因就是 mobile app 的兴起,实现一套 api 就可以接不同的前端。不同的前端可能对数据有不同的需求,graphql 可以减少后端的开发工作量,避免没必要的数据库请求。
我觉得你的需求本质上还是代码重用的问题,只不过刚好前后端都是 ts,所以事情简单了许多。除了能重用类型以外,传统 mvc 框架存在的问题,其实一个都避免不了。
类型这个东西也挺没办法的,不同的数据库有自己的类型系统,每个语言也有自己的类型系统,gql 又有自己的 dsl 类型系统。所以如果是一个 ts 前端,gql 做 api,另外一个语言做后端,还有个数据库的系统,后端框架可能还有一套 dsl 做 db migration,所以加在一起大概得有5种以上的类型描述,基本上是在做同一件事情。我个人的倾向是数据和逻辑分离,而类型也是作为数据的一种,用 json/xml/yaml 或者 dsl 表示都没太大问题,然后作为 single source of truth 去生成其它的东西。然而这件事情如果做不好的话,那就又加入了一套类型描述的系统,于是又多了一个问题。
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我来说说为啥革命性:
: 全栈开发我觉得目前最麻烦的痛点是前后端的typing怎么连起来。前端用ts,后端也用ts(node)或者任何有类型标注的语言(python现在都有类型标注了,也不难用),各自的类型安全是可以很容易地保证的。
: 但是前端后端之间传递数据,要通过一个本质上无类型信息的http协议,到这里就把信息全丢了。接收端只能自己从头为这个api的返回值再写一遍类型,还要通过类似jsonschema之类的东西耗费性能来检查一遍类型合法性,然后api如果变了,还得手动修改类型。。麻烦的要死
: ...................
--
修改:eGust FROM 115.188.162.*
FROM 115.188.162.*
不知道各位大佬是怎么解决35+的问题。
------------
只会在单位上拿工资,肯定不行。你要有很多种本事,利用业余时间赚钱。当然最好还是有家庭背景。
--
FROM 59.52.252.*
不知道各位大佬是怎么解决35+的问题。
-------------
由于没有自由工会,你不可能通过罢工增加工资。不管哪个单位,都有共青团员。这些人一分钱不要,都会疯狂劳动。大搞个人崇拜,反美。自己家里很穷,无所谓。你也只有老老实实过苦日子。
--
FROM 59.52.252.*
那还学个甚么。4个月自己开发个产品都出来了。
【 在 lushan5436 的大作中提到: 】
: 。。。你觉得我是不会c艹么?
: 会是个什么边界,达到写库模板水平算会,我确实四个月也达不到。把c++11的各种类库模板用得溜,我也不行,当然我很多也用过。
: 但漫天的auto,根本不知道什么类型,尤其是里class类型返回还auto的,我也确实学不会。
: ...................
--
FROM 114.245.112.*