19 Bình luận
  • ntmj27
    Làm dạng PWA, web phức tạp, cần đổi nhiều, đổi nhanh, không chắc chắn thì làm GraphQL nhanh hơn và nên làm GraphQL.

    Rest nếu có 2 ông làm backend, frontend riêng biệt thì ông frontend cần thêm field data hiển thị (ko phải tạo hay lấy data mới), lại phải contact ông backend, ông backend bổ sung API, deploy, báo ông frontend lấy trường này trường này. Trong khi GraphQL thì ông frontend chỉ cần sửa query để lấy, cần cái gì mới mới cần bảo ông backend. Chủ động hơn.
    • kspm
      @ntmj27 rest bác hơi cứng ngắc hay sao chứ ạ, ông frontend thì cần dữ liệu hay field gì thì mock dữ liệu đó, ông backend lúc nào rảnh thì update sau cũng được mà, miễn là thống nhất 😁
    • ntmj27
      @kspm mình chỉ nói trường hợp chung thôi, mock vào thì nghĩa là tính năng vẫn phải chờ 1 ông khác, đến lúc ông backend làm lại bảo méo đc, khó lắm (kiểu ông front muốn show ra là text, ông back có mỗi id), hai ông lại phải ngồi với nhau xem em lấy hay anh lấy, làm process nó chậm lại. Mấy cái app to chút, nhiều cái chậm tý sẽ dẫn đến chậm nhiều. Hoặc trường hợp cần sửa UI/UX live site nhanh thì cg là vde nếu ông backend bận.

      Mình cũng ko bảo REST ko tốt, GraphQL làm đc thì REST cũng làm đc, nhưng case như mình nói thì làm GraphQL tổng thể cả dự án chạy nhanh hơn nhiều.
  • thinker
    Các chiên gia lập trình @giongto35, @minister cho ý kiến
    • minister
      @thinker món này m ko xài tới nên ko có ý kiến, về cơ bản xài rest thấy vẫn ok, chưa gặp vấn đề j nên ko nghĩ sẽ áp dụng.

      VD mấy cái http methods như DELETE, PUT, PATH ... mình còn ko xài, vẫn GET + POST là thấy quá đủ.

      ở mô hình to và cấu trúc team lớn, cần phân tách để kiểm soát tốt API mới xài tới.
      còn team nhỏ, development speed là quan trọng khi ko có vấn đề j hay ko thấy giải pháp mới mang lại significant improvement thì sẽ ko áp dụng.

      mấy th to đầu h vẫn xài rest ầm ầm thôi.
  • dongnguyen9186
    Pick the right tool for the job!


    No silver bullet


    Lập trình viên có thể viết ra bad code hay good code với bất kỳ tool nào.


    Graphql hay rest thì cũng là tool và nó có điểm yếu và mạnh. Bài trên nêu ra những điều bạn nên xem xét khi chọn graphql. Điều quan trọng là nó thích hợp với dự án đó của bạn. Tác giả cũng nhấn mạnh ý đó trong kết luận bài.
  • matrixvn
    Có bài này cũng được: http://tinyurl.com/y4a96j54
  • svelte
    đang xài graphql như 1 api gateway cho 2 dự án rồi, xài hàng của Apollo
  • PythonGable
    Cái gì cũng cái tốt cái xấu.
    Nói chung là chịu khó viết bài thì vote thôi
  • cuongnguyen208
    Các bác cho em hỏi http://tinyurl.com/y3dzerew có code này up lên hosting kiểu gì cho nó chạy được nhỉ, em cần cái này dùng chứ lên mạng cứ được 3 cái ảnh nó lại giới hạn
    • PythonGable
      @cuongnguyen208 No ghi ro trong readme roi do ban
      Create a project in google console and add vision api to it.
      In this project go to credentials and create Service account keys
      Download Service account keys in .json format
      Give its path in code.
      RUN
    • cuongnguyen208
      @pythongable em chạy hosting php có được ko bác
    • PythonGable
      @cuongnguyen208 Dạ được nhưng mà nó dùng Gcloud thì phải. Nên kiểu gì bác cũng phải run bên Gcloud một backend processing. Còn hosting của bác thì làm như terminal thôi.
    • cuongnguyen208
      @pythongable oh thế thôi em tưởng upfile như wordpress là được
    • unknowns
      @cuongnguyen208 nó có 2 phần, thằng tesseract là offline, cái này là lib open source của google thì phải, cái kia là gcloud vision api, gọi tới api của google. Mà em thấy bác dùng vision api đi, rẻ bèo (1 tháng free cả mấy chục ngàn request), output cực tốt. Dùng tesseract process output cực lắm (em dùng cách đây 5 năm rồi giờ ko biết thế nào). Mà dùng vision api thì gọi trực tiếp lên nó luôn chớ chạy 1 cái deamon làm gì
  • Ufodanger
    Không quan trong to nhỏ hay phức tạp mà là release pace cần giao kết hợp nhịp nhàng BE/FE => Cần cái j đó ở giữa 2 bên constract được => cho cả 2 nhảy vào layer này sửa tè le hột me Lúc này thì cần Graphql

    Một ngày nào đó khi FE lên ngôi là người quyết định kiến trúc của cả system thay vì mấy ông BE đam mê công nghệ thì càng cần GraphQL
    Chứ Rest riêng đoạn mô tả và khai báo đống router đã phát khóc hic
    • svelte
      @ufodanger FE mà quyết định system thì là dân fullstack. Tôi đi làm trực tiếp với team khách hàng bên Úc và Ca, thấy đa phần anh em dev là dân fullstack, nhất là nhánh nodejs.
    • Ufodanger
      @svelte Giờ Agile nhiều, dev phát triển theo hướng T-Shape cũng là hợp lý.
Website liên kết