前端为什么基本上都使用 AJAX 请求，而不使用 RPC？

[zacharyjia]

前两天试了一下 blazor，在 server-side 模式的时候，使用了 SignalR 传输数据。这样可以做到在页面里调用数据的时候，就像调用本地函数一样，而不用自己处理 http 请求，感觉写起来很简单省事儿了。

后面就想到，为什么现在前端基本上都是基于 ajax 做数据刷新，为什么不能使用 rpc 的方式呢？这样的话，一套接口写好，前端后端都可以自动生成对应的函数接口，直接调用多简单？特别是对于很多个人项目来说，不需要手动处理各种 http 请求了，不是更方便吗？实际传输可以基于 ajax 也可以走 websocket，可以做成库帮我们处理，岂不是更省心省力了？

那么这种方式为什么没有推广呢？有什么非常致命的缺点吗？

[zacharyjia]

@mazyi 你没看清在讨论什么啊？不是 blazor 。是说前端请求后端数据的方式。

[otakustay]

@mazyi 这事你怎么和 JSP 联系起来的……

[otakustay]

@zacharyjia 现在也有一些自动生成调用代码的工具，我记得阿里搞了一套，我们这边是在扩展 yapi 的能力让它来生成
工程做大了，这些事肯定提上台面的，在我看来“大部分人不用”就是因为“大部分工程不够大”

[yaphets666]

RPC 是一种描述 AJAX 也是一种描述 都不是具体的技术 在某种程度上甚至可以认为他们是同一种东西

[zacharyjia]

@otakustay 感谢认真的讨论，我也去了解一下。我倒不是做什么大工程，就是兴趣+好奇而已

[sanggao]

本来懒得再喷了！但还是要喷了，我发现 V2 论坛上特别多的幼稚甚至近乎“弱智”的技术问题，虽然是一本正经的发帖，但是技术了解度跟脉脉 [非广告] 简直一个天上一个地下，可能脉脉用户更多的是一线互联网公司的员工。

（ 1 ）首先能做跟要不要做完全是两回事，特别是对于企业级商业项目，根本不是你玩个个人博客站点那样


（ 2 ） rpc 能调用服务端接口这没问题，但是不代表能做项目，服务端同学都知道，暴露给前端的一个 http 接口，可能内部调用了几百个别的服务端接口，难道你前端调用的时候要一个个去组合吗？后端的逻辑你是否十分十分清楚？还有你前端调用成功了前 N 个接口，但是调用失败了其中一个接口，数据一致性、幂等性，回滚，关键节点日志难道你前端做的了吗？？

（ 3 ）前几年前后端还未分离，例如 java jsp 和 php 前后混编，那时候前后连 rpc 调用都不用，哪种方式有这样的性能高？那为什么又前后分离呢？？


（ 4 ）现在的确有前端（安卓 APP ）用 Grpc 调用服务端接口，你问问哪个不是做的想死的心的都有了?? 项目做到最后加一点需求都加不上去，game over

(5) 求求你，不要总是世人皆醉你独醒了，业界的趟过无数坑总结出来的胜过你的凭空想象！

[rioshikelong121]

》 特别是对于很多个人项目来说，不需要手动处理各种 http 请求了，不是更方便吗

存在良好封装的工具函数的情况下，我觉得处理 http 请求没什么太多的开销吧。

我倒是觉得 “前端后端都可以自动生成对应的函数接口，直接 rpc 调用” 也会带来额外的问题。 到时候也会需要引入聚合层 /BFF 这样的中间层的。

[jugelizi]

@zacharyjia 举个栗子吧 可能不是十分恰当
都是骑电瓶车
你觉得外卖小哥和快递员有什么区别吗？
好像送快递也可以去送外卖
送外卖的也可以去送快递
我也觉得都能做 就是这样

[tabris17]

这是个好问题，你为什么不问问神奇的浏览器？

[otakustay]

哦对了，要说前端的 RPC，我觉得 GraphQL 是个差不多的东西了，前端一定会往这个方向发展的

[LostPrayers]

等你多年以后再回来看看自己发了什么东西吧

[richard1122]

这根本就是两个层次的事情，就跟问
人为什么要喝水而不是买锅

[bnm965321]

听起来像是 GraphQL Subscription

不过楼主说的 RPC based on HTTP/2 我是不认同的

[xiaojie668329]

Google 有开源了 grpc-web 的，应该还不是十分成熟。默认基于 http2 好像。

[keelii]

楼主所说的「前端」实际上指代的是客户端，客户端和服务器之间虽然可以实现 RPC 调用，但是在传统的 web 应用方面通常不会这么做。我认为有两点原因：

1. 模式不通用：前端和后端要进行 RPC 通信必须要有一个通用的协议吧，而且是最好要基于 HTTP 的对吧。*传统*的前端不具备 socket 能力，甚至连二进制数据处理的能力都没有（高级浏览器除外），而且你还只能把客户端当成调用方，客户端并不具备提供服务的能力（除非浏览器层面支持额外功能）。
2. 高并发问题：如果不基于 HTTP 实现上也逃不了 socket 吧，那么你就要面临高并发的问题，服务器能建立的 socket 链接数和客户端的链接数量完全不在一个层级上

如果要实现，其实也不难。打开 telegram 的网页版，telegram 实现的点对点消息发送我猜测就是一种客户端和服务器之间的 RPC 调用，本质上讲他还是 http 请求，或者是基于 socket 的某种通信。

[puilu]

没听说过，看来不是个好东西

[syzh]

嗯, dropbox 也在这样做了
https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy

[xmsz]

只能说以前受限于用户环境兼容，包括现在也是
实现对接 grpc 本身很简单，就是基于 http/2 传输
但是基础环境跑不起来，还得考虑降级等操作，那这部分肯定费时费力
那么就需要大厂来搞和实现

所以需要一点时间慢慢来，这就和短视频和网络关系一样，你网络没升级，短视频肯定不行

[chaleaochexist]

@otakustay
感谢大佬, 所有回答数你最靠谱. 收获很多.

歪楼请教另一个问题: 为什么服务和服务内部通信要用 RPC(GRPC)?
GRPC 为什么流行?
对比 HTTP2 有什么优势?
无论跨语言还是效率我觉得都站不住脚.

SDK? 也无法理解.

谢谢.