d*y
2 楼
2017年9月1日，最后一次签完新京报书评周刊的版，我就彻底熔断了自己的媒体生涯，
也从此真正熔断了自己的职业生涯，解甲回家，扮演一个家庭煮男的角色，从此安心于
给女儿买菜做饭。
我这辈子，职业生涯自1989年7月起，28年，归纳起来无非就做了两件事，一件是在高
校教马克思主义基本原理，另一个就是在媒体行业服务。
第一件事，拿了个讲师职称，自此，我再也没有参与评定过任何职称，讲师成了我职业
生涯曾经拥有的最高职称。当然如今做不了了，也不会再去做了，尽管我偶然还会翻翻
马克思的一些作品，敬佩于他老人家的真知灼见。
第二件，自1994年借调到新闻出版署工作，迄今23年，一直在广义上的媒体行业服务，
走南闯北，换过不少工作，也博了些虚名，在别人眼中可以收割剩余价值的时候，却断
然与这个行业割袍断义，年过半百，从此回家相妻教女，选择新生活。
年轻人辞职换工作很正常，我这一辈子，换过很多工作，从离开体制开始，都是裸辞。
这个年龄（50岁）的时候，选择离开职场，需要别人想象不到的勇气。
我上有老下有小，老人年纪都大了，孩子还正上中学，夫妻俩身体也不是很好，需要足
够的收入养家糊口，维持相对有尊严的生活。相对有尊严的生活，经济是基础，而我缺
的，恰好就是人民币。
我出身普通农家，家无长物。这些年服务于传统媒体行业，工资一直不算高，我也从来
没有为收入斤斤计较过——2014年在深圳，当时我也是赋闲着，一位媒体业的前辈问我
：朱总，你应该实现财务自由了吧？谁谁谁他们不都实现财务自由了么？
我哈哈一笑，说，我如今每天早上起床，就琢磨一件事，今天柴米油盐酱醋茶的钱在哪
，写什么文章挣回来。虽然略微夸张了些，也是事实。像我服务过的媒体，传媒杂志、
南风窗、中国周刊，以及刚刚去职的新京报，如果能够实现财务自由的话，估计我早被
上电视忏悔了。
再说，自己这些年专注于在媒体业服务，心无旁骛，把人生最大的精力和智慧贡献给了
服务的媒体，自然也没有投资收益这样的外财。
虽然太座开了个小茶叶店，也只是挣个辛苦钱而已。尽管太座在我作出决定时给我最大
的支持，豪言“大不了我养你”——封新城兄感慨说，弟妹以一个女人的胸怀，养住了
中国最好的一个总编的情怀——但我心里清楚，第一她养不了我，第二，一个男人，怎
么能让女人挑起全家生活的重担？怎么忍心？
搁在封闭社会，比如说改革开放前，中国人都被固定在某一个单位集体上，一个离开体
制离开单位的人，很难生存，更别说有尊严的生活。
“世界已成颠倒梦，人生俱是可怜虫。”幸运的是，如今的时代虽然依然不堪，但相对
过去，累积了三十年改革开放、不完全市场经济、全球化、世贸体系和技术进步的福祉
，社会愈益多元，人们再也不用像涸泽之鲋非得依附于某个体制某个单位不可，相反，
离开体制，就像鱼儿游向了江海。
唐荆川有诗云“世网幸疏如野马”。感谢在世网稍疏时抓住机会成长起来的市民社会，
当然包括我们所有为之奋斗的人，合力摧毁了曾经细密无漏的一体网格化社会，成就了
今日“世网幸疏”的局面，也由此，我才能如脱缰野马，天涯任行。要搁过去，你想采
菊东篱下，你想天地一沙鸥，你想万顷波中得自由，你想向内在流亡，都只是一场残酷
的美梦。
我2004年与体制割袍断义，断然扎入市场的大潮，活得比体制内滋润许多，而且靠自己
的专业能力和职业操守，赢得了真正的尊严；2014年我又赋闲在家一年，也没饿死，而
且活得更滋润，游山乐水，逍遥自在。虽然著文为稻粱谋，但却依着我手写我心的准则
，从不卖身求财。
所以，我之熔断职业生涯，有过往经历背书，自有底气。
从2017年上半年一直为做有尊严的内容纠结挣扎，到9月1日断然放手，小舟从此逝，江
海寄余生，我的新生活开始了。
熔断三个月来，我其实并没有闲下。期间两下江南故乡，既为探亲，也为疗伤——这些
年服务媒体，内心也有诸多未及抚平的创伤，如今作为媒体的失败者回家寻求精神上的
慰藉——也为访友。感谢沪宁线上诸多亲朋好友，以一场接一场的流水酒席，欢迎游子
南归，而我的身心，在这些亲情友情和热情的大酒中，得到了彻底的放松。让所谓“追
求享乐、奢靡之风”成了彻头彻尾的笑话。
回北京后，见到一些故旧，故旧惊讶于我的气色。我哈哈一笑，说，自然，因为得自由
，因为终于摆脱了大合唱，再也不用虚与委蛇了。尽管“会议缪斯”（肖斯塔科维奇说
自己在莫斯科音乐学院学习时，院长每次开会都作曲，故称为会议缪斯，著名俄罗斯文
学翻译家蓝英年先生也跟我说过，五十年代后期政治学习时，他都默抄古诗词，我后来
也是在开会时抄诗，自嘲会议缪斯）抛弃了我，但如今自己想学什么，想说什么，想读
什么，想写什么，自己说了算。
这就是真正的精神自由，精神自由是最大的解放，自然会让人轻松自如了。就像2017年
7月31日傍晚我正式提出辞职，尽管因值夜班我凌晨才下班，又开了一天会，但因为歇
下了责任的重负，当天晚上，我喝了8两茅台，3瓶啤酒，打车回家后，又小楷歪歪扭扭
抄了首杜甫的《旅夜书怀》，虽然酒醉无力，但天地一沙鸥，却大熨我心。
熔断职业生涯以后，也有一些机构接触我，一些朋友也觉得我这样自我放逐江湖太过可
惜，但我以太座旨意“不准再接固定工作”为藉口，婉谢了所有的邀约，专心致志做一
个家庭煮男——这些年在外奔波，也到了该补偿家人的时候了。
如今我的日常生活，每天依然紧张忙碌，但已经不需要像过去那样修炼屠龙术了，这种
忙碌，是自由而舒心的忙碌，真实可触摸：
早起，站桩锻炼身体；
硬笔抄读外国诗歌或中国现代诗，以及古诗词；
整理流水账和公号，几乎每天发三条；
写文章，江南旧闻或读书笔记，饮食男女等等（每月文章有3万字左右，流水账也有3万
字左右）；感谢技术的进步，让我的文字得以通过诸如大鱼号这样的各种平台，得到传
播，并为有尊严的生活打下物质基础。就像阿斯塔菲耶夫说的那样：“我写的是和我个
人血肉相连的东西，结果却有很多人同样地感受着我的忧虑，我的痛楚。”
自己做午餐；写小楷；读书（每月读6-8本书）；
锻炼，步行暴走；
买菜，为家人做好饭，然后出门与朋友买醉……
稳定而有序，几乎天天如此，中间偶尔打断的，不过是出门办差开会等。
作为漏网之鱼，在网罗之外，我开始学会欣赏并热爱另一种生活，曾经因为所谓事业职
业而被遗忘的生活。那就是我们普通人的日常。
就像伊凡﹒克里玛告诉我们的：真正的生活绝非暂时决定人们命运的政治，而是在这种
强势压迫之下的私人领域的平凡和自在。
守住自己的世界，从容与自己的时光厮守，绝不把自己的世界交给自己鄙夷的人。
所以，与理想无关的生活，也要守住理想。认清生活真相之后，依然要热爱生活。这也
是对粗鄙时代的抵抗。这就是建设自己，也是改造社会，建设新中国。
我很喜欢胡德夫改写泰戈尔的诗唱的的《最最遥远的路》：
“这是最最遥远的路程
来到最接近你的地方
这是最最复杂的训练
这是最最遥远的路程
来到以前出发的地方
这是最后一个上坡
引向田园绝对的美丽
你我需穿透每场虚幻的梦
最后走进自己的门自己的田”
胡德夫说：“我写下这首《最最遥远的路》，来鼓励自己和一起朋友，我们走过这个上
坡，未来一定会变得更好。”
我也相信未来一定会更好。但前提是“你我需穿透每场虚幻的梦，最后走进自己的门自
己的田。”
我终于走进了自己的门自己的田。
也从此真正熔断了自己的职业生涯，解甲回家，扮演一个家庭煮男的角色，从此安心于
给女儿买菜做饭。
我这辈子，职业生涯自1989年7月起，28年，归纳起来无非就做了两件事，一件是在高
校教马克思主义基本原理，另一个就是在媒体行业服务。
第一件事，拿了个讲师职称，自此，我再也没有参与评定过任何职称，讲师成了我职业
生涯曾经拥有的最高职称。当然如今做不了了，也不会再去做了，尽管我偶然还会翻翻
马克思的一些作品，敬佩于他老人家的真知灼见。
第二件，自1994年借调到新闻出版署工作，迄今23年，一直在广义上的媒体行业服务，
走南闯北，换过不少工作，也博了些虚名，在别人眼中可以收割剩余价值的时候，却断
然与这个行业割袍断义，年过半百，从此回家相妻教女，选择新生活。
年轻人辞职换工作很正常，我这一辈子，换过很多工作，从离开体制开始，都是裸辞。
这个年龄（50岁）的时候，选择离开职场，需要别人想象不到的勇气。
我上有老下有小，老人年纪都大了，孩子还正上中学，夫妻俩身体也不是很好，需要足
够的收入养家糊口，维持相对有尊严的生活。相对有尊严的生活，经济是基础，而我缺
的，恰好就是人民币。
我出身普通农家，家无长物。这些年服务于传统媒体行业，工资一直不算高，我也从来
没有为收入斤斤计较过——2014年在深圳，当时我也是赋闲着，一位媒体业的前辈问我
：朱总，你应该实现财务自由了吧？谁谁谁他们不都实现财务自由了么？
我哈哈一笑，说，我如今每天早上起床，就琢磨一件事，今天柴米油盐酱醋茶的钱在哪
，写什么文章挣回来。虽然略微夸张了些，也是事实。像我服务过的媒体，传媒杂志、
南风窗、中国周刊，以及刚刚去职的新京报，如果能够实现财务自由的话，估计我早被
上电视忏悔了。
再说，自己这些年专注于在媒体业服务，心无旁骛，把人生最大的精力和智慧贡献给了
服务的媒体，自然也没有投资收益这样的外财。
虽然太座开了个小茶叶店，也只是挣个辛苦钱而已。尽管太座在我作出决定时给我最大
的支持，豪言“大不了我养你”——封新城兄感慨说，弟妹以一个女人的胸怀，养住了
中国最好的一个总编的情怀——但我心里清楚，第一她养不了我，第二，一个男人，怎
么能让女人挑起全家生活的重担？怎么忍心？
搁在封闭社会，比如说改革开放前，中国人都被固定在某一个单位集体上，一个离开体
制离开单位的人，很难生存，更别说有尊严的生活。
“世界已成颠倒梦，人生俱是可怜虫。”幸运的是，如今的时代虽然依然不堪，但相对
过去，累积了三十年改革开放、不完全市场经济、全球化、世贸体系和技术进步的福祉
，社会愈益多元，人们再也不用像涸泽之鲋非得依附于某个体制某个单位不可，相反，
离开体制，就像鱼儿游向了江海。
唐荆川有诗云“世网幸疏如野马”。感谢在世网稍疏时抓住机会成长起来的市民社会，
当然包括我们所有为之奋斗的人，合力摧毁了曾经细密无漏的一体网格化社会，成就了
今日“世网幸疏”的局面，也由此，我才能如脱缰野马，天涯任行。要搁过去，你想采
菊东篱下，你想天地一沙鸥，你想万顷波中得自由，你想向内在流亡，都只是一场残酷
的美梦。
我2004年与体制割袍断义，断然扎入市场的大潮，活得比体制内滋润许多，而且靠自己
的专业能力和职业操守，赢得了真正的尊严；2014年我又赋闲在家一年，也没饿死，而
且活得更滋润，游山乐水，逍遥自在。虽然著文为稻粱谋，但却依着我手写我心的准则
，从不卖身求财。
所以，我之熔断职业生涯，有过往经历背书，自有底气。
从2017年上半年一直为做有尊严的内容纠结挣扎，到9月1日断然放手，小舟从此逝，江
海寄余生，我的新生活开始了。
熔断三个月来，我其实并没有闲下。期间两下江南故乡，既为探亲，也为疗伤——这些
年服务媒体，内心也有诸多未及抚平的创伤，如今作为媒体的失败者回家寻求精神上的
慰藉——也为访友。感谢沪宁线上诸多亲朋好友，以一场接一场的流水酒席，欢迎游子
南归，而我的身心，在这些亲情友情和热情的大酒中，得到了彻底的放松。让所谓“追
求享乐、奢靡之风”成了彻头彻尾的笑话。
回北京后，见到一些故旧，故旧惊讶于我的气色。我哈哈一笑，说，自然，因为得自由
，因为终于摆脱了大合唱，再也不用虚与委蛇了。尽管“会议缪斯”（肖斯塔科维奇说
自己在莫斯科音乐学院学习时，院长每次开会都作曲，故称为会议缪斯，著名俄罗斯文
学翻译家蓝英年先生也跟我说过，五十年代后期政治学习时，他都默抄古诗词，我后来
也是在开会时抄诗，自嘲会议缪斯）抛弃了我，但如今自己想学什么，想说什么，想读
什么，想写什么，自己说了算。
这就是真正的精神自由，精神自由是最大的解放，自然会让人轻松自如了。就像2017年
7月31日傍晚我正式提出辞职，尽管因值夜班我凌晨才下班，又开了一天会，但因为歇
下了责任的重负，当天晚上，我喝了8两茅台，3瓶啤酒，打车回家后，又小楷歪歪扭扭
抄了首杜甫的《旅夜书怀》，虽然酒醉无力，但天地一沙鸥，却大熨我心。
熔断职业生涯以后，也有一些机构接触我，一些朋友也觉得我这样自我放逐江湖太过可
惜，但我以太座旨意“不准再接固定工作”为藉口，婉谢了所有的邀约，专心致志做一
个家庭煮男——这些年在外奔波，也到了该补偿家人的时候了。
如今我的日常生活，每天依然紧张忙碌，但已经不需要像过去那样修炼屠龙术了，这种
忙碌，是自由而舒心的忙碌，真实可触摸：
早起，站桩锻炼身体；
硬笔抄读外国诗歌或中国现代诗，以及古诗词；
整理流水账和公号，几乎每天发三条；
写文章，江南旧闻或读书笔记，饮食男女等等（每月文章有3万字左右，流水账也有3万
字左右）；感谢技术的进步，让我的文字得以通过诸如大鱼号这样的各种平台，得到传
播，并为有尊严的生活打下物质基础。就像阿斯塔菲耶夫说的那样：“我写的是和我个
人血肉相连的东西，结果却有很多人同样地感受着我的忧虑，我的痛楚。”
自己做午餐；写小楷；读书（每月读6-8本书）；
锻炼，步行暴走；
买菜，为家人做好饭，然后出门与朋友买醉……
稳定而有序，几乎天天如此，中间偶尔打断的，不过是出门办差开会等。
作为漏网之鱼，在网罗之外，我开始学会欣赏并热爱另一种生活，曾经因为所谓事业职
业而被遗忘的生活。那就是我们普通人的日常。
就像伊凡﹒克里玛告诉我们的：真正的生活绝非暂时决定人们命运的政治，而是在这种
强势压迫之下的私人领域的平凡和自在。
守住自己的世界，从容与自己的时光厮守，绝不把自己的世界交给自己鄙夷的人。
所以，与理想无关的生活，也要守住理想。认清生活真相之后，依然要热爱生活。这也
是对粗鄙时代的抵抗。这就是建设自己，也是改造社会，建设新中国。
我很喜欢胡德夫改写泰戈尔的诗唱的的《最最遥远的路》：
“这是最最遥远的路程
来到最接近你的地方
这是最最复杂的训练
这是最最遥远的路程
来到以前出发的地方
这是最后一个上坡
引向田园绝对的美丽
你我需穿透每场虚幻的梦
最后走进自己的门自己的田”
胡德夫说：“我写下这首《最最遥远的路》，来鼓励自己和一起朋友，我们走过这个上
坡，未来一定会变得更好。”
我也相信未来一定会更好。但前提是“你我需穿透每场虚幻的梦，最后走进自己的门自
己的田。”
我终于走进了自己的门自己的田。
d*n
3 楼
看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
难道3年河东3年河西RESTFul这套真的要被淘汰了？
难道3年河东3年河西RESTFul这套真的要被淘汰了？
d*y
4 楼
SEES。刚看到的，如果你组里的人是米国公民或者有绿卡的话
w*r
5 楼
之前big data visual analytics火过一阵吧，但那是基于本机的。我几天前说正真的
云计算时代要来了，不知道有没有人信。以后跟数据相关的绝大部分计算都会在云里。
一般人用电脑，工作，基本都在浏览器里完成。所以，graphgl能火
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
云计算时代要来了，不知道有没有人信。以后跟数据相关的绝大部分计算都会在云里。
一般人用电脑，工作，基本都在浏览器里完成。所以，graphgl能火
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
w*r
6 楼
参考隔壁swiftdove的问题，首先也是上visual analytics，觉得make sense在找合适
的处理算法
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
的处理算法
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
w*g
7 楼
没觉得火。graphql这东西早就有了。我之前研究过一下。
语言越到后面越罗嗦，属于脱裤子放屁。
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
语言越到后面越罗嗦，属于脱裤子放屁。
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
g*t
8 楼
不是不信你。是這條路散戶只能做個螺絲釘。無法彎道超車。另外好多坑都是人挖的，
沒什麼規律和道理。面對很多unknown,而不是uncertain,個人的智慧和能力無用武之地。
所以我是反着看這個問題的。edge computing 分布式計算也可以做。
: 之前big data visual analytics火过一阵吧，但那是基于本机的。我几
天前说
正真的
: 云计算时代要来了，不知道有没有人信。以后跟数据相关的绝大部分计算
都会在
云里。
: 一般人用电脑，工作，基本都在浏览器里完成。所以，graphgl能火
【在 w*****r 的大作中提到】
: 参考隔壁swiftdove的问题，首先也是上visual analytics，觉得make sense在找合适
: 的处理算法
沒什麼規律和道理。面對很多unknown,而不是uncertain,個人的智慧和能力無用武之地。
所以我是反着看這個問題的。edge computing 分布式計算也可以做。
: 之前big data visual analytics火过一阵吧，但那是基于本机的。我几
天前说
正真的
: 云计算时代要来了，不知道有没有人信。以后跟数据相关的绝大部分计算
都会在
云里。
: 一般人用电脑，工作，基本都在浏览器里完成。所以，graphgl能火
【在 w*****r 的大作中提到】
: 参考隔壁swiftdove的问题，首先也是上visual analytics，觉得make sense在找合适
: 的处理算法
t*n
9 楼
GraphQL比RestFul强多了。不是一个层次的。
s*i
10 楼
非常同意wflower。真正的云时代正在发生和到来。
就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
Query直接让前端来定义，免得翻来覆去的写后端。
这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
1. ORM
2. Backend development in general
3. Containers
走上坡坡路的几个东西：
1. Serverless (lambda or functions, API Gateways etc)
2. GraphQL (和类似的前端query 框架）
3. Frontend developement
就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
Query直接让前端来定义，免得翻来覆去的写后端。
这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
1. ORM
2. Backend development in general
3. Containers
走上坡坡路的几个东西：
1. Serverless (lambda or functions, API Gateways etc)
2. GraphQL (和类似的前端query 框架）
3. Frontend developement
g*t
11 楼
从算力来看，后端除了显卡，没什么大的变化。所以后端的新技术应该是如何用好显卡
。整个这波AI核心的技术也可以认为是如何使用好GPU。
前端的话，智能手机的量上来后，造成前端CPU和传感器成本大幅下降。
所以计算的新技术我觉得就是在前端和后端GPU.
但是前端把自己锁在浏览器里，这个我认为不太合乎逻辑。
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问
题。无
非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送
给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就
是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基
本上就
是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
。整个这波AI核心的技术也可以认为是如何使用好GPU。
前端的话，智能手机的量上来后，造成前端CPU和传感器成本大幅下降。
所以计算的新技术我觉得就是在前端和后端GPU.
但是前端把自己锁在浏览器里，这个我认为不太合乎逻辑。
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问
题。无
非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送
给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就
是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基
本上就
是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
g*t
12 楼
展開說說為啥container走下坡路？這條沒看懂。
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无
非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就
是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无
非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就
是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
g*t
13 楼
Restful 資源是定死的。可能他們想解決這個問題吧？但是其實把資源的名字做成一张
表格，當作資源的
話，這問題就不存在了。
感覺這個就是有沒有，以及需要不需要一個統一的規範在restful資源之上加wrapper的
問題。
: 没觉得火。graphql这东西早就有了。我之前研究过一下。
: 语言越到后面越罗嗦，属于脱裤子放屁。
【在 w***g 的大作中提到】
: 没觉得火。graphql这东西早就有了。我之前研究过一下。
: 语言越到后面越罗嗦，属于脱裤子放屁。
表格，當作資源的
話，這問題就不存在了。
感覺這個就是有沒有，以及需要不需要一個統一的規範在restful資源之上加wrapper的
問題。
: 没觉得火。graphql这东西早就有了。我之前研究过一下。
: 语言越到后面越罗嗦，属于脱裤子放屁。
【在 w***g 的大作中提到】
: 没觉得火。graphql这东西早就有了。我之前研究过一下。
: 语言越到后面越罗嗦，属于脱裤子放屁。
d*n
14 楼
lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该都是从WP转过
来的应用吧？
不过为啥前端还能上坡？不是一直在鄙视链底端吗？
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
来的应用吧？
不过为啥前端还能上坡？不是一直在鄙视链底端吗？
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
g*t
15 楼
1.
现在传感器极其便宜。前端CPU和效率的提高也很大。所以老魏十年前知道看IoT还是挺
有眼光的。因为IoT, C语言的份额都提高了不少。
2.
本版做mobile的少。之前我看到个统计，Android studio似乎都占到所有editor/IDE的
1/10以上。mobile就是前端。
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该
都是从
WP转过
: 来的应用吧？
: 不过为啥前端还能上坡？不是一直在鄙视链底端吗？
【在 d****n 的大作中提到】
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该都是从WP转过
: 来的应用吧？
: 不过为啥前端还能上坡？不是一直在鄙视链底端吗？
现在传感器极其便宜。前端CPU和效率的提高也很大。所以老魏十年前知道看IoT还是挺
有眼光的。因为IoT, C语言的份额都提高了不少。
2.
本版做mobile的少。之前我看到个统计，Android studio似乎都占到所有editor/IDE的
1/10以上。mobile就是前端。
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该
都是从
WP转过
: 来的应用吧？
: 不过为啥前端还能上坡？不是一直在鄙视链底端吗？
【在 d****n 的大作中提到】
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该都是从WP转过
: 来的应用吧？
: 不过为啥前端还能上坡？不是一直在鄙视链底端吗？
t*n
16 楼
REST vs GraphQL
类似于汇编 vs C++
现在干嘛用汇编写啊？
类似于汇编 vs C++
现在干嘛用汇编写啊？
d*n
17 楼
c语言份额还能上升？
【在 g****t 的大作中提到】
: 1.
: 现在传感器极其便宜。前端CPU和效率的提高也很大。所以老魏十年前知道看IoT还是挺
: 有眼光的。因为IoT, C语言的份额都提高了不少。
: 2.
: 本版做mobile的少。之前我看到个统计，Android studio似乎都占到所有editor/IDE的
: 1/10以上。mobile就是前端。
:
:
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该
: 都是从
: WP转过
【在 g****t 的大作中提到】
: 1.
: 现在传感器极其便宜。前端CPU和效率的提高也很大。所以老魏十年前知道看IoT还是挺
: 有眼光的。因为IoT, C语言的份额都提高了不少。
: 2.
: 本版做mobile的少。之前我看到个统计，Android studio似乎都占到所有editor/IDE的
: 1/10以上。mobile就是前端。
:
:
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该
: 都是从
: WP转过
w*m
18 楼
同不看好GraphQL。
一个DSL不是解决前后端通讯的银弹。
这种用前端直接操作数据库的尝试，以前也有。
最后都毁在安全问题上了。
看好RPC替代REST。
一个DSL不是解决前后端通讯的银弹。
这种用前端直接操作数据库的尝试，以前也有。
最后都毁在安全问题上了。
看好RPC替代REST。
s*i
19 楼
如果是以前的编点简单的 Html，css的确在鄙视链。现在都是framework，逻辑很多都
跑前端了，再加上GraphQL这种对数据的理解，要求非常高。
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该都是从
WP转过
: 来的应用吧？
: 不过为啥前端还能上坡？不是一直在鄙视链底端吗？
【在 d****n 的大作中提到】
: c语言份额还能上升？
跑前端了，再加上GraphQL这种对数据的理解，要求非常高。
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该都是从
WP转过
: 来的应用吧？
: 不过为啥前端还能上坡？不是一直在鄙视链底端吗？
【在 d****n 的大作中提到】
: c语言份额还能上升？
f*2
20 楼
RPC替代rest，好！不是小好，而是大好
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
【在 w********m 的大作中提到】
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
【在 w********m 的大作中提到】
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
t*n
21 楼
咋扯安全性上了？跟安全性两码事。
【在 w********m 的大作中提到】
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
【在 w********m 的大作中提到】
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
c*o
22 楼
在做GRAPHQL, 主要是可以作比较复杂的结构，能够按需读取部分，资源和API分开了，
而且前端缓存很舒服。
而且前端缓存很舒服。
c*o
23 楼
对，安全性和这个rest/graphql 根本是完全独立的。
【在 t*****n 的大作中提到】
: 咋扯安全性上了？跟安全性两码事。
【在 t*****n 的大作中提到】
: 咋扯安全性上了？跟安全性两码事。
c*n
24 楼
请教下 缓存是怎么做的 以前rest直接扔redis就好了
【在 c******o 的大作中提到】
: 在做GRAPHQL, 主要是可以作比较复杂的结构，能够按需读取部分，资源和API分开了，
: 而且前端缓存很舒服。
【在 c******o 的大作中提到】
: 在做GRAPHQL, 主要是可以作比较复杂的结构，能够按需读取部分，资源和API分开了，
: 而且前端缓存很舒服。
w*m
25 楼
graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
设计各种injection很方便，总可以把数据库dump出来。
还有一个nest，相当于一个join。
多弄几个nest，就把数据库累死了。DDoS也很方便。
总之，出问题的几率大。
【在 c******o 的大作中提到】
: 对，安全性和这个rest/graphql 根本是完全独立的。
设计各种injection很方便，总可以把数据库dump出来。
还有一个nest，相当于一个join。
多弄几个nest，就把数据库累死了。DDoS也很方便。
总之，出问题的几率大。
【在 c******o 的大作中提到】
: 对，安全性和这个rest/graphql 根本是完全独立的。
t*n
26 楼
你用过吗？感觉在想当然。
【在 w********m 的大作中提到】
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
: 设计各种injection很方便，总可以把数据库dump出来。
: 还有一个nest，相当于一个join。
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
: 总之，出问题的几率大。
【在 w********m 的大作中提到】
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
: 设计各种injection很方便，总可以把数据库dump出来。
: 还有一个nest，相当于一个join。
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
: 总之，出问题的几率大。
c*o
27 楼
完全不知道你在说啥。 这个怎么暴露schema啊？ 数据还从不同的地方来的，有
postgresql,Hbase,mongodb你这怎么能暴露schema啊？很多数据都是要复杂的处理完才
出来的，还有async的。和直连数据库的两回事。
大部分数据根本就不是直通数据库的。
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
: 设计各种injection很方便，总可以把数据库dump出来。
: 还有一个nest，相当于一个join。
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
: 总之，出问题的几率大。
【在 w********m 的大作中提到】
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
: 设计各种injection很方便，总可以把数据库dump出来。
: 还有一个nest，相当于一个join。
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
: 总之，出问题的几率大。
postgresql,Hbase,mongodb你这怎么能暴露schema啊？很多数据都是要复杂的处理完才
出来的，还有async的。和直连数据库的两回事。
大部分数据根本就不是直通数据库的。
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
: 设计各种injection很方便，总可以把数据库dump出来。
: 还有一个nest，相当于一个join。
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
: 总之，出问题的几率大。
【在 w********m 的大作中提到】
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
: 设计各种injection很方便，总可以把数据库dump出来。
: 还有一个nest，相当于一个join。
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
: 总之，出问题的几率大。
w*m
28 楼
sorry did not clarify.
1. 那个相当于protocol buffer的schema， 比如type Project {
name: String
tagline: String
contributors: [User]
} 在网站上，是完全透明的，get-graphql-schema https://swapi.graph.cool， 谁都
可以看到。 可以设计字典做injection attack。
2. nest可以无限扩展。比如{hero{friends{hero{friends}}}}. 这里面的nest其实很
消耗资源，很多是db里面的join。完全可以设计死循环，做DDoS。
3. 作为DSL的query， 比如mutation {
createPerson(name: "Alice", age: 36) {
id
}
}不是经历过考验的json，而是一个新的string。各个语言都是自己写的parser，不一
定能escape干净。增加injection风险。
4. 同上，一般的安全系统无法识别，比如极度依赖cloudflare的mitbbs。
总之，不建议在敏感系统使用。
【在 c******o 的大作中提到】
: 完全不知道你在说啥。 这个怎么暴露schema啊？ 数据还从不同的地方来的，有
: postgresql,Hbase,mongodb你这怎么能暴露schema啊？很多数据都是要复杂的处理完才
: 出来的，还有async的。和直连数据库的两回事。
: 大部分数据根本就不是直通数据库的。
:
:
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
:
: 设计各种injection很方便，总可以把数据库dump出来。
:
: 还有一个nest，相当于一个join。
:
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
:
: 总之，出问题的几率大。
1. 那个相当于protocol buffer的schema， 比如type Project {
name: String
tagline: String
contributors: [User]
} 在网站上，是完全透明的，get-graphql-schema https://swapi.graph.cool， 谁都
可以看到。 可以设计字典做injection attack。
2. nest可以无限扩展。比如{hero{friends{hero{friends}}}}. 这里面的nest其实很
消耗资源，很多是db里面的join。完全可以设计死循环，做DDoS。
3. 作为DSL的query， 比如mutation {
createPerson(name: "Alice", age: 36) {
id
}
}不是经历过考验的json，而是一个新的string。各个语言都是自己写的parser，不一
定能escape干净。增加injection风险。
4. 同上，一般的安全系统无法识别，比如极度依赖cloudflare的mitbbs。
总之，不建议在敏感系统使用。
【在 c******o 的大作中提到】
: 完全不知道你在说啥。 这个怎么暴露schema啊？ 数据还从不同的地方来的，有
: postgresql,Hbase,mongodb你这怎么能暴露schema啊？很多数据都是要复杂的处理完才
: 出来的，还有async的。和直连数据库的两回事。
: 大部分数据根本就不是直通数据库的。
:
:
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
:
: 设计各种injection很方便，总可以把数据库dump出来。
:
: 还有一个nest，相当于一个join。
:
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
:
: 总之，出问题的几率大。
i*l
29 楼
然而你说的这些， 用在 plain json 身上也说得通啊
【在 w********m 的大作中提到】
: sorry did not clarify.
: 1. 那个相当于protocol buffer的schema， 比如type Project {
: name: String
: tagline: String
: contributors: [User]
: } 在网站上，是完全透明的，get-graphql-schema https://swapi.graph.cool， 谁都
: 可以看到。 可以设计字典做injection attack。
: 2. nest可以无限扩展。比如{hero{friends{hero{friends}}}}. 这里面的nest其实很
: 消耗资源，很多是db里面的join。完全可以设计死循环，做DDoS。
: 3. 作为DSL的query， 比如mutation {
【在 w********m 的大作中提到】
: sorry did not clarify.
: 1. 那个相当于protocol buffer的schema， 比如type Project {
: name: String
: tagline: String
: contributors: [User]
: } 在网站上，是完全透明的，get-graphql-schema https://swapi.graph.cool， 谁都
: 可以看到。 可以设计字典做injection attack。
: 2. nest可以无限扩展。比如{hero{friends{hero{friends}}}}. 这里面的nest其实很
: 消耗资源，很多是db里面的join。完全可以设计死循环，做DDoS。
: 3. 作为DSL的query， 比如mutation {
n*p
30 楼
顺藤摸瓜，发现Walmart的production不光在用graphql,还有自己的implementation
https://github.com/walmartlabs/lacinia
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
https://github.com/walmartlabs/lacinia
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
w*m
31 楼
大概是这样的,graphql发明的过程，
有一天，facebook有个前端哥们喝高了，觉得sql很好用，像这样的
select name
from user
where id = 1
然后他改头换面了一下
query {
user(id: 1) {
name
}
}
于是用query string传sql的做法，在这个哥们手里实现了。
附送全套schema一份，外加无限nest无限join的能力。
大概，以后graphql injection可以养活很多黑道人士吧。
【在 i******l 的大作中提到】
: 然而你说的这些， 用在 plain json 身上也说得通啊
有一天，facebook有个前端哥们喝高了，觉得sql很好用，像这样的
select name
from user
where id = 1
然后他改头换面了一下
query {
user(id: 1) {
name
}
}
于是用query string传sql的做法，在这个哥们手里实现了。
附送全套schema一份，外加无限nest无限join的能力。
大概，以后graphql injection可以养活很多黑道人士吧。
【在 i******l 的大作中提到】
: 然而你说的这些， 用在 plain json 身上也说得通啊
c*n
32 楼
我觉得是这样的
某天fb某个前端哥们正要下班 三哥PM来到身后 对着脖子吹着气 说半小时前说的那个
需求要稍微改一下
这哥们一看 这一改要动得可多 隔壁后端早撂摊子走人了 没法专门新做个api 用现有
api的话得500多个get才能拿全
三哥还说这次做好了还有下一步 恨不得几千个api都要走一圈
得 别下班了想个办法解决吧
【在 w********m 的大作中提到】
: 大概是这样的,graphql发明的过程，
: 有一天，facebook有个前端哥们喝高了，觉得sql很好用，像这样的
: select name
: from user
: where id = 1
: 然后他改头换面了一下
: query {
: user(id: 1) {
: name
: }
某天fb某个前端哥们正要下班 三哥PM来到身后 对着脖子吹着气 说半小时前说的那个
需求要稍微改一下
这哥们一看 这一改要动得可多 隔壁后端早撂摊子走人了 没法专门新做个api 用现有
api的话得500多个get才能拿全
三哥还说这次做好了还有下一步 恨不得几千个api都要走一圈
得 别下班了想个办法解决吧
【在 w********m 的大作中提到】
: 大概是这样的,graphql发明的过程，
: 有一天，facebook有个前端哥们喝高了，觉得sql很好用，像这样的
: select name
: from user
: where id = 1
: 然后他改头换面了一下
: query {
: user(id: 1) {
: name
: }
c*n
33 楼
这个文章里面貌似还是无脑cache
cacheControl也只是设了个maxAge
GraphQL从本质上来说这样会触发的cache会比传统REST多1 2个量级吧？
https://medium.com/brikl-engineering/serverless-graphql-cached-in-redis-with
-apollo-server-2-0-f491695cac7f
The flow will be:
Our client will be sending a GraphQL request off to the API Gateway which
then proxies the request to our AWS Lambda.
Apollo Server will then translate the query to the data source in the schema.
Apollo Server will check if the type is ‘cacheable’ (cacheControl), if so
it will look in our Redis endpoint for a cached response.
If there is no cached response it will send of a request to our REST API (NY
Times) in this case. Again it will check if the response is ‘cacheable’
and store the result in Redis.
cacheControl也只是设了个maxAge
GraphQL从本质上来说这样会触发的cache会比传统REST多1 2个量级吧？
https://medium.com/brikl-engineering/serverless-graphql-cached-in-redis-with
-apollo-server-2-0-f491695cac7f
The flow will be:
Our client will be sending a GraphQL request off to the API Gateway which
then proxies the request to our AWS Lambda.
Apollo Server will then translate the query to the data source in the schema.
Apollo Server will check if the type is ‘cacheable’ (cacheControl), if so
it will look in our Redis endpoint for a cached response.
If there is no cached response it will send of a request to our REST API (NY
Times) in this case. Again it will check if the response is ‘cacheable’
and store the result in Redis.
S*e
34 楼
http://www.mitbbs.com/article_t/Biology/32097527.html
Quote： GraphQL实现起来方便呗，大家又比较熟，通用性比较好。我们一些需要实时
更新的query，基本上用这个来实现。
Quote： GraphQL实现起来方便呗，大家又比较熟，通用性比较好。我们一些需要实时
更新的query，基本上用这个来实现。
d*n
35 楼
营养贴先顶再消化
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
d*n
36 楼
对后台有几个观点，商榷：
1. 企业级应有后台负责复杂的计算和商业逻辑，完全不仅仅是数据库取数据这么简单。
2 后台与前台要求不一样。 后台要考虑很多非功能性的需求，像支持大量用户，多渠
道通信，全时段服务等等, 满足这些需求难度往往比随便返回一个数据库查询难度大多
了。
不了解graphql, 如果它能够很好的回答以上问题，倒是很有意思的工具。
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
1. 企业级应有后台负责复杂的计算和商业逻辑，完全不仅仅是数据库取数据这么简单。
2 后台与前台要求不一样。 后台要考虑很多非功能性的需求，像支持大量用户，多渠
道通信，全时段服务等等, 满足这些需求难度往往比随便返回一个数据库查询难度大多
了。
不了解graphql, 如果它能够很好的回答以上问题，倒是很有意思的工具。
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
相关阅读
Full story of GO's three level schedulergithub可以让合作者不能push吗？怎么自学spark？请教大牛一个很老的VISUAL STUDIO6.0 的问题K8S , golang别犹豫请问网页app 能怎么实现多线程？国内的参考资料[bssd]再论《金瓶梅》：作者派来的人台巴子造谣被抓包： (转载)清晰，明确的核心竞争力調度機器都是簡單的，調度人才是最難的。为啥Linux这种上古架构竟然能一统服务器的江湖？golang是第一个大规模multi-core, N：M thread model Language机器学习准入门槛降低，机器学习工程师职位或将消失zz想听听大家意见：e commerce UI 框架 Vue react ？可判定程序，如何可以叫做AIhow to find old articles about 12306 and TeachWei's code?Deep Learning云端的深学算法例如Google Vision怎么做到噪声隔离Re: 贾扬清被国人“同胞”捅刀子，被迫离开fb (转载)