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

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

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

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

Ай бұрын

đú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

Ай бұрын

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

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

@anonystick

Ай бұрын

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.

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

@anonystick

Ай бұрын

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.

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

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

Ай бұрын

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

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

Ай бұрын

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

Ай бұрын

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

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?

@anh-beo-code

Ай бұрын

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_

Ай бұрын

Ý 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

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

@anh-beo-code

Ай бұрын

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.

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

@benalpha2297

Ай бұрын

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 😄

Đọc grpc nghe phèn quá a

@anonystick

Ай бұрын

Dạ. Em yếu tiếng Anh á Anh.. xl ạ

@JavaOnly_

Ай бұрын

T vs sếp cũng toàn đọc grpc. Hiểu nhau nói gì là được r bro

@atnguyenlequoc306

Ай бұрын

project áp dụng grpc 3 năm mà e cũng đọc y vậy :))

@loc7500

Ай бұрын

k đọc grpc chứ đoc sao. mấy thằng đặt tên có chữ dev hay thượng đẳng lắm k biết trình độ tới đâu?

@sonhai4539

Ай бұрын

Lại thêm 1 thanh niên hay đi bắt bẻ TA ngta :)))