GraphQL hơi khó chịu

• GraphQL rất tuyệt, nhưng có vẻ đang bị thổi phồng hơi quá
• Có vẻ các lập trình viên mới vào nghề đến tầm trung cấp xem YouTube rồi dùng GraphQL, nhưng điều này có vẻ không đúng
• Ưu điểm
  • Có thể mô tả dữ liệu mong muốn một cách dễ dàng
  • Tiết kiệm băng thông. Có thể lấy đúng lượng dữ liệu mình muốn trong một lần
  • Dễ tạo tài liệu cho bên tiêu thụ dữ liệu
  • Có thể dùng subscription dễ hơn
  • Có thể gộp các lời gọi API
• Nhược điểm
  • Dùng trong thực tế rất đau khổ. Tùy backend bạn dùng, nếu nó không sinh mã theo ngôn ngữ của bạn thì bạn sẽ phải quản lý 2 hoặc nhiều hệ thống kiểu dữ liệu hơn
  • Không hỗ trợ map/table/dictionary. Đây là điểm rất lớn. Dù không muốn, ở đâu đó rồi bạn cũng sẽ phải dùng {[key: string] : T}
  • Không có cách rõ ràng để quản lý phiên bản API. Cuối cùng bạn sẽ thành ra kiểu MyQueryV1.01, MyQueryV1.02, MyQueryV1.03
• Nếu bạn không xử lý đúng bộ vấn đề/giải pháp mà Facebook đã nhắm tới cho GraphQL thì đừng dùng GraphQL
• Các lập trình viên senior khác có lời khuyên khôn ngoan nào để cứu các lập trình viên mới khỏi sa vào vũng lầy này không?

Bình luận trên HN

• Vấn đề lớn nhất của GraphQL là bạn phải làm thêm việc để chống lại các cuộc tấn công DOS, hoặc ngăn những người muốn tải xuống toàn bộ DB của bạn.
  • Rất dễ tạo ra các truy vấn gây tải quá mức cho hệ thống của bạn.
  • Nếu muốn xem cần phải làm những gì thì cứ nhìn Shopify. Họ áp giới hạn tốc độ theo lượng dữ liệu trả về, đồng thời xử lý cả cursor và pagination. Không giống các ví dụ GraphQL đẹp đẽ trên Internet, schema của họ khổng lồ và xấu xí
• GraphQL là một cách tuyệt vời để giải quyết các vấn đề tổ chức mà các công ty công nghệ lớn gặp phải
  • Ví dụ khi đội bảo trì API và đội yêu cầu thay đổi là hai đội khác nhau
  • Khi tổ chức lớn đến mức nếu vậy thì phải chờ thay đổi rất lâu, GraphQL giúp giảm bớt điều đó
  • Nếu là tổ chức nhỏ thì chẳng phải cứ tự làm thêm phần còn thiếu là được sao?
• Dù có chủ đích hay không, GraphQL giúp các lập trình viên frontend tách khỏi việc phải phụ thuộc vào yêu cầu gửi tới lập trình viên backend và di chuyển nhanh hơn
  • Khi lập trình viên backend tạo mô hình dữ liệu và expose nó qua GraphQL, thì lập trình viên frontend chưa từng gặp người backend đó cũng có thể dùng ngay
  • Có thể thay đổi nội dung truy vấn tại chỗ và lấy đúng thứ mình muốn
  • Giúp mọi người đều di chuyển nhanh hơn
  • Nhưng là một lập trình viên backend, tôi thực sự ghét GraphQL

[bichi]

GraphQL hơi gây bực mình. Không phải là cực kỳ bực mình, chỉ là hơi khó chịu thôi, nhưng vì nó chắc chắn giúp giảm chi phí giao tiếp giữa các thành viên trong nhóm nên thay vào đó dùng khoảng thời gian ấy để giải quyết những phần gây khó chịu sẽ hiệu quả hơn. Và giao diện của nó thì thật sự xấu. Nhưng tôi vẫn khuyến nghị dùng GraphQL. Vì sẽ chẳng ai đồng ý với chuyện dùng tRPC đâu. Phần lớn mọi người còn chưa dùng thử cho ra hồn mà đã từ chối dùng công nghệ chỉ vì phỏng đoán trước, mà để giải quyết chuyện đó thì phải có quyền lực đủ mạnh để ép triển khai. Có thể ép 1~2 công nghệ thì còn được, nhưng nếu cái gì cũng ép thì mất nhiều hơn được nên không thể làm vậy... Thế nên rốt cuộc mức độ dễ thuyết phục nhất vẫn là GraphQL huhu REST chết tiệt này, đúng là một công nghệ thời đồ đá xấu xa tiêu tốn chi phí giao tiếp khủng khiếp huhu

[alucard]

Đây là lần đầu tiên tôi thấy một bài viết trên GeekNews khiến mình phải đăng ký thành viên. Tôi đã để lại trả lời ở phần The bad.

