Tác giả: admin

Sutunam là công ty công nghệ của Pháp với hơn 40 nhân viên làm việc tại Việt Nam bên cạnh trụ sở chính tại Lyon, Pháp. Với hơn 10 năm kinh nghiệm trong lĩnh vực Open Source, Sutunam nổi bật với thế mạnh chuyên môn ở mảng Ecommerce. Công ty làm việc với đa dạng các dịch vụ xoay xung quanh website Ecommerce: từ hoạch định chiến lược kinh doanh số, thiết kế trải nghiệm trên website và mobile app, cho đến các dịch vụ về hạ tầng máy chủ. Sutunam hoạt động như một nhà tư vấn dự án số cho khách hàng, trong đó Progressive Web App là cũng là một hướng đi mà công ty chú trọng.

Progressive Web App (PWA) là gì?

PWA (progressive web apps) là dạng web app được xây dựng dựa trên các công nghệ của website, nhưng mang lại trải nghiệm tương tự như Native App. Nhờ vào tính năng của service worker, manifest và https, PWA có thể hoạt động offline ngay cả khi không có mạng. Khi người dùng vào website PWA thông qua trình duyệt trên mobile, họ có thể cài đặt website PWA trong điện thoại. Sau đó, họ có thể truy cập trở lại website thông qua icon ngay trên điện thoại, tương tự như khi họ click vào một icon của native app để truy cập phần mềm vậy.

Vậy PWA có gì khác so với một Native App?

Trải nghiệm của người dùng

Thông thường, quá trình mua hàng của người dùng sẽ đi từ việc tìm kiếm bằng phiên bản mobile website – responsive thông thường của phiên bản đó. Khi truy cập, bạn sẽ nhận được gợi ý tải app để vào web nhanh hơn chẳng hạn. Sau đó, bạn sẽ được điều hướng sang App Store hay Google Play, iOS Store, để download và cài đặt app vào máy. Cuối cùng, bạn sẽ tìm kiếm lại những thứ mình cần trong app đó một lần nữa và tiến hành thanh toán.

Đối với những người lần đầu tiên sử dụng website, hoặc ít mua hàng của doanh nghiệp đó, đây là một quy trình khá rắc rối. Theo thống kê, có gần 50% khách hàng lần đầu tiên đến với website rất dễ dàng bỏ qua giai đoạn gợi ý tải app về mobile. Ngoài ra, người dùng cũng có tâm lý ngại tải app mới để tăng dung lượng của điện thoại. Vậy phải làm gì để tăng trải nghiệm người dùng trên mobile responsive website, để giúp cho việc thanh toán trở nên dễ dàng và tiết kiệm thời gian hơn?

Progressive Web App chính là giải pháp.

Trải nghiệm người dùng với PWA sẽ đơn giản hơn rất nhiều. Khách hàng chỉ việc tìm kiếm trên mobile website và thanh toán đơn hàng, cuối cùng nhấn vào Add to homescreen để tải website về dưới dạng icon. Vậy là lần sau khách hàng chỉ cần nhấn vào icon để trở lại với website. Trải nghiệm này sẽ tương tự như khi người dùng app trong điện thoại. Với người dùng, đây là một giải pháp cực kỳ tiện dụng vì vẫn được sử dụng mobile website rất nhanh chóng mà không cần tải app về.

Release Cycle

Với PWA, release cycle cũng đơn giản hơn. Với các lập trình viên mobile, mỗi lần có update hay tính năng mới, họ sẽ phải cập nhật phiên bản mobile app. Mỗi lần update như thế, các dev sẽ phải đẩy lên lại các chợ ứng dụng, quá trình như thế sẽ mất khá nhiều thời gian và công sức hơn so với PWA cập nhật trang web.

