Đăng bởi

Progressive Web App và tương lai trong lĩnh vực E-commerce

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
Progressive Web App và tương lai của nó trong lĩnh vực E-commerce sẽ như thế nào?

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.

PWA là gì
Progressive Web App là gì?

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?

user flow native app
User flow native app

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ề.

user flow pwa
User flow PWA

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.

PWA team

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
PWA giúp nâng cao trải nghiệm người dùng với mobile website

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.

progressive web app
Châu Á đã, đang và sẽ tiếp tục là thị trường “màu mỡ” của PWA

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.

Đăng bởi

Single Page Application là gì? Đây có phải là xu hướng lập trình Web hiện nay?

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.

Đăng bởi

Backend for frontend (BFF) pattern(2)

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 đó.

Đăng bởi

Backend for frontend (BFF) pattern(1)

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)

Đăng bởi

Micro frontend tại sao và như thế nào?

Tại sao bạn cần biết đến Micro frontend

Vấn đề cần giải quyết:

  • Ứng dụng càng lúc càng phình ra về quy mô, cũng như độ phức tạp
  • Một codebase FE duy nhất mà muốn maintain thì chỉ có gặp ác mộng hằng đêm
  • Bạn có nhiều team FE khác nhau, mỗi team chỉ làm việc chính trên một phần tính năng nào đó rất cụ thể, chỉ 1 codebase mà hơn 5 team vào làm việc trên đó thì thôi xong
  • Bạn muốn có 1 codebase viết bằng typescript, một codebase viết js, một feature được build bằng React, feature khác được build Vue

Micro frontend là cái gì

Đây là cách tiếp cận cũng na ná như microservice, thay vì 1, chúng ta có nhiều codebase, và trên từng codebase chỉ quản lý một tính năng cụ thể mà thôi.

Có thể xem một ứng dụng web là một bộ kết hợp của nhiều tính năng, mỗi một tính năng như vậy được quản lý bởi một team

Micro frontend tại sao và như thế nào?

Thuật ngữ này được giới thiệu lần đầu vào 2016 bởi Thourghtworks Tech Radar

An architectural style where independently deliverable frontend applications are composed into a greater whole

Micro frontend tại sao và như thế nào?

Một cách trực quan hơn bạn có thể tham khảo hình sau

Micro frontend tại sao và như thế nào?

Còn đây là demo của trang microfrontends.com https://demo.microfrontends.com/

Hiện thực hóa như thế nào

Để có thể hiện thực hóa hoàn chỉnh micro frontend sẽ bao gồm rất nhiều thứ, ở đây chỉ tóm tắt một số vấn đề cơ bản cần giải quyết

Tương tác giữa các ứng dụng

Một câu hỏi được đặt ra đầu tiên là nếu tách ra thành nhiều bộ source như vậy, làm sao chúng có thể nói chuyện được với nhau? Một cách tổng quát, nên hạn chế việc trao đổi thông tin qua lại ít chừng nào tốt chừng đó, bởi vì nếu bạn làm ngược lại, nghĩa là bạn đang lặp lại vấn đề chúng ta muốn giải quyết ngay từ đâu: decoupling các tính năng với nhau.

Nhưng việc trao đổi giữa các ứng dụng với nhau là không tránh khỏi và cần thiết, chúng ta chỉ tiết chế chứ không loại bỏ hết, Custom event là một cách, cách khác, lấy mô hình truyền callback và data từ trên xuống trong React để làm kênh trao đổi thông tin, làm như thế nó sẽ rất tường minh, cách thứ 3 là thông qua thanh đường dẫn trên trình duyệt, chút nữa nói kỹ hơn.

Tựa chung, chúng ta không share state, mà chỉ share dữ liệu trong database như microservice.

Thư viện component dùng chung

Nó chung, ý tưởng re-use lại những component UI không có gì mới, nghe cũng rất hợp lý, mặc dù ai cũng biết việc đó khó làm.

