d****n
发帖数: 12461 | 1 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
难道3年河东3年河西RESTFul这套真的要被淘汰了？ |
w*****r
发帖数: 197 | 2 之前big data visual analytics火过一阵吧，但那是基于本机的。我几天前说正真的
云计算时代要来了，不知道有没有人信。以后跟数据相关的绝大部分计算都会在云里。
一般人用电脑，工作，基本都在浏览器里完成。所以，graphgl能火
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
|
w*****r
发帖数: 197 | 3 参考隔壁swiftdove的问题，首先也是上visual analytics，觉得make sense在找合适
的处理算法
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
|
w***g
发帖数: 5958 | 4 没觉得火。graphql这东西早就有了。我之前研究过一下。
语言越到后面越罗嗦，属于脱裤子放屁。
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
|
g****t
发帖数: 31659 | 5 不是不信你。是這條路散戶只能做個螺絲釘。無法彎道超車。另外好多坑都是人挖的，
沒什麼規律和道理。面對很多unknown,而不是uncertain,個人的智慧和能力無用武之地。
所以我是反着看這個問題的。edge computing 分布式計算也可以做。
: 之前big data visual analytics火过一阵吧，但那是基于本机的。我几
天前说
正真的
: 云计算时代要来了，不知道有没有人信。以后跟数据相关的绝大部分计算
都会在
云里。
: 一般人用电脑，工作，基本都在浏览器里完成。所以，graphgl能火
【在 w*****r 的大作中提到】
: 参考隔壁swiftdove的问题，首先也是上visual analytics，觉得make sense在找合适
: 的处理算法
|
t*****n
发帖数: 2578 | 6 GraphQL比RestFul强多了。不是一个层次的。 |
s*i
发帖数: 5025 | 7 非常同意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 |
g****t
发帖数: 31659 | 8 从算力来看，后端除了显卡，没什么大的变化。所以后端的新技术应该是如何用好显卡
。整个这波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
发帖数: 31659 | 9 展開說說為啥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
|
g****t
发帖数: 31659 | 10 Restful 資源是定死的。可能他們想解決這個問題吧？但是其實把資源的名字做成一张
表格，當作資源的
話，這問題就不存在了。
感覺這個就是有沒有，以及需要不需要一個統一的規範在restful資源之上加wrapper的
問題。
: 没觉得火。graphql这东西早就有了。我之前研究过一下。
: 语言越到后面越罗嗦，属于脱裤子放屁。
【在 w***g 的大作中提到】
: 没觉得火。graphql这东西早就有了。我之前研究过一下。
: 语言越到后面越罗嗦，属于脱裤子放屁。
|
|
|
d****n
发帖数: 12461 | 11 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
|
g****t
发帖数: 31659 | 12 1.
现在传感器极其便宜。前端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
发帖数: 2578 | 13 REST vs GraphQL
类似于汇编 vs C++
现在干嘛用汇编写啊？ |
d****n
发帖数: 12461 | 14 c语言份额还能上升？
【在 g****t 的大作中提到】
: 1.
: 现在传感器极其便宜。前端CPU和效率的提高也很大。所以老魏十年前知道看IoT还是挺
: 有眼光的。因为IoT, C语言的份额都提高了不少。
: 2.
: 本版做mobile的少。之前我看到个统计，Android studio似乎都占到所有editor/IDE的
: 1/10以上。mobile就是前端。
:
:
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该
: 都是从
: WP转过
|
w********m
发帖数: 1137 | 15 同不看好GraphQL。
一个DSL不是解决前后端通讯的银弹。
这种用前端直接操作数据库的尝试，以前也有。
最后都毁在安全问题上了。
看好RPC替代REST。 |
s*i
发帖数: 5025 | 16 如果是以前的编点简单的 Html，css的确在鄙视链。现在都是framework，逻辑很多都
跑前端了，再加上GraphQL这种对数据的理解，要求非常高。
: lambda没过时？serverless现在还是炒作阶段吧。能做serverless的应该都是从
WP转过
: 来的应用吧？
: 不过为啥前端还能上坡？不是一直在鄙视链底端吗？
【在 d****n 的大作中提到】
: c语言份额还能上升？
|
f******2
发帖数: 2455 | 17 RPC替代rest，好！不是小好，而是大好
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
【在 w********m 的大作中提到】
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
|
t*****n
发帖数: 2578 | 18 咋扯安全性上了？跟安全性两码事。
【在 w********m 的大作中提到】
: 同不看好GraphQL。
: 一个DSL不是解决前后端通讯的银弹。
: 这种用前端直接操作数据库的尝试，以前也有。
: 最后都毁在安全问题上了。
: 看好RPC替代REST。
|
c******o
发帖数: 1277 | 19 在做GRAPHQL, 主要是可以作比较复杂的结构，能够按需读取部分，资源和API分开了，
而且前端缓存很舒服。 |
c******o
发帖数: 1277 | 20 对，安全性和这个rest/graphql 根本是完全独立的。
【在 t*****n 的大作中提到】
: 咋扯安全性上了？跟安全性两码事。
|
|
|
c******n
发帖数: 16666 | 21 请教下 缓存是怎么做的 以前rest直接扔redis就好了
【在 c******o 的大作中提到】
: 在做GRAPHQL, 主要是可以作比较复杂的结构，能够按需读取部分，资源和API分开了，
: 而且前端缓存很舒服。
|
w********m
发帖数: 1137 | 22 graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
设计各种injection很方便，总可以把数据库dump出来。
还有一个nest，相当于一个join。
多弄几个nest，就把数据库累死了。DDoS也很方便。
总之，出问题的几率大。
【在 c******o 的大作中提到】
: 对，安全性和这个rest/graphql 根本是完全独立的。
|
t*****n
发帖数: 2578 | 23 你用过吗？感觉在想当然。
【在 w********m 的大作中提到】
: graphql把整个schema暴露着。他那个query string能不能escape干净不确定。
: 设计各种injection很方便，总可以把数据库dump出来。
: 还有一个nest，相当于一个join。
: 多弄几个nest，就把数据库累死了。DDoS也很方便。
: 总之，出问题的几率大。
|
c******o
发帖数: 1277 | 24 完全不知道你在说啥。 这个怎么暴露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也很方便。
: 总之，出问题的几率大。
|
w********m
发帖数: 1137 | 25 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也很方便。
:
: 总之，出问题的几率大。
|
i******l
发帖数: 270 | 26 然而你说的这些， 用在 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 {
|
n***p
发帖数: 110 | 27 顺藤摸瓜，发现Walmart的production不光在用graphql,还有自己的implementation
https://github.com/walmartlabs/lacinia
【在 d****n 的大作中提到】
: 看了好几个大厂例如脸书例如网飞例如气床都号称自己用了graphql。
: 难道3年河东3年河西RESTFul这套真的要被淘汰了？
|
w********m
发帖数: 1137 | 28 大概是这样的,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 身上也说得通啊
|
c******n
发帖数: 16666 | 29 我觉得是这样的
某天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
发帖数: 16666 | 30 这个文章里面貌似还是无脑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. |
|
|
S*******e
发帖数: 525 | 31 http://www.mitbbs.com/article_t/Biology/32097527.html
Quote： GraphQL实现起来方便呗，大家又比较熟，通用性比较好。我们一些需要实时
更新的query，基本上用这个来实现。 |
d*****n
发帖数: 2132 | 32 营养贴先顶再消化
【在 s*i 的大作中提到】
: 非常同意wflower。真正的云时代正在发生和到来。
: 就API来说，绝大多数应用（除了computational的），都是IO bound的问题。无非是数
: 据库里取点东西或者存点东西，做些格式和结构的转变与整合，然后发送给前端。
: 以前那种每次需要什么就做一个API的年代显然是低效的。因为基本上就是不同的
: resource，后端Code换换数据table，其它的都一样。GraphQL这种东西基本上就是各种
: Query直接让前端来定义，免得翻来覆去的写后端。
: 这个大趋势有很多可以讨论。我斗胆预测走下坡路的几个东西：
: 1. ORM
: 2. Backend development in general
: 3. Containers
|
d*****n
发帖数: 2132 | 33 对后台有几个观点，商榷：
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
|