Với PWA, bạn chỉ việc release bản update một lần và refresh cache trên website. Tính năng đồng bộ ngay cả khi người dùng không mở PWA cũng được phát triển. Twitter được biết đến là một trong những đơn vị tiên phong trong việc sử dụng PWA. App size trên Android app của Twitter chiếm dụng 24mb, iOS app chiếm 214mb dung lượng máy, trong khi đó với PWA chỉ tốn 600 kb cho điện thoại. Đối với những khách hàng không muốn tốn quá nhiều dung lượng điện thoại hay không muốn cài đặt thêm các app khác gây tốn bộ nhớ máy thì đây là một lựa chọn tuyệt vời.

Chi phí vận hành và duy trì

Chi phí doanh nghiệp và lập trình cũng là một đề cần lưu tâm cho một dự án công nghệ. Với một doanh nghiệp e-commerce, xây dựng website cùng IOS + Android app sẽ yêu cầu chi phí vận hành lớn với đội nhân sự bao gồm front-end, back-end, IOS developer và Android developer.

Trong khi đó với PWA, với bản chất web-app dựa trên nền tảng công nghệ website, đội ngũ sẽ rút ngắn chỉ cần frontend và backend. Tuy việc thực hiện ứng dụng PWAs đòi hỏi số lượng nhân lực ít hơn, nhưng lại cần nhiều kỹ năng hơn. Đối với đội ngũ front-end đang quen thuộc với JQuery và HTML từ cách phát triển truyền thống backend-driven website, bây giờ sẽ cần học hỏi và tìm hiểu nhiều dạng kiến thức hơn để thực hiện dự án, và đội ngũ lập trình website truyền thống sẽ phải hiểu thêm về trải nghiệm người dùng trên mobile app.

Search Engine Optimization

Ưu điểm của PWA là ta có thể tối ưu hóa SEO cho nó. Vì vẫn là server side rendering nên ta vẫn có thể tối ưu hóa việc hiển thị trên Google với các kỹ thuật về technical SEO.

Đối với native app, ta khó có thể tối ưu hóa nội dung SEO mà chỉ có thể giới thiệu trên website, dẫn link tới chợ ứng dụng, hoặc trả tiền quảng cáo trên các chợ ứng dụng. Ngoài ra, PWA được tạo ra để tối ưu hóa trải nghiệm người dùng trên mobile, nhanh hơn, tiện dụng hơn, về thiết kế nó vẫn là mobile-first design và tuân thủ các nguyên tắc thiết kế được ưu ái của các công cụ tìm kiếm như Google, Bing.

Progressive Web App và Native App có đang trong thế “đối đầu” nhau?

Với những ưu thế nổi trội của PWA – là sự kết hợp của website và native app, nhiều người đã đặt các câu hỏi và so sánh PWA với Native App. Nhưng sự thật thì hai nền tảng này hoàn toàn không nằm trong thế đối đầu với nhau. Ít nhất ở thời điểm hiện tại.

Số lượng người dùng di động trên thế giới là khoảng 3 tỷ người, thị trường hoàn toàn đủ lớn để PWA và Native App cùng phát triển. Bên cạnh đó, PWA giúp chuyển hóa first-time user (người mua lần đầu) khá tốt, nhằm giúp họ làm quen với nhãn hàng và dần trở thành khách hàng trung thành. Từ đó, doanh nghiệp dễ dàng thu hút họ hơn trong việc tải và sử dụng native app của mình. Vì vậy, có thể thấy, ở thời điểm hiện tại PWA đang hỗ trợ cho Native App, chứ không hề ở thế đối đầu nhau.

Bên cạnh đó, PWA hiện tại vẫn đang trong quá trình phát triển nên vẫn còn khá mới mẻ. Đối với những doanh nghiệp có tiềm lực tài chính tốt, họ sẽ lựa chọn sử dụng cả hai vì không ai muốn mất khách hàng cả, doanh nghiệp nào cũng sẽ muốn tối ưu hóa lợi nhuận của mình.

