Размер видео: 1280 X 720853 X 480640 X 360
Показать панель управления
Автовоспроизведение
Автоповтор
感謝講解 一直很不懂gRPC與API到底有啥差別 今天終於懂了
個人不怎喜歡gencode 這種方式 , 如果其中一個自部門clietn有特例要微調 或者 自部門的clietn代碼小版本跌帶版控 都要考量, 太貼的做法會怕.api這種情況喜歡用 運行服務後線上呈現的swagger spec , 各部門要串接則查看線上doc , 如果要依各部門的版本需要釋出對應的gencode版本也是困擾, 幫別人做好意謂就是要幫他們維護? 不如rest一點realease api出來讓其他部門自己串接, 每部門維護自己的項目=>高內聚?跟其他部門不要gencode這種方式 => 低耦合?
謝謝您的解釋～非常的清楚明暸～感謝你
感謝支持
讲的很厉害，感谢分享
讲得太好了，迫不及待想尝试下
感謝支持，昨天本來發佈到 bibi 那邊，結果 AI 判斷我裡面有廣告 XD
gRCP好像5 6年前就有聽過了XD，比較好奇從RESTful和GraphQL換過去會有什麼痛點或是有那些不適合的場景，我是只有用過RESTful API啦，像是RESTful常用到的HTTP header，URL path的功能，CDN cache，還有Circuit Break之類的功能也要考量
gRPC 2015 年出來的，2016 年 8 月正式 release stable 版本。XD 我正打算錄製一篇 RESTful API vs GraphQL vs gRPC 適用場景
我也是觉得 RESTFul 用到好好，还出现什么这种东西？是为了和 Golang 或者和底层语言沟通吗？一般JSON还是不能满足吗？
@@JkeyKonggrpc也能做restful,你們是不是把restful跟http api混為一談了
在我理解 grpc 并不能够替代 restful 以及 mq 这类中间件； 它们之间是并存的关系，选用哪种技术是需要根据实际情况而定的； 在异构语言之间通信我觉得 mq就很好
grpc-gateway 可以將 RESTful JSON API 轉換成 gRPC。至於 mq 又是另一種使用情境了。
RESTful gRPC 是同步通訊, 可以互相替代; 但MQ是非同步通訊, 跟前者情境不同.
@@b123321321 我想表述的观点就是 服务之间通信(包括异构系统) 要看具体实际场景进行选型; 究竟是同步或是异步要看实际需求以及成本等综合因素
你說的第三方 library，通常不會由服務提供者來撰寫吧？如果是說 SDK (Software Development Kit) 還比較能理解。
網路上眾多服務都會提供各種語言的 SDK 包，假如都能透過 gRPC 模式來傳輸，那就不需要大家一起來開發特定語言的 SDK 包。
5:00 因為restAPI 而考慮 app lib version 這有點奇怪。一般來說 http protocol 在各語言中的要求滿低的，不需要到太新版就有支援。比如說 Java 早期板本就可以送 http REQ。
那段我想強調的是，當你在寫 RESTful API 你就會考慮到各個語言的 Http Library 實作以及不同版本的特性，然而如果用 gRPC 則完全不用考慮，都可以透過 protoc 幫忙產生出各種不同語言 (Python, Go ...) 的套件。
希望大大有空可以介紹rabbitmq在這架構下的應用
我自己寫一個 Queue Service 串接各種不同 Queue 服務，像是 NSQ, Nats, Rabbitmq, Redis .. 等，有時間來介紹一下github.com/golang-queue
喔喔，感謝大大分享🙏
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
![[Go 語言] 用 10 分鐘了解 context 使用場景及介紹](/img/1.gif)
感謝講解 一直很不懂gRPC與API到底有啥差別 今天終於懂了
個人不怎喜歡gencode 這種方式 , 如果其中一個自部門clietn有特例要微調 或者 自部門的clietn代碼小版本跌帶版控 都要考量, 太貼的做法會怕.
api這種情況喜歡用 運行服務後線上呈現的swagger spec , 各部門要串接則查看線上doc ,
如果要依各部門的版本需要釋出對應的gencode版本也是困擾, 幫別人做好意謂就是要幫他們維護?
不如rest一點realease api出來讓其他部門自己串接,
每部門維護自己的項目=>高內聚?
跟其他部門不要gencode這種方式 => 低耦合?
謝謝您的解釋～非常的清楚明暸～感謝你
感謝支持
讲的很厉害，感谢分享
感謝支持
讲得太好了，迫不及待想尝试下
感謝支持，昨天本來發佈到 bibi 那邊，結果 AI 判斷我裡面有廣告 XD
gRCP好像5 6年前就有聽過了XD，比較好奇從RESTful和GraphQL換過去會有什麼痛點或是有那些不適合的場景，我是只有用過RESTful API啦，像是RESTful常用到的HTTP header，URL path的功能，CDN cache，還有Circuit Break之類的功能也要考量
gRPC 2015 年出來的，2016 年 8 月正式 release stable 版本。XD 我正打算錄製一篇 RESTful API vs GraphQL vs gRPC 適用場景
我也是觉得 RESTFul 用到好好，还出现什么这种东西？是为了和 Golang 或者和底层语言沟通吗？一般JSON还是不能满足吗？
@@JkeyKonggrpc也能做restful,你們是不是把restful跟http api混為一談了
在我理解 grpc 并不能够替代 restful 以及 mq 这类中间件； 它们之间是并存的关系，选用哪种技术是需要根据实际情况而定的； 在异构语言之间通信我觉得 mq就很好
grpc-gateway 可以將 RESTful JSON API 轉換成 gRPC。至於 mq 又是另一種使用情境了。
RESTful gRPC 是同步通訊, 可以互相替代; 但MQ是非同步通訊, 跟前者情境不同.
@@b123321321 我想表述的观点就是 服务之间通信(包括异构系统) 要看具体实际场景进行选型; 究竟是同步或是异步要看实际需求以及成本等综合因素
你說的第三方 library，通常不會由服務提供者來撰寫吧？如果是說 SDK (Software Development Kit) 還比較能理解。
網路上眾多服務都會提供各種語言的 SDK 包，假如都能透過 gRPC 模式來傳輸，那就不需要大家一起來開發特定語言的 SDK 包。
5:00 因為restAPI 而考慮 app lib version 這有點奇怪。一般來說 http protocol 在各語言中的要求滿低的，不需要到太新版就有支援。比如說 Java 早期板本就可以送 http REQ。
那段我想強調的是，當你在寫 RESTful API 你就會考慮到各個語言的 Http Library 實作以及不同版本的特性，然而如果用 gRPC 則完全不用考慮，都可以透過 protoc 幫忙產生出各種不同語言 (Python, Go ...) 的套件。
希望大大有空可以介紹rabbitmq在這架構下的應用
我自己寫一個 Queue Service 串接各種不同 Queue 服務，像是 NSQ, Nats, Rabbitmq, Redis .. 等，有時間來介紹一下
github.com/golang-queue
喔喔，感謝大大分享🙏