gRPC vs Rest API dùng khi nào? Ở đâu? Xem đồng nghiệp giải thích

Рет қаралды 9,933

Күн бұрын

Пікірлер: 35

@benalpha2297 6 ай бұрын

Có lời khuyên là khi nào mà hệ thống có lượng traffic cao và đặc biệt là phát sinh bottleneck ở việc encode/decode request data giữa các services thì lúc đó hẳn tính đến việc xài GRPC hay không? Chứ bình thường thì xài REST vẫn tiện và ngon chán. Nên là cần phải có hệ thống monitoring, tracing đủ tốt để phát hiện ra chỗ nào cần tối ưu. Thấy có nhiều ông lên mạng đọc blog thấy tụi Big Tech như Google, Uber xài GRPC nghe nói nhanh thì cũng phải apply vào hệ thống cho bằng được trong khi chỗ làm chậm hệ thống có khi nằm ở Database hoặc code viết chưa tối ưu, rốt cuộc là chả cải thiện hệ thống lên bao nhiêu mà bắt cả team học thêm cái tech mới cùng với đống convention, best practice,... Chưa kể team DevOps/System cũng phải setup, tìm hiểu, cài thêm plugin để có thể monitor cái tech mới đó.

@thaihungnguyen3893 6 ай бұрын

đúng rồi tuỳ bài toán mà sử dụng các kiến trúc, như chỗ mình làm các anh thiết kiến trúc hệ thống nửa nạc nửa mỡ rất microservices nhưng ko phải microservices, thế nhưng rất ngon và ổn định, kiến trúc đơn giản dễ hiểu phục vụ traffic rất lớn. Đồng ý rằng nhanh hay chậm phụ thuộc rất nhiều ở database là chính và đoạn code nữa.

@hienluongvi3533 6 ай бұрын

ko ai bắt buộc phải dùng gRPC thì nó mới nhanh hay xịn cả gRPC phổ biến trong kiến trúc micro-service mà micro-service được triển khai để độc lập hóa giữa các module (cũng như là chia team ra quản lý luôn), mình thấy micro-service là scale về mặt nhân sự hơn là thay vì performance ( cũng có nhưng mà ko đáng kể ). và đồng ý là dùng kiến trúc monolithic + cân bằng tải + cache là đã nhanh lắm rồi, điển hình như StackOverflow

@aken2802 6 ай бұрын

Mình cũng đang triển khai cả 2 thằng này nếu có đủ nguồn lực và thời gian thì triển khai đúng kiến trúc như anh trình bày thì quá ngon rồi nhưng 1 vài trường hợp thời gian triển khai trên gRPC nó mất nhiều thời gian vì phải triển khai trển cả 2 đầu ( còn rest thì ko cần ) nên trường hợp nếu như ko yêu cầu tốc độ hoặc lượng data gọi qua lại ko quá lớn thì triển khai rest trong local server vẫn xài được bù lại tiết kiệm thời gian code cũng như chi phí nguồn lực coder

@tahitivn 6 ай бұрын

Đúng cái mình mới tìm hiểu gRPC khi join dự án mới, thanks bác

@tcdtist 6 ай бұрын

cảm ơn "anh đồng nghiệp lão làng" đã giải thích 🫡

@minhtrihoang6192 6 ай бұрын

Sếp làm tiếp vụ solid đi ạ, em hóng quá trời

@nghiepdev 3 ай бұрын

Có lễ nên so sánh Restful vs GraphQL đúng bài hơn trong vai trò Client (web, app,...) Server. Còn gRPC thì thiên về kiên trúc micro-service, mặc dù cũng có gRPC Web Client nhưng không đáng kể.

@congdatt 6 ай бұрын

Hóng Tips Go mà lâu quá chưa thấy anh ra vids

@anonystick 6 ай бұрын

Chuẩn bị xong elastic và mysql thì sẽ tiến hành khởi động cấu trúc dự an GO như đã nói hen.

@tonydeveloperdndndn 6 ай бұрын

Video ngắn gọn dễ hiểu quá ạ. Thanks anh. Cơ mà bàn về gRPC, em thấy hiện nay, mặc dù nó đã phát triển, cơ mà hầu hết dự án rất ít khi apply, mặc dù em thấy là làm về banking, finance các kiểu. Cơ mà việc giao tiếp giữa các server với nhau vẫn dùng Client Rest như bình thường. Trong khi đó, dùng gRPC lại cho thấy việc lợi về hiệu năng. Cho em hỏi, anh có ý kiến gì về vấn đề này không ạ. Em cảm ơn.