Với các doanh nghiệp vừa và nhỏ, chi phí duy trì IOS app và Android App sẽ khá cao, nhất là với các Ecommerce app. PWA có thể chính là giải pháp phù hợp cho họ. Đặc biệt, đối với các doanh nghiệp có số lượng tải app của họ quá thấp, họ sẽ tìm cách để tối ưu hóa chi phí, tìm cách nào tiết kiệm hơn so với việc bảo trì Native App và cũng tìm đến với PWA.

Tương lai của Progressive Web App ở thị trường châu Á sẽ ra sao?

Châu Á là thị trường tiềm năng với lượng dân số đông, bối cảnh thị trường công nghệ độc đáo. Vì thế, tại châu Á, các doanh nghiệp sẽ đối mặt cả những vấn đề mà thế giới gặp phải, cũng như chưa thị trường nào từng trải qua. Nếu lựa chọn một nơi có một bước nhảy vọt và tiên phong về công nghệ, những báo cáo thị trường luôn chọn châu Á là nơi đi đầu trong tất cả những xu hướng đó.

Bối cảnh thị trường châu Á có 4 điểm chính:

• Mức độ sử dụng di động rất cao
• Việc sử dụng di động để mua hàng và truy cập mạng xã hội rất phổ biến
• Dễ dàng chấp nhận công nghệ mới
• Các công ty công nghệ nhanh chóng mở rộng cơ hội sáng tạo.

Mức độ sử dụng di động ở châu Á đặc biệt cao, nhiều hơn hẳn so với laptop, TV hay các hình thức giải trí khác. Khả năng tiếp cận công nghệ của gen Z rất nhạy bén. Vì là những người trưởng thành hoàn toàn trong thời kỳ công nghệ nên việc họ tương tác trên mạng xã hội rất cao, hình thành nên những ngành nghề hoàn toàn mới như content creator, influencer, streamer. Hành vi trên mạng xã hội rõ ràng cũng đã thay đổi rất nhiều.

Mức độ sử dụng di động ở châu Á rất cao, nhiều hơn hẳn so với laptop, TV hay các hình thức giải trí khác. Khả năng tiếp cận công nghệ của gen Z rất nhạy bén. Vì là những người trưởng thành hoàn toàn trong thời kỳ công nghệ nên việc họ tương tác trên mạng xã hội rất cao, hình thành nên những ngành nghề hoàn toàn mới như content creator, influencer, streamer. Hành vi trên mạng xã hội rõ ràng cũng đã thay đổi rất nhiều.

Về khả năng thích ứng với công nghệ mới ở châu Á gần như cao hơn hẳn so với các khu vực khác trên thế giới. Một phần của vấn đề này liên quan đến bối cảnh văn hóa độc đáo của khu vực này. Đây là môi trường khá non trẻ, các công ty đa phần đều thuộc first generation (thế hệ đầu tiên) nên họ sẽ không có lịch sử 200, 300 năm hay những yếu tố lịch sử tương tự. Từ đó, các công ty thường sẽ mở rộng và dễ dàng đón nhận xu hướng hơn và có nhiều cơ hội sáng tạo hơn.

Ở châu Á cũng sẽ gặp những vấn đề mà không có châu lục nào gặp phải (như không có quốc gia nào trên thế giới có đến hơn 1 tỷ dân như Trung Quốc, Ấn Độ) nên đây cũng là động lực để đáp ứng nhu cầu thị trường đa dạng để các doanh nghiệp công nghệ tiếp tục phát triển nhiều hơn trong tương lai. Bên cạnh đó, ta cũng có thể thấy sự khác biệt về thị trường công nghệ phát triển cao (Nhật Bản – Hàn Quốc) và đang phát triển (Đông Nam Á), tạo ra một bối cảnh đặc biệt thú vị và khó dự đoán tại Châu Á

Không có một “”châu Á đồng nhất””, những công ty công nghệ lâu đời ở Hàn Quốc và Nhật Bản nên sẽ mang đến cho các lập trình viên những cơ hội công việc ổn định và môi trường phát triển chắc chắn hơn. Trong khi đó, Trung Quốc, Ấn Độ và các quốc gia khu vực Đông Nam Á sẽ phải đối mặt với những khó khăn khác nhau, nên đây cũng là cơ hội để các công ty có cơ hội tiếp xúc với PWA nói riêng và các công nghệ mới nói chung.

