🚵Client & Server
Client và Server là hai thành phần quan trọng, hỗ trợ cho quá trình hoạt động của website luôn thuận tiện và mượt mà hơn.
Client
Client hay còn được hiểu là máy trạm hay máy khách, thông qua đó gửi những yêu cầu của mình đến hệ thống Server.
Client đóng vai trò như nơi trung gian, hỗ trợ cho quá trình giao tiếp giữa người dùng, Server cũng nhưumôi trường bên ngoài ngay trạm làm việc của nó.
Ngoài ra, Client còn có nhiệm vụ tiếp nhận các yêu cầu phía người dùng, sau đó thiết lập các Query String để gửi trực tiếp đến Server. Khi Server phản hồi lại kết quả, Client sẽ truy xuất và hiển thị chúng đến người dùng cuối.
Server
Server hay còn được biết đến là máy chủ - một hệ thống bao gồm cả phần cứng và phần mềm máy tính, giúp đáp ứng tốt mọi yêu cầu trên một mạng máy tính.
Vai trò chính của Server là lưu trữ, xử lý các dữ liệu cho một mạng máy tính hoặc thậm chí là trong môi trường Internet.
Server hoạt động chủ yếu trên một máy tính chuyên dụng hay nhiều máy tính nối mạng có khả năng lưu trữ lượng dữ liệu khổng lồ. Mọi hoạt động diễn ra trên Internet muốn vận hành mượt mà đều phải thông qua hệ thống Server.
Server được hình thành dựa trên các thuật toán Quere và Black - box. Loại thuật toán này hoạt động với nguyên tắc khi có dữ liệu đầu vào sẽ ngay lập tức xử lý và xuất kết quả trả về cho User.
Hiện nay, Server hoạt động với các loại sau:
File Servers.
Mail Servers.
Database Servers.
Web Servers.
Game Servers.
Print Servers.
Application Servers.
Phân biệt
Client và Server được biết đến là hai yếu tố vô cùng quan trọng trong quá trình vận hành của một website, hỗ trợ mọi hoạt động diễn ra trên mạng Internet trở nên thiết thực hơn.
Điểm khác biệt cơ bản giữa Client và Server chính là môi trường hoạt động của chúng. Client hoạt động chủ yếu ở phía người dùng, còn Server lại phục vụ cho phía máy chủ.
Trong quá trình vận hành, Client và Server còn khác nhau về mặt hiệu suất hoạt động. Client được tối ưu khi các ứng dụng có thời gian khởi động nhanh chóng, còn Server được xem là tối ưu cho ứng dụng khi và chỉ khi nó được chú trọng đến yếu tố nhấn mạnh nhiều hơn là về hiệu suất.
Một điểm khác biệt tiếp theo giữa Client và Server, đó chính là Server sẽ chứa toàn bộ những thông tin và nội dung cần thiết cho quá trình vận hành của website, còn Client lại hỗ trợ chủ yếu cho quá trình tìm kiếm của người dùng. Nhờ có Server mà mọi nhu cầu sử dụng phía Client luôn được đáp ứng một cách nhanh chóng và chính xác.
Thêm vào đó, Server có thể hỗ trợ cho quá trình đăng nhập của nhiều người dùng, còn Client chỉ hỗ trợ được cho một User đăng nhập vào.
Có thể nói, giữa Client và Server luôn tồn tại mối quan hệ tương hỗ, giúp cơ chế hoạt động của các website diễn ra bình thường và trơn tru hơn, đáp ứng tốt các nhu cầu của con người trong việc tìm kiếm và nghiên cứu thông tin trên Internet.
Đánh giá ưu nhược điểm của mô hình Client Server
Cùng điểm qua ưu, nhược điểm của Client Server để sử dụng một cách chính xác nhất và phù hợp với nhu cầu của bản thân.
Ưu điểm
Tập trung
Ưu điểm đầu tiên của mô hình Client Server kiểu mạng khách chủ đó chính là khả năng kiểm soát tập trung (Centralization) đã được tích hợp sẵn. Theo như mô hình này thì tất cả mọi thông tin cần thiết đều sẽ được đặt ở một vị trí duy nhất. Đây là một ưu điểm vô cùng hữu ích được những người quản trị viên mạng yêu thích bởi vì họ có thể toàn quyền quản lý cũng như điều hành mọi việc.
Tính năng này giúp cho mọi sự cố trong mạng đều sẽ được giải quyết ở cùng một nơi thống nhất. Đồng thời, việc cập nhật cơ sở tài nguyên, dữ liệu cũng sẽ dễ dàng hơn rất nhiều.
Bảo mật
Trong mạng Client Server, tất cả các dữ liệu đều sẽ được bảo vệ một cách tối đa nhờ vào hệ thống kiến trúc tập trung của mạng. Thông qua đó, nó sẽ giúp người dùng kiểm soát truy cập để chỉ có những ai được cấp quyền truy cập thì mới được thực hiện các thao tác cần thiết.
Muốn làm như vậy, chúng ta cần phải áp đặt thông tin đăng nhập cũng như Username hay Password. Bên cạnh đó, nếu dữ liệu của chúng ta bị mất thì các file sẽ được khôi phục một cách vô cùng dễ dàng chỉ từ một bản sao lưu duy nhất mà thôi.
Khả năng mở rộng
Mô hình mạng kết nối Client Server có khả năng mở rộng vô cùng tốt. Chỉ cần người dùng cần sử dụng bất cứ lúc nào thì họ cũng có thể tăng được số lượng tài nguyên của mình. Ví dụ như số Client hoặc Server. Nhờ đó mà chúng ta có thể tăng kích thước của Server một cách dễ dàng mà không bị gián đoạn nhiều.
Khả năng truy cập
Hoàn toàn không hề có sự phân biệt giữa các vị trí hay nền tảng với nhau. Tất cả mọi Client đều có khả năng đăng nhập được vào hệ thống mạng máy tính. Điều này sẽ giúp cho tất cả các nhân viên đều có thể truy cập thông tin của công ty một cách dễ dàng mà không cần phải dùng một terminal mode hoặc một bộ xử lý nào khác.
Nhược điểm
Tắc nghẽn lưu lượng
Nói về nhược điểm lớn nhất của mô hình mạng Client Server đó chính là tắc nghẽn lưu lượng. Trong trường hợp có quá nhiều Client tạo request từ cùng một Server thì nó có thể sẽ làm cho kết nối chậm hơn. Trong trường hợp xấu nhất còn có thể xuất hiện hiện tượng crash. Khi một server bị quá tải thì sẽ tạo ra nhiều vấn đề khi truy cập thông tin.
Độ bền
Client Server là mạng tập trung chính vì thế, khi Server chính xảy ra sự cố hoặc bị nhiễu thì cũng đồng nghĩa với việc toàn bộ hệ thống mạng sẽ bị gián đoạn. Như vậy, bạn cần chú ý đó là mạng thiếu tính ổn định và độ bền. Bạn cần chú ý khi thực hiện.
Chi phí
Chi phí được sử dụng để thiết lập và bảo trì Server trong Client Server thường sẽ khá cao. Lý do là vì các hệ thống mạng có sức mạnh rất lớn cũng đồng nghĩa với việc giá để chi cho việc này là rất đắt. Chính vì vậy, không phải ai cũng có khả năng chỉ trả và sử dụng.
Bảo trì
Khi các Server thực hiện triển khai để làm việc thì nó cũng sẽ hoạt động một cách không ngừng nghỉ. Điều này đồng nghĩa với việc chúng ta cần phải quan tâm đến việc bảo trì hệ thống đúng mức. Khi xảy ra bất cứ vấn đề gì cũng cần phải giải quyết ngay lập tức. Vậy nên, cần phải có một nhà quản lý mạng chuyên biệt để tiến hành duy trì hoạt động của Server khi chúng được đưa vào và sử dụng.
Tài nguyên
Một điều mà chúng ta rất cần phải lưu ý đó chính là không phải tất cả tài nguyên hiện có trên Server đều sử dụng được. Ví dụ một cách đơn giản đó chính là chúng ta không thể in trực tiếp được tài liệu từ trên web cũng như tiến hành chỉnh sửa bất kỳ một thông tin nào trên ổ cứng của Client cả.
Ví dụ về mô hình Client Server
Để giúp bạn có thể hiểu rõ hơn về Client Server sau đây sẽ là ví dụ về mô hình client-server.
Web server: Người dùng tiến hành nhập địa chỉ website thông qua máy tính. Client sẽ gửi yêu cầu đến web server. Sau đó, web Server sẽ gửi lại toàn bộ nội dung của website về cho Client ban đầu.
Mail server: Người dùng soạn mail gửi đi. Client gửi đến mail Server. Sau khi nhận được tín hiệu, Mail Server sẽ thực hiện tiếp nhận, lưu trữ cũng như tìm kiếm địa chỉ email được gửi đến và tiến hành gửi mail đi.
File server: Client chia sẻ thông tin đến File server. Sau đây, File server thực hiện lưu trữ cũng như truyền tập tin đi. Người dùng upload hoặc download các tập tin lên trên server qua giao thức FTP hay web browser
So sánh giữa Client Server, P2P chi tiết
P2P và Client server là 2 mô hình mạng phổ biến hiện nay. Cùng so sánh một chút để xem hệ thống nào có nhiều ưu điểm nổi bật hơn nhé.
Điểm giống nhau
Điểm chung của 2 mô hình này đó chính là có một client gửi request đến server sau đó server sẽ gửi trả thông tin về cho client.
Điểm khác nhau
Nội dung | Client server | P2P |
Vai trò, phân quyền | Phân chia vai trò rõ ràng giữa server và client | Trong cùng một mạng, tất cả máy đều ngang hàng với nhau |
Quản trị mạng | Cần có người quản trị mạng | Không cần có người quản trị mạng |
Phần cứng, phần mềm | Cần máy chủ, phần cứng và hệ điều hành | Cần khá ít phần cứng, có thể không cần đến hệ điều hành và máy chủ |
Chi phí cài đặt | Cao | Thấp |
Nguyên lý hoạt động của Client/server network
Việc giao tiếp giữa Client với Server phải dựa trên các giao thức chuẩn. Các giao thức chuẩn được sử dụng phổ biến nhất hiện nay là : giao thức TCP/IP, giao thức SNA của IBM, OSI, ISDN, X.25 hay giao thức LAN-to-LAN NetBIOS.
Được biết đến là giải pháp phần mềm cho việc khắc phục tình trạng quá tải trên mạng, Client/server network còn vượt qua những ngăn cách về sự khác nhau trong cấu trúc vật lý cũng như hệ điều hành của các hệ thống máy tính khác nhau trên mạng.
Dưới đây là cách mà mạng Client/Server hoạt động:
Yêu cầu từ Client: Máy tính Client gửi yêu cầu đến máy tính Server thông qua mạng. Yêu cầu này có thể là truy cập dữ liệu, thực hiện một chức năng cụ thể hoặc yêu cầu một dịch vụ nào đó.
Xử lý yêu cầu từ Server: Máy tính Server nhận yêu cầu từ máy tính khách hàng. Server sẽ xác định loại yêu cầu và tác vụ cần thực hiện để đáp ứng yêu cầu đó.
Xử lý dữ liệu hoặc chức năng: Server thực hiện xử lý dữ liệu hoặc thực hiện chức năng cụ thể được yêu cầu từ Client. Điều này có thể bao gồm truy vấn cơ sở dữ liệu, tính toán phức tạp, xử lý hình ảnh, và nhiều tác vụ khác tùy thuộc vào mục đích của ứng dụng hoặc dịch vụ.
Phản hồi từ Server: Sau khi xử lý yêu cầu, Server tạo ra kết quả hoặc dữ liệu được yêu cầu. Server sau đó gửi phản hồi chứa kết quả này trở lại máy tính khách hàng thông qua mạng.
Xử lý phản hồi từ máy tính khách hàng: Máy tính Client nhận phản hồi từ máy tính máy chủ và xử lý kết quả hoặc dữ liệu được cung cấp. Điều này có thể là hiển thị thông tin trên giao diện người dùng, lưu trữ dữ liệu trên máy tính Client hoặc thực hiện các hành động khác dựa trên kết quả nhận được.
Các phương pháp giao tiếp giữa Server và Client
Bản thân giao thức TCP là song công (khả năng truyền và nhận dữ liệu cùng một lúc), nhưng HTTP1.1 được sử dụng phổ biến nhất đối với người dùng , mặc dù là giao thức dựa trên TCP, là bán song công, không thân thiện lắm với hầu hết các tình huống yêu cầu máy chủ chủ động đẩy dữ liệu đến máy khách, vì vậy chúng ta cần sử dụng giao thức websocket hỗ trợ song công đầy đủ.
Trong HTTP1.1. Miễn là máy khách không hỏi, máy chủ không trả lời. Dựa trên tính năng này, đối với các tình huống đơn giản như trang đăng nhập, bạn có thể sử dụng tính năng thăm dò theo thời gian hoặc bỏ phiếu dài để đạt được hiệu quả của việc đẩy máy chủ comet.
Đối với các tình huống phức tạp đòi hỏi sự tương tác thường xuyên giữa máy khách và máy chủ, chẳng hạn như trò chơi trên web, giao thức websocket có thể được xem xét. Websocket hầu như không liên quan gì đến socket, nhưng được đặt tên tương tự. Bởi vì mỗi trình duyệt hỗ trợ giao thức HTTP, websocket trước tiên sẽ sử dụng giao thức HTTP cộng với một số tiêu đề đặc biệt để thực hiện thao tác nâng cấp bắt tay. Sau khi nâng cấp thành công, nó không liên quan gì đến HTTP, sau đó sử dụng định dạng dữ liệu websocket để gửi và nhận dữ liệu.
Có rất nhiều loại API, nhưng trong giao tiếp trên nền tảng web, có hai kiểu API quan trọng: Web Service APIs (SOAP, JSON-RPC, XML-RPC, REST) và WebSocket APIs. Bài viết này mong muốn làm rõ hơn nhu cầu sử dụng của hai đối tượng này.
Nguồn gốc của các kiểu API này liên quan đến các protocol và architectural style trên nền tảng network, tỉ dụ như: HTTP, REST, HTTP Polling, HTTP Streaming, SSE (Server Send Events/EventSource), HTTP/2 Server Push, WebSocket, Webhook.
HTTP
HTTP là giao thức kết nối cơ bản của World Wide Web. HTTP vận hành theo dạng request-response protocol trong mô hình client-server. HTTP/1.1 là phiên bản phổ biến nhất của HTTP được dùng trong web browser và server. So với các phiên bản trước, phiên bản này cài đặt những tối ưu hiệu suất quan trọng cũng như chức năng mới, ví dụ như: persistent và pipelined connections, chunked transfers (phân đoạn truyền tải), new header fields trong request/response body … Trong những cải tiến này, có 2 header information rất đáng lưu ý bởi hầu hết các cải tiến hiện đại đối với HTTP đều dựa trên 2 header này.
Keep-Alive header để thiết lập các policy cho long-live communication giữa các host (timeout period và maximum request count xử lý các connection).
Upgrade header để chuyển connection lên một enhanced protocol mode như là HTTP/2.0 (h2, h2c) hoặc WebSocket
REST
REST là một Architectual Style, REST ở thời điểm hiện tại là cách phổ biến nhất để cấu trúc Web APIs. REST là một pure architectual style dựa trên một số nguyên tắc (principle). Các APIs tuân theo các REST Principles được gọi là RESTful APIs. Nói chung, RESTful APIs dùng HTTP làm giao thức truyền. Cho những trường hợp như vậy, các truy suất dữ liệu sẽ dùng các GET method request. PUT, POST, và DELETE request dùng tương ứng để update, create, và delete dữ liệu. (Không sử dụng GET request để update dữ liệu).
HTTP Polling
Trong HTTP Polling, client thực hiện poll đến server để request thông tin mới. Có một số cơ chế poll sẽ được mô tả bên dưới. Polling được sử dụng bởi phần lớn các ứng dụng ngày này, và thực tiễn chúng đi kèm với RESTful. Thực tế, HTTP Short Polling rất hiếm khi được sử dụng, còn HTTP Long Polling và Periodic Polling luôn luôn được lựa chọn.
HTTP Short Polling:
Một cách tiếp cận đơn giản. Một lượng lớn request được xử lý khi chúng đi đến server, tạo lượng traffic lớn cũng như sử dụng nhiều resource, tuy nhiên sẽ được giải phóng ngay khi responde được gửi trở lại. Bởi vì mỗi connection chỉ mở trong thời gian ngắn, nên nhiều connnection có thể timemultiplexed (share). 00:00:00 C-> Is the cake ready? 00:00:01 S-> No, wait. 00:00:01 C-> Is the cake ready? 00:00:02 S-> No, wait. 00:00:02 C-> Is the cake ready? 00:00:03 S-> Yeah. Have some lad. 00:00:03 C-> Is the other cake ready?
HTTP Long Polling:
Khi request đến server, client đang đợi response phản hồi. Server giữ (hold) request đó open đến khi dữ liệu mới sẵn sàng. Bạn được notify ngay không bị delay khi server event xảy ra. Các này sẽ phức tạp và tốn server resource hơn.
12:00 00:00:00 C-> Is the cake ready?
12:00 00:00:03 S-> Yeah. Have some lad.
12:00 00:00:03 C-> Is the other cake ready?
HTTP Periodic Polling:
Cách thức này sẽ định nghĩa trước một time gap giữa 2 request liên tiếp. Đây là một phiên bản cải tiến của polling. Bạn có thể giảm việc sử dụng server bằng việc tăng time gap. Nhưng nếu bạn cần được notify mà không bị delay khi server event xảy ra thì cách thức này không phải là lựa chọn tốt
00:00:00 C-> Is the cake ready? 00:00:01 S-> No, wait. 00:00:03 C-> Is the cake ready? 00:00:04 S-> Yeah. Have some lad. 00:00:06 C-> Is the other cake ready?
HTTP Streaming
Client tạo một HTTP request, và server truyền dữ liệu dần (stream) vào một response với độ dài chưa xác định (nó giống polling infinitely). HTTP streaming cho hiệu năng tốt, dễ sử dụng và có thể là một thay thế cho WebSocket.
Nhược điểm: Các đối tượng trung gian có thể làm gián đoạn kết nối (ví dụ: timeout, phục vụ request khác theo cơ chế round-robin). Trong những trường hợp đó, không thể đảm bảo tính chất realtime hoàn toàn.
00:00:00 CLIENT-> I need cakes 00:00:01 SERVER-> Wait for a moment. 00:00:01 SERVER-> Cake-1 is in process. 00:00:02 SERVER-> Have cake-1. 00:00:02 SERVER-> Wait for cake-2. 00:00:03 SERVER-> Cake-2 is in process. 00:00:03 SERVER-> You must be enjoying cake-1. 00:00:04 SERVER-> Have cake-2. 00:00:04 SERVER-> Wait for cake-3. 00:00:05 CLIENT-> Enough, I'm full.
SSE (Server Sen Events/EventSource)
SSE connection chỉ có thể push data đến browser (browser chỉ có thể subscribe để nhận dữ liệu update từ server, chứ không thể gửi bất kỳ dữ liệu nào đến server). 00:00:00 CLIENT-> I need cakes 00:00:02 SERVER-> Have cake-1. 00:00:04 SERVER-> Have cake-2. 00:00:05 CLIENT-> Enough, I'm full. Các ứng dụng thực tiễn: Twitter updates, Stock quotes, Notifications đến browser. Nhược điểm: - Một số browser không support SSE. - Số lượng open connection tối đa chỉ từ 6–8 trên HTTP/1.1 (dựa trên từng phiên bản browser). Nếu bạn dùng HTTP/2, sẽ không còn là vấn đề nữa vì một TCP connection là đủ cho toàn bộ các request. (multiplexed support in HTTP/2)
HTTP/2 Server Push
Một cơ chế chủ động để server có thể chủ động đẩy các asset đến client cache trước. Ví dụ: stylesheet, scripts, media… Các ứng dụng: Social media feeds, single page app (SPA)
Theo IETF, một “stream” là một chuỗi các frame độc lập, bidirection được exchange giữa client và server bên trong một HTTP/2 connection. Một trong những đặc trưng chính là một HTTP/2 connection đơn có thể chứa nhiều concurrently open stream, có thể gửi xen kẽ các frame của nhiều stream. Nhược điểm: - Các trung gian (proxy, router, host) có thể chọn không push information đến client như mong muốn của origin server. - Các connnection không được duy trì mở vô thời hạn. Một kết nối có thể bị đóng bất kỳ lúc nào ngay cả khi việc thực hiện push nội dung đang diễn ra. Sau khi mở lại kết nối bị đóng, thì kết nối này không thể tiếp tục tại điểm nó bị đóng trước đó. - Một số browser/trung gian không hỗ trợ Server Push.
WebSocket
WebSocket cho phép cả server và client thực hiện push message tại bất kỳ thời điểm nào và không liên quan đến những request trước đó. Một ưu điểm đáng lưu ý khi sử dụng WebSocket là: hầu hết mọi browser đều hỗ trợ WebSocket. WebSocket giải quyết một số vấn đề của HTTP:
Bi-direction protocol: client/server đều có thể gửi message cho đối phương. Trong HTTP, request luôn luôn được khởi tạo bởi client và server trả về response — điều này có nghĩa HTTP là một uni-directional protocol.
Full-duplex communication: client và server có thể nói chuyện với nhau một cách độc lập tại cùng thời điểm.
Single TCP connection: Sau thời điểm được upgrade HTTP connection, thì client và server kết nối với nhau trên TCP connection chia sẻ đó trong suốt vòng đời của một WebSocket connection.
00:00:00 CLIENT-> I need cakes 00:00:01 SERVER-> Wait for a moment. 00:00:01 CLIENT-> Okay, cool. 00:00:02 SERVER-> Have cake-1. 00:00:02 SERVER-> Wait for cake-2. 00:00:03 CLIENT-> What is this flavor? 00:00:03 SERVER-> Don't you like it? 00:00:04 SERVER-> Have cake-2. 00:00:04 CLIENT-> I like it. 00:00:05 CLIENT-> But this is enough.
Websocket connection (Image from PubNub.com) Các ứng dụng: IM/Chat apps, Games, Admin frontends. Mặc dù WebSocket được support bởi hầu hết các browser, tuy nhiên có một số ngoại lệ đối với một số trung gian
Unexpected behavior: nếu các WebSocket connection của bạn đi qua proxy/firewall, bạn có thể thấy các kết nối đều thất bại. Luôn luôn phải dùng Secured WebSocket (WSS) để giảm phần lớn những kết nối thất bại. Bạn có thể tham khảo bài viết: How HTML5 Web Sockets Interact With Proxy Servers và WebSockets, caution required. Bởi vậy cần cảnh giác để xử lý với WSS và Falling back về giao thức được hỗ trợ.
Các trung gian không hỗ trợ WebSocket. Nếu vì lý do nào đó mà WebSocket không được hỗ trợ thì bạn cần đảm bảo rằng connection sẽ tự fallback về một lựa chọn long-polling phù hợp.
REST vs WebSocket — Performance Test
Nếu bạn thực hiện một performance test cho REST và WebSocket, bạn có thể thấy rằng WebSocket thực hiện tốt hơn khi ở mức tải cao (high load). Điều này không có nghĩa REST là không hiệu quả. Bởi mỗi đối tượng xử lý những bài toán khác nhau và không thể chỉ so sánh bằng những kết quả test này.
Tuy nhiên, có thể nhận thấy rằng WebSocket là lựa chọn tuyệt vời để xử lý các long-lived bi-direction data streaming và theo các gần như realtime. Trong khi đó REST là tốt cho các kết nối theo tình huống (occassional communication).
Webbook (cho kết nối giữa các server)
Nếu bạn muốn lấy dữ liệu từ API khi có dữ liệu thay đổi, polling phải là lựa chọn đầu tiên xuất hiện trong đầu. Nhưng khi đó là kết nối giữa các server, thì chi phí polling sẽ là rất lãng phí (trung bình 98.5% poll là lãng phí).
Webhook là đấng cứu thế trong tình huống này. Đầu tiên, Sender Node đăng ký một Callback URL trong một hoặc nhiều Receiver Node. Khi một event xảy ra ở phía Sender, thì Webhook sẽ được trigger và gửi một event object với dữ liệu mới (bằng một HTTP POST request) đến các Receiver Node sử dụng Callback URL đã được đang ký. Điều tuyệt vời ở đây là server load ở cả Sender Node và Receiver Node đều được giảm mạnh với Webhook. Nó đảm bảo trải nghiệm người dùng tốt hơn trong khi developer có thể tận dụng service endpoint cho những thứ ý nghĩa hơn mà không lãng phí cho các polling.
Các ứng dụng: Notification khi một user đăng ký hoặc một user update một profile setting.
Bạn sẽ sử dụng giải pháp nào cho API sắp tới?
Việc sử dụng kỹ thuật nào tuỳ thuộc vào context của ứng dụng của bạn.
HTTP/1.1 vs HTTP/2: Chúng là những Transport Protocol. Khả năng Multiplexing (chia sẻ) trong HTTP/2 là tốt, nhưng nó không được support ở mọi nơi. Trong những trường hợp như vậy cần đảm bảo rằng việc fallback trong ứng dụng không tạo ra đống hỗn độn. Dùng để tranfer data, thì HTTP/1.1 vẫn là lựa chọn tuyệt vời.
RESTful APIs: Đến thời điểm hiện tại vẫn rất ổn cho các ứng dụng Web. Tuy nhiên đang có những thảo luận mới về JSON-Pure: Replace RESTful APIs with JSON-Pure.
JSON vs XML: Sử dụng JSON. Đó là xu hướng, và cũng rất tiện để xử lý.
HTTP Polling: Đã cũ, nhưng vẫn là lựa chọn tốt cho việc xử lý với API. Nếu dữ liệu của bạn thay đổi thường xuyên hoặc realtime, không sử dụng Short Polling, chỉ dùng WebSocket, công nghệ tốt hơn cho realtime. Luôn luôn sử dụng Long và Periodic Polling một cách phù hợp với các REST principles.
HTTP Streaming: Cái này sử dụng tốt cho những ứng dụng dạng news/social media feeds, stock/score board, tweet… Nhưng trong thực tiễn, người ta thường dùng WebSocket hơn là HTTP Streaming.
HTTP/2 Server Push là lựa chọn tốt cho việc sending resource đến client theo một cách quản lý tốt hơn. Nhưng không phải tất cả các trung gian và browser sẽ hỗ trợ. Nên cần đảm bảo có xử lý fallback.
Server-sent event là một công nghệ khá mới và chưa được support bởi toàn bộ các browser chính, bởi vậy chưa phải là lụa chọn cho những enterprise level web application.
WebSocket cung cấp một giao thức tốt để thực hiện bi-direction, fullduplex communication. Điều này rất cuốn hút với các game, message app, collaboration tool, và cho những trường hợp cần realtime update theo cả hai hướng.
Webhook xử lý một trường hợp rất cụ thể. Nếu server của bạn cần kết nối thường xuyên bạn nên dùng WebSocket. Nếu server của bạn thi thoảng mới kết nối, sử dụng REST call. Nếu server của bạn cần kết nối một chiều (unidirection) trên một sự kiện xảy ra, dùng Webhook. Không sử dụng Polling để kiểm tra thay đổi dữ liệu hoặc trạng thái, nó là một sự lãng phí.
Proxy và Intermediaries sẽ ăn những packet hoặc timeout unexpectedly. Cần nhận thức điều đó và có xử lý cẩn thận.
Sử dụng các giao thức bảo mật (HTTPS, WWS) để xử lý các kết nối của bạn. Như vậy các Intermediaries sẽ gây ảnh hưởng ít đến kết nối của bạn, cũng như điều này sẽ bảo mật cho dữ liệu của bạn.
Developer yêu thích webhook. Nhưng đảm bảo nó được vận dụng đúng.
Bạn thật sự không cần luôn luôn sử dụng các công nghệ mới nhất, đặc biệt cho các ứng dụng mức độ enterprise. Cần đảm bảo rằng infrastructure hỗ trợ công nghệ bạn lựa chọn, cũng như đảm bảo xử lý fallback cho những trường hợp cần thiết.
Nguồn Quang Vu Trong
Last updated
