Recommended
Recommended
More Related Content
Similar to Gapo mobile apps at scale
Similar to Gapo mobile apps at scale (20)
Gapo mobile apps at scale
- 1. Challenges of Building Gapo Mobile App at Scale
- 2. Table of Contents Distribution, app crash, notification Due to the Nature of Mobile Applications Due to App Complexity Navigation architect, modular architecture, automated testing Due to Large Dev Teams Scaling build & merge times, planning and decision making 01 02 03
- 3. Challenges due to the Nature of Mobile Applications 01
- 4. Challenges due to the Nature of Mobile Applications Mistakes Are Hard to Revert 01 - Không cho phép deploy code trực tiếp như BE - Thời gian release có thể phụ thuộc vào review của Apple - User không update app ngay lập tức - Số lượng user update
- 5. Challenges due to the Nature of Mobile Applications (cont) Notifications Crash 02 03 - Cấu hình, xử lý điều hướng - Automated testing push notifications - Background notifications - Highly impact - Debuggability - Reproducibility
- 6. Challenges due to App Complexity 02
- 7. Challenges due to App Complexity Navigation architect 01 Modular architecture 02 Automated Testing 03
- 8. Navigation architect Inconsistent navigation Có thể ví dụ như popup, toast, fullscreen modal, half-screen or pages/screen => không đồng nhất về transition, duplicate code Asynchronous navigation Login form hoặc submit form => điều gì xảy ra nếu user cố tình thay đổi trong khi form chưa được xử lý xong Navigation framework or consistent navigation approach Self - building, coordinator protocol 0 1 0 3 0 2 Mobile & tablet 0 4
- 10. Modular architecture Modular Việc cần thiết chia ra thành các module nhỏ để sử dụng tại các nơi khác nhau, dev nhanh hơn. Ví dụ payment, sticker, input box Dependency Injection is a powerful tool for maintaining testable code 0 1 0 2
- 11. Automated testing Unit testing Validate url, hashtag từ string Integration testing Gọi user info từ api sau đó lưu vào local db Snapshot test So sánh layout app và design. Một số tool iOSSnapshotTestCase, SwiftSnapshotTesting UI test Có thể cần moking data test 0 1 0 3 0 4 0 2
- 12. Automated testing (cont) Consider efforts Tốn resources để viết, maintain Moked live data for testing Tốc độ, edge case, độ tin cậy, cần update lại test case trong một số trường hợp (test fails) 0 5 0 6
- 13. Challenges due to Large Dev Team 03
- 14. Challenges due to Large Dev Team Scaling Build & Merge Times Planning and decision making 01 03
- 15. Scaling build Build time at scale is one of biggest problems cả apple hay google đều không ưu tiên việc cải thiện build time cho project lớn - Bazel: Uber, Pinterest - Buck: Telegram, Facebook - Gradle: Netflix, Linkedin Optimize building Dynamic framework vs static framework vs monorepo 0 1 0 3 0 2
- 16. Planning & decision making Formalizing the planning process Chương 18: chuẩn hoá specification trước khi dev team planning iOS & Android Cả 2 bên thảo luận thống nhất từ function, feature flags, analytics có thể cả class structure. Từ đó có thể phát hiện ra lỗi sai của phía còn lại hoặc hoàn thiện phía mình 0 1 0 2
- 18. Thanks! Do you have any questions?
Editor's Notes
- NAT ( Network access transaction): Hiểu đơn giản Là một phương pháp để chuyển đổi thông tin IP của một gói tin từ mạng cục bộ (private) sang mạng mạng công cộng (internet). Thiết bị NAT sẽ dịch địa chỉ IP cá nhân từ bên trong tường lửa thành địa chỉ IP công khai (public-facing IP). Ta cần các thiết bị NAT để bảo mật và giải quyết sự giới hạn của IPv4 đối với những địa chỉ IP công khai sẵn có. Đó là lý do tại sao webapp không nên giả định rằng thiết bị hiện tại có 1 địa chỉ IP public tĩnh. Cùng tìm hiểu 1 chút về cách hoạt động của các thiết bị NAT. Nếu như bạn đang ở trong môi trường công cộng và kết nối vào mạng WiFi, máy tính của bạn sẽ được gán 1 địa chỉ IP mà nó chỉ tồn tại đằng sau NAT. Giả sử IP là 172.0.23.4, tuy nhiên, với thế giới bên ngoài, địa chỉ IP của bạn có thể mang giá trị khác, ví dụ 164.53.27.98. Vì vậy, thế giới bên ngoài sẽ thấy các request của bạn đến từ địa chỉ 164.53.27.98 nhưng thiết bị NAT sẽ đảm bảo các response cho những request (được gửi từ máy của bạn) sẽ trả về đúng chỗ là 172.0.23.4. Ơn trời các bảng ánh xạ (mapping table). Lưu ý rằng ngoài địa chỉ IP thì cổng (port) cũng là điều kiện cần thiết cho các giao tiếp mạng. STUN (Simple Traversal Of UDP Through NAT): Tiếp theo là STUN nhé, mấy cái khái niệm này rất quan trọng, nắm chắc thì khi implement rất dễ dàng :) STUN thì các bác cứ tạm hiểu là khi một máy chủ nào xài NAT (behind NAT) thì STUN server sẽ giúp cho client đó biết được địa chỉ IP và Port mà thiết bị NAT sử dụng. Và từ đó giúp cho các peer có thể lấy được địa chỉ của peer khác (IP nào, cổng mấy, NAT loại gì) để mà vượt rào vào chém gió chứ :D . Nhưng STUN có một nhược điểm là nó không support Symmetric NAT (NAT có nhiều loại), nhưng đừng lo "mày không làm được thì cứ để anh, TURN biến hình" :D TURN (Traversal Using NAT Relay): Cũng giống như STUN tuy nhiên TURN hỗi trợ cả giao thức TCP làm giao thức truyền tải. TURN bổ xung cho hạn chế của STUN là hỗ trợ Symmetric NAT. Dữ liệu thay vì được gửi trực tiếp tới các peer thì các peer sẽ gửi dữ liệu tới các TURN server và TURN server sẽ đóng vai trò trung gian vận chuyển gói tin. Điều này nâng cao giúp chất lượng dịch vụ của ứng dụng mà còn đảm bảo an toàn thông tin khi truyền dẫn. Nhưng cái gì cũng có hai mặt đúng ko? Chỉ có bức tường mới trường tồn với thời gian mà :D Vâng bất lợi của TURN là chi phí sử dụng lớn, vì sẽ có một lưu lượng băng thông lớn được sử dụng đúng không nào? Nhất là với chất lượng full HD hay video HD nữa. ICE (Interactive Communication Establishment): nôm na dễ hiểu là một giao thức được cùng để thiết lập phiên media dựa trên UDP đi qua NAT một cách nhanh nhất. ICE sẽ tìm đường tốt nhất để kết nối giữa các peer, nó thử tất cả khả năng có thể kết nối một cách song song và lựa chọn con đường hiệu quả nhất (cướp ngân hàng làm giàu). Đầu tiên nó sẽ cố gắng tạo ra một kết nối bằng cách sử dụng địa chỉ thu được từ hệ điều hành và card mạng của thiết bị, nếu không thành công (có thể thiết bị đằng sau NAT) thì ICE sẽ lấy địa chỉ bên ngoài của thiết bị bằng cách sử dụng máy chủ STUN (nhưng đời có lúc không gặp may), nếu không thành công nữa thì nó sẽ chuyển lưu lượng mạng qua một máy chủ chuyển tiếp là TURN. Nếu khó nhớ thì các bạn cứ nghĩ là ICE xài STUN xong không được thì đi xài TURN. Cho dễ nhớ . SDP (Session Description Protocol) được encode trong đối tượng RTCSessionDescription, để mô tả đặc tính media của hai đầu trong kết nối P2P như loại media đề truyền/nhận (audio, video, application data), network transports, loại codecs sử dụng và cấu hình, thông tin băng thông, và các thông tin metadata khác. Thông điệp SDP được trao đổi qua máy chủ báo hiệu hay còn gọi là được trao đổi qua kênh báo hiệu. Máy chủ báo hiệu có trách nhiệm gửi và nhận tất cả thông điệp đến tất cả các peers mà mong muốn kết nối đến peer khác STUN (Session Traversal Utilities for NAT): là giao thức giúp cho việc vượt NAT trong quá trình thiết lập kết nối. Trong WebRTC, một STUN client sẽ được xây dựng trong User Agent của trình duyệt để kết nối đến STUN server ngoài Internet. STUN server thực thi nhiệm vụ khá đơn giản, kiểm tra thông tin địa chỉ IP, port của request đến từ ứng dụng sau NAT, sau đó trả thông tin đó về dưới dạng response, nói cách khác là STUN giúp ứng dụng biết địa chỉ IP, cổng của nó sử dụng khi đi ra Internet. STUN có thể được vận chuyển trên UDP, TCP hoặc TLS TURN (Traversal Using Relays around NAT), là một mở rộng (extension) của giao thức STUN, cung cấp media relay cho tình huống thực hiện hole punching(vượt qua) không thành công. Trong WebRTC, User Agent của trình duyệt sẽ bao gồm một TURN client. TURN server được cung cấp trên Internet qua các nhà cung cấp dịch vụ, hoặc có thể cài đặt trong mạng doanh nghiệp. Giao thức UDP được sử dụng để giao tiếp giữa TURN client và TURN server qua NAT. Cổng UDP mặc định cho TURN là 3478. Trên thực tế TURN server thường là STUN server có bổ sung tính năng relay. TURN server thì có chức năng STUN, nhưng không phải mọi STUN server đều có chức năng TURN JSEP (Javascript Session Establishment Protocol - Giao thức thiết lập phiên của Javascript): Thông tin về phiên gieo tiếp của người gọi, và người nhận UDP (User Datagram Protocol) là một trong những giao thức cốt lõi của giao thức TCP/IP. Dùng UDP, chương trình trên mạng máy tính có thể gửi những dữ liệu ngắn được gọi là datagram tới máy khác. UDP không cung cấp sự tin cậy và thứ tự truyền nhận mà TCP làm; các gói dữ liệu có thể đến không đúng thứ tự hoặc bị mất mà không có thông báo. Tuy nhiên UDP nhanh và hiệu quả hơn đối với các mục tiêu như kích thước nhỏ và yêu cầu khắt khe về thời gian. Do bản chất không trạng thái của nó nên nó hữu dụng đối với việc trả lời các truy vấn nhỏ với số lượng lớn người yêu cầu.
- NAT ( Network access transaction): Hiểu đơn giản Là một phương pháp để chuyển đổi thông tin IP của một gói tin từ mạng cục bộ (private) sang mạng mạng công cộng (internet). Thiết bị NAT sẽ dịch địa chỉ IP cá nhân từ bên trong tường lửa thành địa chỉ IP công khai (public-facing IP). Ta cần các thiết bị NAT để bảo mật và giải quyết sự giới hạn của IPv4 đối với những địa chỉ IP công khai sẵn có. Đó là lý do tại sao webapp không nên giả định rằng thiết bị hiện tại có 1 địa chỉ IP public tĩnh. Cùng tìm hiểu 1 chút về cách hoạt động của các thiết bị NAT. Nếu như bạn đang ở trong môi trường công cộng và kết nối vào mạng WiFi, máy tính của bạn sẽ được gán 1 địa chỉ IP mà nó chỉ tồn tại đằng sau NAT. Giả sử IP là 172.0.23.4, tuy nhiên, với thế giới bên ngoài, địa chỉ IP của bạn có thể mang giá trị khác, ví dụ 164.53.27.98. Vì vậy, thế giới bên ngoài sẽ thấy các request của bạn đến từ địa chỉ 164.53.27.98 nhưng thiết bị NAT sẽ đảm bảo các response cho những request (được gửi từ máy của bạn) sẽ trả về đúng chỗ là 172.0.23.4. Ơn trời các bảng ánh xạ (mapping table). Lưu ý rằng ngoài địa chỉ IP thì cổng (port) cũng là điều kiện cần thiết cho các giao tiếp mạng. STUN (Simple Traversal Of UDP Through NAT): Tiếp theo là STUN nhé, mấy cái khái niệm này rất quan trọng, nắm chắc thì khi implement rất dễ dàng :) STUN thì các bác cứ tạm hiểu là khi một máy chủ nào xài NAT (behind NAT) thì STUN server sẽ giúp cho client đó biết được địa chỉ IP và Port mà thiết bị NAT sử dụng. Và từ đó giúp cho các peer có thể lấy được địa chỉ của peer khác (IP nào, cổng mấy, NAT loại gì) để mà vượt rào vào chém gió chứ :D . Nhưng STUN có một nhược điểm là nó không support Symmetric NAT (NAT có nhiều loại), nhưng đừng lo "mày không làm được thì cứ để anh, TURN biến hình" :D TURN (Traversal Using NAT Relay): Cũng giống như STUN tuy nhiên TURN hỗi trợ cả giao thức TCP làm giao thức truyền tải. TURN bổ xung cho hạn chế của STUN là hỗ trợ Symmetric NAT. Dữ liệu thay vì được gửi trực tiếp tới các peer thì các peer sẽ gửi dữ liệu tới các TURN server và TURN server sẽ đóng vai trò trung gian vận chuyển gói tin. Điều này nâng cao giúp chất lượng dịch vụ của ứng dụng mà còn đảm bảo an toàn thông tin khi truyền dẫn. Nhưng cái gì cũng có hai mặt đúng ko? Chỉ có bức tường mới trường tồn với thời gian mà :D Vâng bất lợi của TURN là chi phí sử dụng lớn, vì sẽ có một lưu lượng băng thông lớn được sử dụng đúng không nào? Nhất là với chất lượng full HD hay video HD nữa. ICE (Interactive Communication Establishment): nôm na dễ hiểu là một giao thức được cùng để thiết lập phiên media dựa trên UDP đi qua NAT một cách nhanh nhất. ICE sẽ tìm đường tốt nhất để kết nối giữa các peer, nó thử tất cả khả năng có thể kết nối một cách song song và lựa chọn con đường hiệu quả nhất (cướp ngân hàng làm giàu). Đầu tiên nó sẽ cố gắng tạo ra một kết nối bằng cách sử dụng địa chỉ thu được từ hệ điều hành và card mạng của thiết bị, nếu không thành công (có thể thiết bị đằng sau NAT) thì ICE sẽ lấy địa chỉ bên ngoài của thiết bị bằng cách sử dụng máy chủ STUN (nhưng đời có lúc không gặp may), nếu không thành công nữa thì nó sẽ chuyển lưu lượng mạng qua một máy chủ chuyển tiếp là TURN. Nếu khó nhớ thì các bạn cứ nghĩ là ICE xài STUN xong không được thì đi xài TURN. Cho dễ nhớ . SDP (Session Description Protocol) được encode trong đối tượng RTCSessionDescription, để mô tả đặc tính media của hai đầu trong kết nối P2P như loại media đề truyền/nhận (audio, video, application data), network transports, loại codecs sử dụng và cấu hình, thông tin băng thông, và các thông tin metadata khác. Thông điệp SDP được trao đổi qua máy chủ báo hiệu hay còn gọi là được trao đổi qua kênh báo hiệu. Máy chủ báo hiệu có trách nhiệm gửi và nhận tất cả thông điệp đến tất cả các peers mà mong muốn kết nối đến peer khác STUN (Session Traversal Utilities for NAT): là giao thức giúp cho việc vượt NAT trong quá trình thiết lập kết nối. Trong WebRTC, một STUN client sẽ được xây dựng trong User Agent của trình duyệt để kết nối đến STUN server ngoài Internet. STUN server thực thi nhiệm vụ khá đơn giản, kiểm tra thông tin địa chỉ IP, port của request đến từ ứng dụng sau NAT, sau đó trả thông tin đó về dưới dạng response, nói cách khác là STUN giúp ứng dụng biết địa chỉ IP, cổng của nó sử dụng khi đi ra Internet. STUN có thể được vận chuyển trên UDP, TCP hoặc TLS TURN (Traversal Using Relays around NAT), là một mở rộng (extension) của giao thức STUN, cung cấp media relay cho tình huống thực hiện hole punching(vượt qua) không thành công. Trong WebRTC, User Agent của trình duyệt sẽ bao gồm một TURN client. TURN server được cung cấp trên Internet qua các nhà cung cấp dịch vụ, hoặc có thể cài đặt trong mạng doanh nghiệp. Giao thức UDP được sử dụng để giao tiếp giữa TURN client và TURN server qua NAT. Cổng UDP mặc định cho TURN là 3478. Trên thực tế TURN server thường là STUN server có bổ sung tính năng relay. TURN server thì có chức năng STUN, nhưng không phải mọi STUN server đều có chức năng TURN JSEP (Javascript Session Establishment Protocol - Giao thức thiết lập phiên của Javascript): Thông tin về phiên gieo tiếp của người gọi, và người nhận UDP (User Datagram Protocol) là một trong những giao thức cốt lõi của giao thức TCP/IP. Dùng UDP, chương trình trên mạng máy tính có thể gửi những dữ liệu ngắn được gọi là datagram tới máy khác. UDP không cung cấp sự tin cậy và thứ tự truyền nhận mà TCP làm; các gói dữ liệu có thể đến không đúng thứ tự hoặc bị mất mà không có thông báo. Tuy nhiên UDP nhanh và hiệu quả hơn đối với các mục tiêu như kích thước nhỏ và yêu cầu khắt khe về thời gian. Do bản chất không trạng thái của nó nên nó hữu dụng đối với việc trả lời các truy vấn nhỏ với số lượng lớn người yêu cầu.