Từ bối cảnh công nghệ của châu Á, ta có khẳng đinh về châu Á là một mobile-first region, châu lục được thống trị bởi nhu cầu sử dụng di động. Tối ưu hóa trên di động từ đó cũng sẽ mang lại cạnh tranh màu mỡ cho doanh nghiệp.

Một đặc tính thị trường châu Á ta có thể là sự thống trị của Marketplace – những trang web trung gian, các sàn thương mại điện tử, từ Taobao, Lazada, Shopee, Tiki,… Vậy nên để các doanh nghiệp nhỏ và vừa, những doanh nghiệp không phải là Marketplace muốn tồn tại được, họ bắt buộc phải sáng tạo nhiều hơn, tiến bộ nhiều hơn, tìm những đường ngách để đi, tăng cường các kế hoạch branding cho doanh nghiệp trên tinh thần tập trung tối ưu mobile. PWA ở đây sẽ là một lựa chọn đổi mới có hiệu quả dài lâu cho các doanh nghiệp này.

PWAs trên ecommerce – bước đầu tiếp cận Headless Commerce

Kể cả khi người dùng đến với cửa hàng thực tế mua hàng, họ vẫn sử dụng di động để xem review của người mua trước, so sánh với các cửa hàng khác tương đương để đi đến quyết định có mua sản phẩm đó hay không. Khách hàng quan tâm tới việc tiếp cận nhãn hàng ở nhiều khía cạnh hơn là chỉ mua ở cửa hàng.

Khi di động là chìa khóa để phát triển doanh số, headless commerce cũng là sự phát triển tất yếu trong e-commerce.

Headless Architecture là gì? Đó là việc phát triển tách rời phần front-end và back-end của website, thông tin sẽ được gọi thông qua hệ thống API. Headless cho phép phần front-end (giao diện) không phụ thuộc và linh hoạt hơn khi tùy chỉnh và cá nhân hóa trải nghiệm người dùng, dễ dàng hơn cho doanh nghiệp kết nối thông tin với nhiều kênh bán hàng hơn (multiple touch-point) – một trong những yếu tố nền tảng của omnichannel để tạo ra vòng tròn trải nghiệm đa điểm cho khách hàng. Từ đó tăng sale, năng lực cạnh tranh và quản lý đồng nhất cho doanh nghiệp.

Thay vì là cấu trúc backend-driven truyền thống, xu hướng headless hiện tại sẽ phân tách cấu trúc frontend và backend. Backend sẽ xử lý phần logic, frontend sẽ độc lập kết nối với rất nhiều selling point để tạo ra lợi thế cạnh tranh và tăng sale cho doanh nghiệp.

Với PWA, lập trình viên cũng sẽ bắt đầu phải làm quen với việc phát triển tách rời front-end và back-end, làm việc với manifest và service worker, cho phép cache các thông tin và chức năng đẩy thông báo (push notification) tương tự như native app. Đây cũng sẽ bước đầu chuyển đổi website truyền thống trở thành cấu trúc headless.

Tuy còn khá nhiều thách thức, nhưng nếu xét tới khía cạnh thị trường và hỗ trợ công nghệ, ta có thể sự phát triển của PWAs còn tiếp tục tăng cao trong tương lai. Hi vọng bài viết sẽ đóng góp thêm một vài góc nhìn cho các bạn lập trình viên khi tiếp cận PWA.