@anonystick 6 ай бұрын

gRPC an toàn, tốc độ, quan trọng không lộ network

@LongHuỳnh-h1j 3 ай бұрын

Bác đi dạy thì phải thường xuyên cập nhật mấy cái mình dạy chớ nhỉ, mình thấy Postman hỗ trợ gRPC rồi mà nhỉ.

@anonystick 3 ай бұрын

Sao cậu biết tôi không cập nhật???

@LongHuỳnh-h1j 3 ай бұрын

@@anonystick thì bác nói trong video vụ debug grpc khó hơn rest đó, mình search thấy có bài ghi postman support grpc, publish từ 2022 rồi mà

@anonystick 3 ай бұрын

@@LongHuỳnh-h1j Cậu thử nó xem thử? Xem nó thế nào? Xem video 105

@vinvin1869 6 ай бұрын

Em chào anh ạ, em là sinh viên năm 2. Em có thắc mắc là khi các dev fe và be làm xong 1 sản phẩm, thì quá trình bàn giao sản phẩm cho khách hàng sẽ diễn ra như thế nào ạ. Anh có thể làm 1 clip chia sẻ về vấn đề này không ạ. (Em còn khá non nên nếu có hỏi hơi ngu, mong anh và mọi người thông cảm, đừng ném gạch ống em ạ😂😂)

@anonystick 6 ай бұрын

Riêng cái này nếu làm công ty thì có quy chuẩn. Còn cá nhân nhận dự án thì anh có thể chia sẻ cho em được

@vinvin1869 6 ай бұрын

@@anonystick thế thì tuyệt quá anh ❤️

@jan9102 6 ай бұрын

mong anh làm thêm nh về Go

@anonystick 6 ай бұрын

Chuẩn bị xong elastic và mysql thì sẽ tiến hành khởi động cấu trúc dự an GO như đã nói hen.

@loc7500 6 ай бұрын

cho em hỏi tóm lại bài này là: Mình vẫn xây dung Restful để giao tiếp với phía client. Nếu client A gọi đến Http A thì vẫn là Resful. Trong Restful A mình sẽ sử dụng GRPC để gọi qua các server khác để thực thi logic gì đó. xong r trả về client A phải không anh?

@cau-beo-review 6 ай бұрын

bạn hiểu đúng rồi, giao tiếp với phía Client ( các web app dùng React, Angular, Vue ) thì vẫn sử dụng HTTP protocol (restAPI hoặc graphql) và giao tiếp qua lại thông qua định dạng JSON.

@JavaOnly_ 6 ай бұрын

Ý video này là với client sử dụng dữ liệu thì nên để định dạng json cho dễ mở rộng và maintain, còn phía server lấy dữ liệu ở các server khác thì có thể sử dụng rpc để tăng hiệu năng và giảm độ trễ. Mong có thể giúp ích cho b

@quyhuynh8628 6 ай бұрын

Vậy là gRPC được sử dụng chủ yếu trong kiến trúc micro-service đúng ko ạ ? Em có thấy ngoài gRPC còn có tRPC nữa ạ, mong anh giải thích cho e luôn với

@cau-beo-review 6 ай бұрын

tRPC là 1 framework để triển khai HTTP API, ko phải 1 protocol nên ko so sánh nó với gRPC được. bản chất bên dưới tRPC vẫn sử dụng HTTP protocol thôi.

@huyvogia1889 6 ай бұрын

go uptrend hay sao nhiều người tìm hiểu go quá nhỉ 🤔

@benalpha2297 6 ай бұрын

Go hiện tại nó đi vào mainstream luôn rồi chứ trend gì nữa bạn? 😄 Ở VN phần lớn là cty outsource nên job Go nó ít hơn mấy ngôn ngữ khác. Nhưng mấy công ty Product như VNG, Tiki, ZaloPay, Shopee, Viettel,... qua code Go khá nhiều. Lướt tuyển dụng thì thấy cũng kha khá công ty nước ngoài tuyển remote Go. Lương thì thường cao hơn các ngôn ngữ khác nhưng đa số toàn tuyển Senior 😄