Sai lầm thường thấy là việc tạo các component như vậy quá sớm, việc hào hứng quá mức vào xây dựng một Framework UI chuẩn không cần chỉnh, viết một lần xài mãi mãi, thống nhất giao diện trên mọi mặt trận là điều thường thấy ở mọi team. Tuy nhiên, trong thực tế, kinh nghiệm cho biết rằng việc đó rất khó, nếu không muốn nói là không thể, không thể ngồi nghĩ ra một bộ Framework với tất cả các API cần thiết rồi đưa cho tất cả các team xài, chắc gì API đó đã đáp ứng đúng nhu cầu cho tất cả các team? Lời khuyên là các team cứ tạo ra những component riêng trong codebase nếu họ thấy cần, dù cho nó có bị duplicate đây nữa cũng chẳng sao. Và khi đã chín mùi, những API nào cần thiết sẽ hiện nguyên hình, chúng ta đưa những cho đang bị duplicate vào trong thư viện dùng chung.

Tất nhiên cũng có những ngoại lệ, những component mà nhìn vào chúng ta biết ngay là cần đưa vào share component, như icon, label, button, autocomplete, drop-down, search, table. Và nhớ là chỉ đưa đúng UI logic, đừng đưa bất kỳ business logic và domain logic vào đây. Ví dụ như một component ProductTable cho riêng cái domain Product là không nên, chỉ nên làm một cái component Table.

Thoạt nghe làm một share component có vẻ đơn giản, nhưng nó lại là công việc đòi hỏi kỹ thuật phải rất cứng tay, và người có nhúng tay vào tất cả các team.

Styling

Styling 2020 là một câu chuyện dài, như mình đã kể trong một bài viết, tựa chung mà nói bạn có thể dùng BEM, dùng SASS, dùng CSS module, dùng CSS-in-JS, dùng Styled Component, dùng Tailwind, kiểu gì cũng được, miễn đảm bảo được style không chồng chéo lên nhau, thằng nào độc lập thằng đó, và tự tin đoạn code nó sẽ chạy như đúng như lường trước.

Các cách để integrate

Để hiện thực hóa ý tưởng của micro frontend, cũng có nhiều cách làm, cách nào cũng có đánh đổi. Tựu chung, nếu xét theo hướng giao diện, chúng ta có thể tổ chức nó theo dạng một ứng dụng dạng container, bao gồm những thành phần chung như headermenu, và các micro frontend sẽ nhúng vào phần ruột của trang

Micro frontend tại sao và như thế nào?

Cách 1: composition dùng server side template

Với một cách không chính thống lắm cho việc phát triển code FE, chúng ta render HTML ở phía server, với nhiều bộ template khác nhau. Chúng ta có một file index.html với các phần tử chung, server sẽ quyết định phần ruột trả về cho từng trang

<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>Feed me</title>
  </head>
  <body>
    <h1>🍽 Feed me</h1>
    <!--# include file="$PAGE.html" -->
  </body>
</html>

Ở ví dụ này đang dùng với Nginx, biến $PAGE sẽ ứng với URL đang được request

server {
    listen 8080;
    server_name localhost;

    root /usr/share/nginx/html;
    index index.html;
    ssi on;

    # Redirect / đến /browse
    rewrite ^/$ http://localhost:8080/browse redirect;

    # Dùng HTML nào để insert dựa vào URL
    location /browse {
      set $PAGE 'browse';
    }
    location /order {
      set $PAGE 'order';
    }
    location /profile {
      set $PAGE 'profile'
    }

    # Cho phép render ở index.html
    error_page 404 /index.html;
}

Kỹ thuật này mình không nắm lắm, nên cũng chỉ để đây cho các bạn tham khảo, trong thực tế mình gặp và làm việc với những cách làm bên dưới nhiều hơn.

Integrate lúc build

Cách này sẽ publish cái micro frontend ở dạng package, container sẽ khai báo những micro frontend này ở dạng dependency. File package.json nó sẽ trông như thế này:

{
  "name": "@feed-me/container",
  "version": "1.0.0",
  "description": "A food delivery web app",
  "dependencies": {
    "@feed-me/browse-restaurants": "^1.2.3",
    "@feed-me/order-food": "^4.5.6",
    "@feed-me/user-profile": "^7.8.9"
  }
}

Thoạt nhìn, cũng khá hợp lý, tuy nhiên nếu để ý, bạn sẽ thấy chúng ta phải re-compile và release trên từng cục dependency, rồi sao đó lại phải release tiếp container. Đây vẫn không phải là cách làm được khuyến khích.

Integrate lúc run-time bằng iframe