Single Page Application – SPA là thuật ngữ đã xuất hiện cách đây từ nhiều năm về trước. SPA đem đến người dùng sự trải nghiệm web tuyệt vời nhất không khác gì mobile. Chính vì vậy ngay từ khi mới ra đời, SPA đã được các chuyên gia đánh giá đây là một xu hướng lập trình web trong tương lai. Vậy điều đó có thành sự thật, Single Page Application mang đến những lợi ích như thế nào cho lập trình viên và người dùng? Tại bài viết này, hãy cùng chúng tôi đi giải đáp xem rốt cuộc Single Page Application là gì mà được ca tụng nhiều đến vậy nhé.

Single Page Application là gì? Những ưu và nhược điểm khi tạo web theo SPA

Single Page Application là gì?

Trước khi có sự xuất hiện của Single Page Application hay được viết tắt là SPA, việc lập trình web chủ yếu được thực hiện theo mô hình MVC (Model – View – Controller). Tuy nhiên, nguyên lý hoạt động của kiểu cấu trúc này chỉ tập trung ở xử lý server mà không đáp ứng được những trải nghiệm người dùng. Chính vì vậy, rất cần đến một mô hình mới có thể đáp ứng được các yêu cầu của server và client. Và đó cũng chính là lý do mà Single Page Application được ra đời.Xem thêm: dịch vụ vận chuyển hàng không là gì

SPA là một kiểu lập trình web mà ở đó người dùng có thể truy cập vào nhiều trang web con khác nhau mà không làm ảnh hưởng đến trang web gốc. Khi người dùng truy cập vào bất kỳ thành phần nào trên trang, SPA sẽ chỉ chạy nội dung của thành phần đó mà không tải lại toàn bộ trang như các web truyền thống. Các thành phần chung như header, footer, thanh menu sẽ được giữ nguyên.

SPA sẽ tập trung xử lý ở client, đẩy mạnh hơn vai trò của frontend. Frontend chính là phần mà người dùng có thể nhìn thấy và tiếp nhận request của người dùng từ đó xác định được những tính năng và dữ liệu cần thiết, sau đó mới gửi yêu cầu đến backend. Backend nhận yêu cầu và trả về dữ liệu ra bên ngoài website. Từ đó làm tăng trải nghiệm người dùng, giúp người dùng có cảm giác như đang sử dụng trên mobile chứ không phải là một trang web.

Ví dụ một số mẫu website bạn vẫn sử dụng hàng ngày được lập trình theo kiểu SPA như Facebook, Youtube, Twitter, Shopee,…

Rất nhiều trang web nổi tiếng được lập trình theo SPA như Youtube, Facebook, Twitter,…

Web SPA hoạt động khác gì một trang web truyền thống?

Có hai đặc điểm nổi bật nhất tạo nên sự khác biệt giữa trang web sử dụng SPA và trang web truyền thống là:

• Web SPA có sự phân chia rõ ràng giữa backend và frontend
• Web SPA đẩy mạnh xử lý ở frontend

Sự phân chia rõ ràng giữa backend và frontend

Nếu lập trình theo kiểu truyền thống sẽ khó phân chia được ranh giới cụ thể giữa frontend và backend. Chẳng hạn như Laravel Framework, bạn vẫn có thể thực hiện code PHP trong phần View. Tuy nhiên đối với SPA lại hoàn toàn khác, backend và frontend được tách bạch tới nỗi chúng có thể nằm ở 2 dự án khác nhau mặc dù chúng sinh ra là để dành cho nhau. Việc trao đổi dữ liệu giữa frontend, backend trong SPA thường qua các Restful API và định dạng của chúng  thường là JSON.

Cách hoạt động của frontend và backend theo SPA có thể được mô tả như sau:

• Khi người dùng truy cập trang web, frontend sẽ tiếp nhận request chứ không phải backend. Hiểu đơn giản, web SPA thực hiện routing ở frontend chứ không phải backend như kiểu lập trình truyền thống.
• Sau khi tiếp nhận request, frontend sẽ xác nhận người dùng muốn sử dụng tính năng nào và cần những dữ liệu gì sau đó mới gửi request tới backend. Cuối cùng, backend sẽ thực hiện yêu cầu và trả về những dữ liệu mong muốn.
• Frontend nhận dữ liệu từ backend và dựa vào dữ liệu này để render ra nội dung trang web một cách hoàn chỉnh.

