Dạo gần đây thì mình được tiếp xúc với GraphQL, nói chính xác hơn là thời gian rảnh và mình có tìm hiểu về nó. Trước đó thì mình đã làm nhiều với REST và Soap. Và mình nhận ra rằng GraphQL có những điểm cải tiến và nó khắc phục được một số các nhược điểm của 2 người anh đi trước đó. GraphQL được phát triển bởi Facebook, tuy tại thời điểm mình viết bài viết này, xung quanh mình mọi người vẫn đang dùng REST khá là phổ biến, nhưng mình tin rằng với những thế mạnh của GraphQL thì nó sẽ là tương lai mới của API. Còn bao lâu nữa thì mình không dám nói trước 😀
– Lịch sử ra đời và phát triển của GraphQL.
GraphQL được Facebook phát triển vào năm 2012 và được phát triển công khai vào năm 2015. Vài năm gần đây GraphQL đang phát triển mạnh mẽ và được rất nhiều công ty lớn sử dụng như Spotify, Facebook, GitHub, NYTimes, Netflix, Walmart, và rất nhiều công ty khác. Ở bài viết này thì chúng ta sẽ tìm hiểu về GraphQL và tại sao mình lại nói nó sẽ là tương lai của API.
Thì đầu tiên, GraphQL là gì ?
– GraphQL: A query language for your API, là một cú pháp mô tả cách yêu cầu lấy dữ liệu, và thường được dùng để load data từ một server cho client. GraphQL bao gồm 3 điểm đặc trưng bao gồm cho phép client xác định chính xác những gì dữ liệu họ cần, làm cho việc tổng hợp dữ liệu từ nhiều nguồn dễ dàng hơn và nó sử dụng một type system để mô tả dữ liệu.
Trước khi đi tìm hiểu sâu hơn về GraphQL thì chúng ta lướt qua về REST và Soap để có cái nhìn tổng qua hơn về cả 3.
– SOAP (Simple Object Access Protocol) và REST (Representational State Transfer) là 2 đáp án cho 1 câu hỏi: làm sao để truy cập Web services. Sự lựa chọn ban đầu có thể dễ dàng, nhưng nhiều lúc cũng rất khó khăn với những dự án phức tạp.
SOAP là chuẩn protocol để access các Webservice chuẩn, được phát triển bởi Microsoft, nó được sử dụng rộng rãi một thời gian khá lâu trước và có những lợi ích nhất định.
SOAP định nghĩa 1 phương thức (set of rules) chuẩn để kết nối dựa trên XML để trao đổi thông tin. SOAP sử dụng nhiều phương thức kết nối như HTTP và SMTP.
REST là người đến sau, nó sữa chữa những vấn đề của SOAP và đưa ra cách đơn giản hơn để truy cập Web service. Tuy nhiên, đôi lúc thì SOAP cũng dễ sử dụng hơn, đôi lúc REST cũng có những vấn đề. Cả 2 công nghệ này đều cần cân nhắc trước khi quyết định sử dụng.
REST mô tả 1 tập các công thức mà ở đó dữ liệu có thể được trao đổi thông qua 1 chuẩn interface (ví dụ HTTP). REST không chưa tầng message layer để định nghĩa các hàm và ràng buộc dữ liệu, vì vậy mà truyền dữ liệu bằng REST cũng ít tốn băng thông hơn, thường nhận và gửi bằng JSON. Client có thể access tài nguyên dựa trên URI và nhận được response cùng với state.
Và ngày nay thì REST được ưa chuộng và được thay thế rất nhiều cho SOAP, tuy nhiên thì với sự phát triển của ứng dụng và web. REST càng ngày càng bộc lộ nhiều vấn đề.
1 .A lot of endpoints
Với mỗi API, REST sẽ tạo ra 1 endpoint, Ví dụ bạn thiết kế 1 hệ thống gồm rất nhiều API, mỗi API phục vụ cho 1 mục đích khác nhau. Thì Rest sẽ tạo ra từng đó endpoint.
Vídụ bạn muốn hiển thị một list posts, và ở dưới mỗi post là một list like, bao gồm cả tên người dùng và avatar. Cách giải quyết đơn giản là thay đổi API của ‘posts’ để nó bao gồm một ‘like’ array chứa thông tin về người dùng.
Thế nhưng khi làm như vậy cho các app mobile thì bạn sẽ phát hiện ra tốc độ của chúng chạy quá chậm. Vì thế mà giờ đây bạn sẽ cần tới 2 endpoints, một với likes và một với không likes.
Giờ thì còn có thêm một vấn đề khác xuất hiện: trong khi postsđược lưu trữ trong một MySQL database thì likes lại được lưu tại Redis store! Bạn biết mình phải làm gì trong trường hợp nào không?
Mở rộng vấn đề trên ra với việc Facebook phải quản lí vô số data source và API clients thì cũng là điều dễ hiểu khi REST APIs bị đánh giá là cũ kĩ bởi những hạn chế của nó.
-Giải pháp:
Giải pháp mà Facebook đưa ra đến từ một ý tưởng rất đơn giản: Thay vì có đến hàng tá “endpoint” ngu ngốc, sao lại không dùng chỉ một “endpoint” thông minh với khả năng tiếp thu những Query phức tạp rồi đưa ra output data với loại type tùy theo yêu cầu của client.
Thực tế mà nói, GraphQL như là một layer nằm giữa client và data source, sau khi nhận yêu cầu của client thì nó sẽ kiếm những thông tin cần từ các data source và đưa lại cho client theo format họ muốn. Vẫn chưa hiểu? Thế thì đến lúc dùng ví dụ ẩn dụ rồi đây!
Như bạn thấy đấy, REST model cũ giống y như việc bạn đặt cái bánh Pizza, rồi gọi ship hàng online và kêu bên tiệm giặt ủi đem đồ đến cho bạn. Tất cả diễn ra với 3 cuộc gọi và 3 cửa hàng.
GraphQL mặt khác lại giống như là thư kí riêng của bạn vậy: Sau khi bạn đưa địa chỉ của 3 cửa hàng và nói yêu cầu của bạn thì GraphQL sẽ làm hết mọi chuyện còn lại trong khi bạn chỉ việc chờ chúng được chuyển đến cho mình.
Nói cách khác GraphQL tạo ra một ngôn ngữ chuẩn (standard language) để thực hiện những công việc này.
2.Over-fetching and under-fetching of information
Một điều nữa gây khó chịu cho nhiều nhà phát triển là việc quá tải và thiếu thông tin của REST. Điều này là do các API REST luôn trả về một cấu trúc cố định. Chúng ta có thể nhận được chính xác dữ liệu mà chúng ta muốn trừ khi chúng ta tạo một endpoint cụ thể cho điều đó.
Ví dụ bạn muốn tạo 1 API để lấy ra thông tin người dùng bao gồm firstName, lastName và age . Thì không có cách nào để bạn có thể lấy chính xác 3 thông tin trên mà không phải lấy ra toàn bộ thông tin người dùng. Vì bạn không thể biết trước rằng tại thời điểm này người dùng muốn lấy ra những thông tin gì mà để thiết kế API riêng cho việc này được. Cứ cho rằng bạn biết chắc là tại thời điểm này người dùng chỉ lấy ra 3 thông tin bên trên và bạn tạo 1 API và query DB chỉ để lấy ra 3 thông tin bên trên. Vậy chẳng nhẽ với mỗi lần muốn thêm hay bớt thông tin cần lấy thì bạn lại tạo ra một API cho việc đó ? Điều này là không khả thi, thay vào đó thì REST sẽ lấy ra toàn bộ thông tin người dùng và sẽ trả ra tùy theo thông tin được nhận từ đầu vào. Nghĩa là cho dù bạn chỉ cần lấy 1 thông tin của user là name thôi thì REST cũng sẽ lấy ra toàn bộ thông tin của user đó và trả ra cho bạn mỗi name.
3.Versioning
Lấy một ví dụ đơn giản, công ty yêu cầu bạn phải nâng cấp tính năng cho việc tra cứu thông tin người dùng từ v1 lên v2. Đương nhiên là tính năng cũ v1 vẫn phải được đưa vào sử dụng cho đến khi tính năng mới v2 được ra mắt. Thì với việc thiết kế API theo REST, bạn sẽ phải đánh version cho API như kiểu bên dưới :
https://example.com/api/v1/users/12312
https://example.com/api/v2/users/12312Việc này đôi khi có thể gây nhầm lẫn và sẽ có những khó khăn trong quá trình thiết kế và phát triển. Nhưng với GraphQL thì điều này trở nên không cần thiết.
Vậy tại sao lại nói GraphQL là tương lai của API
Quay trở lại năm 2012, khi mà Facebook vẫn đang sử dụng REST và họ gặp nhiều vấn đề cho việc phát triển của mình. Và đó là nguyên nhân họ tạo ra GraphQL.
Những nhược điểm của REST API:
– Hiệu suất kém
– Có quá nhiều endpont
– Quả tải và thiếu thông tin
– Phải thay đổi version mỗi khi cần thay đổi
– API khó hiểu
Với những vấn đè bên trên, các nhà phát triển Facebook đã tìm hiểu cách khắc phục và tạo ra một thiết kế mới và họ đặt tên cho nó là GraphQL. Về cơ bản thì nó là sự thay thế cho việc sử dụng REST và mang lại nhiều cải tiến.
Với việc sử dụng GraphQL, nó mang lại nhiều ưu điểm, hãy điểm qua một vài thứ mới mẻ của GrapQL.
-Single endpoint
không cần phải tạo ra quá nhiều endpoint cho việc lấy dữ liệu, GrapQL chỉ cần tạo ra duy nhất 1 endpont và sẽ trả ra kết quả như mình mong muốn
-With GraphQL you fetch only the data you need
khắc phục được nhược điểm của REST, GraphQL sẽ chỉ trả về đúng những thứ mà bạn muốn mà không phải tải tất cả các thứ không liên quan. Điều này mang lại tốc độ và hiệu suất cao hơn REST
-GraphQL makes it easy to start building APIs and be consistent
Nhiều người nghĩ là việc sử dụng GraphQL sẽ khó và phức tạp vì nó liên quan đến schema và single endpont. Nhưng nó dễ dàng hơn so với bạn nghĩ, và hiện nay GraphQL đang support hơn 12 ngôn ngữ.
GraphQL là một open source, nghĩa là cộng đồng có thể đóng góp vào việc phát triển và cải thiện nó. Khi Facebook ra mắt GrapQL, nó nhận được rất nhiều sự ủng hộ từ các nhà phát triển. Ngày nay thì GraphQL càng ngày càng phát triển, và mình nghĩ rằng trong 1 tương lai gần nào đó, nó sẽ có thể thay thế cho REST.
Khi mới được nghe và chưa có cơ hội tiếp xúc với GraphQL thì mình nghĩ nó chỉ là 1 kiểu thiết kế API thông thường, nhưng sau quá trình làm quen và tìm hiểu thì mình nhận ra nó thực sự là 1 đột phá trong thiết kế API. GraphQL sẽ là tương lai của thiết kế API, và đó là lý do vì sao rất nhiều công ty lớn đang sử dụng.
Vào tháng 11 năm 2018, GraphQL đã tạo ra một nền tảng GraphQL, hợp tác với Linux. Và Facebook vẫn đang khuyến khích các nhà phát triển để xây dựng thêm tài liệu và công cụ cho GraphQL. Nó sẽ mang lại 1 tương lai mới cho việc thiết kế API, một tương lai đảm bảo và bên vững hơn.
Đương nhiên là nó sẽ không thể lập tức thay thế cho REST được, bởi vì hiện tại có rất nhiều các ứng dụng to đang sử dụng REST cho việc thiết kế API của họ. Và những ứng dụng đó không thể viết lại được trong vòng một đêm hay vài ngày được mà là phải một quá trình lâu dài.
Lời kết
GraphQL có vẻ sẽ khá phức tạp khi bạn mới nhìn vào bởi nó là một kĩ thuật dựa trên nhiều lĩnh vực khác nhau của công nghệ hiện đại. Tuy nhiên, nếu bạn kiên tri học hỏi thì tôi tin rằng bạn sẽ hiểu được nó một cách tường tận.
Vì thế cho dù bạn có dùng nó hay không thì cũng đều đáng bỏ thời gian ra để làm quen với GraphQL. Hiện nay, càng ngày càng có nhiều công ty và framework sử dụng nó, rất có thể GraphQL sẽ trở thành một phần không thể thiếu cho các web developer trong tương lai.
Đào Văn Đô 