Đây cũng là cách mà dự án mình đang dùng, một cách tiếp cận đơn giản nhất để compose nhiều ứng dụng với nhau trong trình duyệt đã có từ rất rất lâu. Lợi ích có thể kể thêm của cách làm này là phần styling và biến global đều độc lập và không bị đụng độ lẫn nhau

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <iframe id="micro-frontend-container"></iframe>

    <script type="text/javascript">
      const microFrontendsByRoute = {
        '/': 'https://browse.example.com/index.html',
        '/order-food': 'https://order.example.com/index.html',
        '/user-profile': 'https://profile.example.com/index.html',
      };

      const iframe = document.getElementById('micro-frontend-container');
      iframe.src = microFrontendsByRoute[window.location.pathname];
    </script>
  </body>
</html>

Nhược điểm của cách này là việc tích hợp giữa các phần của ứng dụng, như route, history, deep-link sẽ rất phức tạp, responsive cũng sẽ gặp nhiều vấn đề cần xử lý hơn.

Integrate lúc run-time bằng JavaScript

Đây là cách linh hoạt nhất, và được nhiều team chọn làm. Mỗi một micro frontend sẽ được nhét vào trong trang bằng thẻ <script />. Container sẽ làm nhiệm vụ cho mount micro frontend nào và thực thi các hàm liên quan để báo cho các micro frontend sẽ render ở đâu và khi nào.

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <!-- Nó không render bất cứ gì cả -->
    <!-- Nó sẽ đưa vào hàm entry-point vào `window` -->
    <script src="https://browse.example.com/bundle.js"></script>
    <script src="https://order.example.com/bundle.js"></script>
    <script src="https://profile.example.com/bundle.js"></script>

    <div id="micro-frontend-root"></div>

    <script type="text/javascript">
      // Những global function này được nhét vào window bằng các đoạn script include ở trên
      const microFrontendsByRoute = {
        '/': window.renderBrowseRestaurants,
        '/order-food': window.renderOrderFood,
        '/user-profile': window.renderUserProfile,
      };
      const renderFunction = microFrontendsByRoute[window.location.pathname];

      // Sau khi đã có các hàm cần thiết,
      // đưa id của element sẽ dùng để render
      renderFunction('micro-frontend-root');
    </script>
  </body>
</html>

Trên đây chỉ là ví dụ cơ bản nhất để mô tả kỹ thuật sẽ làm, thật tế có thể phải thêm thắt một số thứ khác. Không giống với cách integrate lúc build, bundle.js có thể được deploy một cách độc lập. Và khác iframe, chúng ta có thể linh động chọn lựa việc render micro frontend nào chúng ta thích.

Nếu có hứng thú với cách làm này, có thể tham khảo thêm ví dụ chi tiết hơn

Integrate lúc run-time bằng Web Component

Một lựa chọn khác cũng tương tự như cách làm trên, mỗi một micro frontend sẽ được link với element

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <!-- Chưa render gì cả -->
    <script src="https://browse.example.com/bundle.js"></script>
    <script src="https://order.example.com/bundle.js"></script>
    <script src="https://profile.example.com/bundle.js"></script>

    <div id="micro-frontend-root"></div>

    <script type="text/javascript">
      // Những element type này được định nghĩa ở các script trên
      const webComponentsByRoute = {
        '/': 'micro-frontend-browse-restaurants',
        '/order-food': 'micro-frontend-order-food',
        '/user-profile': 'micro-frontend-user-profile',
      };
      const webComponentType = webComponentsByRoute[window.location.pathname];

      // Tạo instance và đưa vào document ứng với từng loại phù hợp
      const root = document.getElementById('micro-frontend-root');
      const webComponent = document.createElement(webComponentType);
      root.appendChild(webComponent);
    </script>
  </body>
</html>

Khác nhau duy nhất so với cách trên có lẽ chỉ là việc dùng web component thay vì một interface chúng ta tự định nghĩa.

Trao đổi giữa Backend

Cái này chưa biết, không dám chém.

Kết

Micro frontend có thể không lạ với một số người và khá mới với số còn lại, thực tế mà nói đã có rất nhiều dự án đang áp dụng kiến trúc này (dự án mình đang làm).

Cùng hy vọng với bài viết này bạn đã thấy công việc của những lập trình viên frontend không còn đơn thuần là việc làm sao cho trang web bay, lượn, responsive mượt mà, nếu bạn muốn tiến xa hơn, giới hạn là chân trời.

Các bài viết đã tham khảo