SPA có sự tách bạch rõ ràng giữa Frontend và Backend

Web SPA đẩy mạnh xử lý về frontend

Đối với những trang web được lập trình theo kiểu SPA, vai trò của frontend sẽ được đẩy mạnh hơn. Frontend sẽ đảm nhiệm hoàn toàn việc render giao diện và xử lý những thay đổi, trong khi đó, backend chỉ cần ngồi chờ xem frontend có yêu cầu gì thì trả về cái đó. Web SPA yêu cầu xử phức tạp ở frontend, vì vậy mà nó sẽ áp dụng một framework hay thư viện nào đó về SPA để xử lý. Dựa vào framework hay thư viện này mà các nhà lập trình viên dễ dàng hơn trong việc phát triển một web SPA.Xem thêm: vận chuyển hàng không quốc tế

Ưu và nhược điểm khi sử dụng Single Page Application

Ưu điểm của web SPA

Single Page Application mang lại rất nhiều những điểm nổi bật như:

• Hỗ trợ target dễ dàng: Mọi thông tin sẽ được đặt trên cùng một trang, đây là phương án hiệu quả đối với SEO bởi nó sẽ hướng đến bộ từ khóa. Với Single Page Application, nội dung sẽ được dàn trải trong một trang do đó có thể người dùng phải kéo đến những dòng cuối cùng mới tìm thấy được. Do vậy, hãy suy nghĩ cẩn thận để đưa ra được những nội dung phù hợp nhất, hấp dẫn người đọc nhé.
• Độ tin cậy của SPA: đối với SPA, đường link đóng vai trò quan trọng, nó quyết định xem trang web của bạn đang nằm ở thứ hạng bao nhiêu. Những link trỏ tới sẽ đều di chuyển đến trang chủ của bạn, do vậy độ tin cậy của SPA vô cùng cao.
• Thích hợp cho các dòng điện thoại: Single Page Application trang web của bạn sẽ được load nhanh hơn rất nhiều khi sử dụng mobile, tránh trường hợp load lâu dẫn đến mất đi lượng khách hàng.

Nhờ có SPA trang web của bạn sẽ được load nhanh hơn rất nhiều khi sử dụng mobile

Ngoài ra còn rất nhiều những ưu điểm cho cả lập trình viên và người dùng.

Đối với lập trình viên

• Lập trình viên sẽ không cần phải viết code HTML để render trên server mà thay vào đó việc render HTML cho request của người dùng sẽ được thực hiện bởi chính thiết bị truy cập xử lý.
• Sự tách biệt giữa frontend và backend cho phép việc thực hiện song song giúp đẩy nhanh tiến độ xử lý.
• Tiết kiệm băng thông do chỉ có sự chuyển giao dữ liệu giữa server và client, còn đối với các tài nguyên tĩnh thì chỉ cần tải một lần duy nhất là được.
• Sử dụng SPA giúp tận dụng được các lợi thế từ framework của JavaScript.
• Tận dụng code một cách dễ dàng để phát triển mobile app.

Đối với người dùng

Trang web được thiết kế theo SPA sẽ mang đến những trải nghiệm tốt hơn cho người dùng khi truy cập trang. Với mô hình này, thời gian tải trang sẽ được rút ngắn hơn, nội dung trang tập trung vào nội dung mà người dùng muốn xem. Chính vì vậy mà các trang web này trở nên linh hoạt hơn và thu hút đối với người dùng hơn.Xem thêm: vận chuyển hàng không nội địa

Một vài hạn chế của SPA

