Chào anh em đồng nghiệp trong năm 2018, ở Balan hiện giờ đã vào đông, tuy kì nghĩ mùa đông của chúng tôi rất ngắn, nhưng tại Treehouse chúng tôi vẫn đang theo sát tôc độ phát triển của các web development, chúng tôi sẽ cố gắng hết sức để phân loại và sắp xếp các xu hướng đã qua từ những công nghệ mà về cơ bản sẽ thay đổi những gì chúng tôi đã dạy cho sinh viên của mình. Gần đây tôi đã tìm thấy một đầu mối cho tương lai dưới dạng một câu trích dẫn tư Sacha Greif, một trong những nhà đồng xuất bản 2017 State Of JavaScript Survey:
“…Tôi muốn nói nên hãy chú ý đến GraphQL. Đó là công nghệ đem lại lãi suất rất lớn nhưng thực tế ngược lại thì số lượng người dùng hiện tại lại rất thấp, điều này có thể cho thấy một phần đáng kể của hệ thống tiếp cận GraphQL trong năm 2018…”
Nếu phải đoán (chúng tôi phải làm điều này tại Treehouse) tôi phải nói rằng anh ta đúng. Năm 2018, GraphQL đã sẵn sàng cho một sự hưởng ứng to lớn từ cộng đồng web development, các junior developers sẽ học cách làm việc với nó và nó sẽ trở thành một yêu cầu mới trong nghành công nghệ. Nhưng điều gì khiến cho GraphQL bị đặt qua một bên trong ngày hôm nay, dù thế nào đi nữa mọi thứ cuối cùng vẫn sẽ là GraphQL:
Điều dễ nhất để nhận ra rằng loại API duy nhất đã từng là REST API. Nếu bạn đã học về development web trong 5 năm, REST API có lẽ là loại API duy nhất bạn đã sử dụng. Một số công nghệ và framework có hướng dẫn và quy tắc chung khá nhiều, lần đâu tiên một ý tưởng về REST API được đề xuất bởi Roy Fielding trong năm 2000 như một cách để giúp việc truy cập và sử dụng API dễ hơn so với các định dạng tiêu chuẩn khác trong cùng thời điểm. Những hướng dẫn và nguyên tắc đơn giản này có thể dễ dàng tích hợp với các tài nguyên bên ngoài vào các ứng dụng web khác và REST API đã sớm được chấp nhận như là Amazon Web Services, Flickr và EBay, đã trở thành một phần không thể thiếu của Internet.
Nhưng REST API luôn tồn tại một số vấn đề. Trong REST API, một URL được dành riêng cho một tài nguyên cụ thể, dữ liệu được trả về từ tài nguyên sau khi được sửa lỗi. Nó hoạt động tốt trong một số vấn đề được dự đoán trước, nhưng khi vấn đề chúng tôi yêu cầu API sử lý trở nên lớn hơn và khó dự đoán hơn, số lượng yêu cầu chúng tôi phải thực hiện cho một số kết thúc khác nhau trong REST API để có thể tăng tốc độ của các ứng dụng web.
Bắt đầu với GraphQL như một giải pháp, GraphQL là một ngôn ngữ truy vấn có cấu trúc, được nhập vào đầu trang của một API cho phép các nhà phát triển truyền đạt thêm thông tin về dữ liệu họ gửi và nhận. Điều đó nghĩa là gì? Xem sét ví dụ API về nhân khẩu của một thành phố. Giả sử chúng ta muốn tạo một ứng dụng với API này cung cấp tổng số người sở hữu thú cưng trong một khu phố nhất định.
“ GraphQL là một ngôn ngữ truy vấn có cấu trúc, được nhập vào đầu trang của một API cho phép các nhà phát triển truyền đạt thêm thông tin và dữ liệu của họ ’’
Trong REST API, chúng ta có thể bắt đầu tạo lập những câu hỏi từ điểm kết thúc của thành phố cho một danh sách của khối thành phố. Chúng ta sẽ chờ thông tin trả lại, và sau đó lọc các thông tin theo khu vực phù hợp để đạt được kết quả gần như mong muốn của chúng ta. Khi chúng ta đã có được thông tin khối nhà mong đợi, chúng ta có thể thiết lập yêu cầu đến điểm kết thúc của các khối nhà đó, một yêu cầu cho môt khối nhà, để nhận được thông tin của các ngôi nhà trong khối thành phố đó. Có thể điểm kết thúc của các khối thành phố được thiết kế để giới hạn lại thông tin trên con người ở trong những ngôi nhà ấy, tuy nhiên để tìm ra liệu là mỗi người trog số đó có nuôi thú cưng, chúng ta lạ phải đặt ra hàng tá cá câu hỏi khác đến những người khác để biết thêm chi tiết. Điều này khiến các câu hỏi cứ chất chồng lên nhau, ngay cả khi nếu chúng ta đẩy nhanh tốc độ của quy trình bằng việc chạy các câu hỏi song song.
Nhưng với GraphQL, chúng tôi đang tiến hành tạo ra những câu hỏi đến các điểm kết thúc của thành phố và với những yêu cầu này, chúng tôi cũng sẽ gửi một câu hỏi để điểm kết thúc biết chúng tôi chỉ muốn các khối trong các vùng cụ thể. Chúng tôi chỉ cần biết 1 danh sách của các nhà cho mỗi khối, vì vậy chúng tôi cũng sẽ đặt câu hỏi cụ thể. Sau đó chúng tôi sẽ tạo một yêu cầu đến điểm cuối các ngôi nhà với yêu cầu khác nhằm yêu cầu danh sách dân cư trong mỗi nhà, và cụ thể là chúng tôi muốn biết liệu là mỗi người có đang sở hữa một con thú cưng hay không?
Nếu như may mắn, API có thể được thiết kế để có điểm kết thúc thành phố và thêm vào đó là các thông tin của các ngôi nhà, con người và thú cưng có thể được bao gồm trong câu hỏi. Bằng việc sử dụng ngôn ngữ truy vấn của GraphQL, chúng ta giảm thiểu được hàng chục các câu hỏi xuống còn 2 đến 7 câu. Đó là một hiệu xuất lớn trong hệ thống của chúng tôi !
Khi làm việc với GraphQL bạn sẽ thấy được các lợi ích từ hệ thống này, như khả năng phát hiện hình dạng của dữ liệu chúng ta nhận và nhận được nhiều thông tin chi tiết về dữ liệu cũng như các lỗi được gửi từ API thong qua 1 loại hệ thống đơn giản của GraphQL.
GraphQL thậm chí còn có khả năng cung cấp cho chúng tôi một vài mã code cơ bản trong khi chúng tôi viết request.
Để càng ngày càng nhiều công ty như Github, Facebook, Amazon, và Twitter triển khai các điểm cuối GraphQL vào các API công cộng của họ và ngày càng nhiều nhà phát triển trở nên quan tâm đến việc học loại công nghệ này, GraphQL sẵn sàng trở nên cần thiết cho nhà phát triển cơ sở để học như các yêu cầu của REST API đã được triển khai trong thập kỷ qua.
Tác giả: Đặng Thanh Hiền