Có lẽ sẽ có ưu và nhược điểm khi nhìn từ phía client/server riêng lẻ, nhưng khi gộp lại để xem thì dù hiểu rằng giá trị lớn nhất của GraphQL là schema của nó lấp đầy lớp trừu tượng còn thiếu giữa server và client, cá nhân tôi vẫn cảm thấy việc nói rằng sẽ cân nhắc REST cho một sản phẩm thông thường nghe hơi như câu chuyện của quá khứ.
The bad

• It is actually a pain to use, depending on the backend you are using you'll have to manage
  two or more type systems if there are no code first generates in your language
  Nói cách khác thì ý là nếu dùng đúng cách thì sẽ tốt chứ gì? Mấy thứ như code generation giờ đâu còn là vấn đề nữa. Tooling đã phát triển đến mức nào rồi cơ mà.
• It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
  some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
  Dù đây cũng là nội dung được nhắc đến trong Production Ready, nhưng nếu tận dụng ưu điểm của Type System thì có vẻ đây không phải phần cần phải băn khoăn nhiều. Thay vì key: string thì chỉ cần chỉ định đúng field là được..
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  Vốn dĩ GraphQL là versionless mà....
  Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
  Nghe giống như nói rằng nếu không giải quyết đúng loại vấn đề mà Facebook định xử lý bằng React thì cũng đừng dùng React vậy.

[bichi]

Xin chào, bạn nói rất đúng. Liệu chúng ta có thể làm quen không? Tôi cần những người cũng nghĩ như vậy. Thật sự quá khó để thuyết phục người khác (thành viên trong nhóm).

[alucard]

Haha, tôi xem bình luận hơi muộn rồi..!! Tôi đang dùng nickname Alucard trong Slack của GraphQL Korea :)

[sixmen]

Tôi đã áp dụng GraphQL từ tương đối sớm, nhưng vào thời điểm đó có rất nhiều phần giải thích thiên về backend. Vì vậy tôi nghĩ có lẽ đã hình thành nhận thức rằng nó sẽ mang lại điều gì đó tốt đẹp cho phía backend.

Sau khi tự mình vật lộn thử đủ thứ, mỗi khi những người vào công ty sau này hoặc những người đi phỏng vấn hỏi, tôi thường giải thích rằng nó vất vả với backend, nhưng lại tốt cho frontend. :)

[bbulbum]

#Nhưng với tư cách là một lập trình viên backend, tôi thật sự ghét GraphQL
Đồng cảm..

[ifmkl]

Đúng là khiến người ta nghĩ ngay đến chuyện dùng đúng chỗ, đúng lúc.

[kbumsik]

Dù có chủ đích hay không, GraphQL giúp các lập trình viên frontend tách rời khỏi những yêu cầu phụ thuộc vào lập trình viên backend để có thể di chuyển nhanh hơn

Đó chính là lý do dùng GraphQL. Ngay trong đặc tả GraphQL cũng ghi rõ nó là dành cho frontend 1
Tôi cũng mới bắt đầu dùng GraphQL ở một startup mới, và có cảm giác số lần tôi phải trao đổi với kỹ sư frontend về API chắc chắn đã giảm đi so với trước đây.

Trước khi dùng GraphQL thật sự, tôi không ngờ lại có những vấn đề khiến phía kỹ sư backend khá đau đầu, nhưng có vẻ nó vẫn tốt hơn nhiều so với việc vò đầu bứt tai để thiết kế REST API cho thật chuẩn.

[hwasurr]

Không có công nghệ nào là hoàn hảo cả! Tôi nghĩ rằng nếu công nghệ đó thực sự cần thiết đến mức xứng đáng để chấp nhận chi phí bỏ ra nhằm khắc phục nhược điểm của nó, hoặc nếu nó giải quyết được một vấn đề khác lớn hơn, thì cũng đáng để cân nhắc áp dụng. Sự phù hợp của công nghệ/công cụ thì cuối cùng lúc nào cũng được quyết định bởi hoàn cảnh của người dùng.

Mặt khác, tôi cũng nghĩ một trong những lý do GraphQL bị chỉ trích là vì nó tạo dựng hình ảnh là “dễ” chăng?

[jjpark78]

Hồi đầu khi Graphql mới xuất hiện và tôi làm dự án POC, không có engine nào hỗ trợ multipart cho ra hồn nên tôi nhớ là đã khá vất vả..

[gjen6s]

Tôi cũng từ trước đến nay cứ thấy người ta dùng GraphQL cho các dự án nhỏ là lại nghĩ đây có phải là over-spec quá không.. xem ra ai cũng nghĩ giống nhau nhỉ

[xguru]

Mình chỉ chuyển phần bình luận ban đầu. Có hơn 400 bình luận nên cũng khó mà đọc hết được.