• SPA đòi hỏi các nhà lập trình phải thông thạo các ngôn ngữ HTML, CSS, JS, ajax, es6 và có kinh nghiệm với frontend.
• Mô hình SPA kém phù hợp với những thiết bị có hiệu năng thấp do mọi thao tác đều được xử lý trên cùng một trang web. 
• Tốc độ tải trang lần đầu cũng kém hơn so với các trang web truyền thống.
• Các kỹ thuật SEO nâng cao như cấu trúc Silo sẽ không thể áp dụng được.
• Nội dung trên trang bị giới hạn do vậy nhiều vấn đề không thể chi tiết được.
• Không phải dự án nào cũng phù hợp: SPA chỉ thích hợp sử dụng với những dự án cần maintain, dự án có định hướng phát triển lâu dài, các phần mềm dịch vụ hay những dự án tập trung nhiều vào trải nghiệm người dùng UX.

Ở thời điểm hiện tại, SPA đã là một kiểu lập trình web có chỗ đứng vững chắc và trở thành sự lựa chọn lý tưởng của nhiều dự án công nghệ mới. Tuy nhiên vẫn còn quá sớm để kết luận được sự hùng mạnh của Single Page Application trong giới lập trình tương lai. Với những chia sẻ trên, chắc hẳn đã giúp các bạn đã hiểu hơn về Single Page Application là gì cũng như các thông tin hữu ích khác về SPA. Hy vọng rằng trong tương lai, SPA sẽ càng được đổi mới và hoàn thiện hơn nữa để phù hợp với người dùng.

Trong bài “Backend for frontend (BFF) pattern(1)” tôi đã nêu ra những vấn đề mà khi triển khai một hệ thống “Genneral Purpose Backend Server-Side” sẽ gặp phải.

Một giải pháp để giải quyết những vấn đề nêu trên đó là “Backend For Fontend“. Mô hình này lần đầu được mô tả bởi Sam NewMan

Kiến trúc BFF là một biến thể của API Gateway Pattern giữ cho phần xử lý dữ liệu được đặt tách biệt khỏi giao diện hoặc giảm thiểu nhất có thể . Với đề xuất một thành phần phía máy chủ đảm nhiệm cho mỗi nền tảng giao diện người dùng, mục đính để nâng cao trải nghiệm người dùng. Lớp BFF được thiết kế với nhiều Backend để đáp ứng yêu cầu của từng nền tảng giao diện khác nhau, nhờ mỗi Backend được thiết kế để đáp ứng yêu cầu riêng giúp cho trải nghiệm người dùng trở nên mượt mà, tối ưu cho từng giao diện.

Trước khi đi thiết kế một hệ thống sử dụng BFF chúng ta thử cân nhắc tới một số vấn đề sau:

• Thứ nhất BFF sẽ làm tăng độ trễ của hệ thống có phải không ? Đúng vậy dữ liệu sẽ cần đi qua BFF và được xử lý tại đó điều này sẽ làm tăng độ trễ nhưng điều đó có thể chấp nhận được khi mà BFF sẽ tiêu thụ tài nguyên ở máy chủ nơi có tài nguyên mạnh mẽ hơn thay vì ở phía máy khách có tài nguyên giới hạn.
• Thứ hai: Cần bao nhiều BFF cho hệ thống ?. Nhà triển khai có thể dựa vào việc phân loại nền tảng giao diện phục vụ thành các nhóm. Ví dụ: Nhà triển khai có thể xây dựng một BFF cho các giao diện mobile hoặc có thể phân chia thành hai BFF, một phục vụ cho Android, cái khác phục vụ cho IOS. Điều này dựa vào yêu cầu của các nền tảng giao diện có quá khác biết nhau không hay có thể gộp thành một nhóm.
• Thứ ba: Vấn đề trùng lặp code trong BFF, việc có mỗi BFF cho từng giao diện sẽ không tránh khỏi việc trùng lặp code cho những logic chung. Nhưng việc này cũng không phải là một vấn đề quả đáng ngại vì chúng được đặt tại máy chủ nơi mà tài nguyên hiện nay vô cùng mạnh và cũng không quá hạn hẹp.

Kết luận lại: Sử dụng mẫu BFF không chi giúp cải thiện đáng kể trải nghiệm người dùng giao diện mà con giúp nhà triển khai dễ dàng tối ưu về hiệu năng và mở rộng khả năng hỗ trợ giao diện mà không lo lắng ảnh hưởng tới những giao diện đã được hỗ trợ trước đó.

Introduction

Xuất phát từ mong muốn hỗ trợ giao diện trên nhiều nền tảng thì ở phía backend tạo ra các API genneric để dễ dàng tích hợp sau này, ở phía góc độ người triển khai thấy rằng điều đó sẽ làm tiết kiệm thời gian và giảm đi chi phí triển khai hỗ trợ nền tảng mới.

Nhưng càng phát triển thì chúng ta càng nhồi nhét nhiều thứ vào một nơi. Vì lúc này hệ thống đòi hỏi phải hỗ trợ được nhiều nền tảng hơn, mà mỗi nền tảng lại yêu cầu đặc điểm dữ liệu trả về có những yêu cầu cụ thể Ví dụ: Trên thiết bị di động không cần thiết trả về nhiều dữ liệu giống như trên nền tảng web desktop vì điều đó đơn giản là tài nguyên trên thiết bị di động không có nhiều giống như trên desktop.

Backend For Fontend pattern(BFF)

Thông thường ý tưởng của người phát triển ban đầu sẽ xuất phát sử dụng “A genneral purpose API backend”

Đối với những hệ thống được xác định từ trước với những nền tảng sẽ hỗ trợ thì cách tiếp cận này cũng sẽ thành công bởi vì

• Thứ nhất: Tách riêng backend và đưa phần xử lý đặt tại đó làm cho phần hiển thị trở nên nhẹ và tốn ít tài nguyên hơn. Ở phía giao diện chỉ có nhiệm vụ là hiện thị dữ liệu và thu thập tương tác của người dùng.
• Thứ hai: Tiết kiệm được thời gian và chi phí phát triển những chức năng sử dụng chung cho các nền tảng thay vì tách riêng và sẽ bị trùng lặp “hight coupling“.
• Thứ ba: Cách tiếp cận này có thể định tuyến các yêu cầu của ứng dụng khách(client) và xử lý xuyên suốt (bảo mật, auth, cached) điều này có thể làm giảm độ trễ và tài nguyên máy chủ(server).

Tuy nhiên từng nền tảng giao diện(User Interface) thì rất khác chưa kể logic được thiết kế riêng cho từng giao diện mà không phải chỉ đơn thuần là sắp xếp và trả về dữ liệu thông thường. Như tôi đã đề cập trước đó, ví dụ như đối với thiết bị di động sẽ rất khác về kích thước màn hình hiện thị, giới hạn hiện thị, dung lượng pin, bộ nhớ. Các khác biệt sẽ diện ra thường xuyên dẫn tới người phát triển cần cập nhật thay đổi đó trong khi vẫn phải giữ không làm ảnh hưởng tới nhưng giao diện khác.

Thông thường thì người phát triển sẽ cố gắng điều chỉnh những yêu câu cụ thể từ phía giao diện bằng cách tạo ra những đoạn code đặc biệt để xử lý. Nhưng cách này làm vấn đề càng thêm nghiêm trọng hơn bởi lúc này hệ thống sẽ cần phải cân bằng cả những ưu tiên cho những yêu cầu đặc biết và những yêu cầu chung từ các giao diện. Thêm vào đó các service phía dưới cũng sẽ bị ảnh hưởng theo để đáp ứng được những logic đặc biệt.

Một vấn đề khác mà “genneral purpose backedn server-side” sẽ gặp phải đó là sẽ xảy ra hiện tượng thắt cổ trai “bottleneck” khi có quá nhiều yêu cầu trên cùng một cấu trúc hạ tầng.

Một giải pháp cho những vấn đề trên mà hiện được sử dụng bởi SoundCloud thay “genneral purpose backedn server-side” đó là Backend For Frontend(BFF)(2)