Hỏi vui về góc nhìn: Làm product bằng mobile app và web app

  1. Đọc đâu đó user dành hầu hết thời gian cho mobile app hơn là dí mắt vào website. Cho nên mobile app đang là xu thế. Kể cả game gủng cũng đã phát triển phiên bản mobile rất nhiều. Thằng Riot cố chấp nhưng cũng phải phát triển Wild rift để hút thêm người chơi. Vậy làm product(nhỏ đến vừa) thì mobile app có lợi thế và cần thiết không?

  2. Ai phát triển mobile thì mới biết làm front-end của app mobile không “đơn giản là chỉ làm front-end”(ring-3 app). Vậy transfer cho web có khó khăn gì không. Codebase của mobile còn dễ đọc chán. Rất hệ thống. Nhìn sang ông web thấy rất nản(“ring-4 app”). Dùng template phát triển nhanh cho product có hiệu quả và bớt tốn sức khi transfer qua không?

Thống này đúng, nếu web có gắn các tool Analytics như Google Analytics, Ahrefs, SimilarWeb sẽ thấy hơn 90% traffic là thiết bị di động, còn lại là tablet và desktop. Nhưng nó chỉ đúng với các sản phẩm hướng đến khách hàng cá nhân ví dụ web hoặc app đặt vé xem phim, shopping, web đặt thức ăn, web xem phim, nghe nhạc; nói chung là các thể loại giải trí, truyền thông trên không gian mạng, chính xác hơn là B2C hoặc C2C.
Chắc bạn chưa tiếp xúc nhiều với các thể loại web doanh nghiệp. Đối với các web ERP, CRM, HRM, … thì ngược lại, 99% là desktop, hoàn toàn không có khái niệm “mobile first”, một số hệ thống quản trị trị vẫn có app nhưng rất hạn chế tính năng, hầu hết là để duyệt request, xem overview, nhận thông báo (push notifications).

Quan điểm này đúng, nếu cty quy mô nhỏ chỉ có thể làm game mobile vì market share mảng mobile lớn, game trên desktop kén user, các game AAA thì không bàn tới vì đây là phạm trù khác rồi.

Mobile app luôn là lợi thế, nhưng để đưa app lên các store thì không dễ, không phải loại app cũng được publish lên store, một số app đặc thù liên quan đến network, tài chính, sức khoẻ, … bắt buộc phải đăng ký doanh nghiệp mới cho publish app. Chưa kể đến những dịch vụ thuộc “vùng xám” thì làm sao kinh doanh bằng app được.

Vẫn như ở trên, tùy nghiệp vụ kinh doanh, bạn làm app gọi xe cần truy cập GPS và các cảm biến của thiết bị thì giữa app và web cái nào hiệu quả hơn? App tài chính cần định danh user, cần truy cập sâu vào thiết bị thì bạn cũng đã biết câu trả lời rồi.

Phần này chẳng có cái nào đúng. Để làm app có rất nhiều ngôn ngữ, kotlin, swift, dart, js, C#. Chỉ riêng JS cũng có rất nhiều framework như react native, cordova, ionic, app của Huawei cũng viết bằng JS, ngay cả chính react native cũng có đến 3 trường phái: react native thuần túy, expo, vừa react native vừa native code.

Lời khuyên của mình là bạn nên tìm hiểu kỹ từng công nghệ, xem nó áp dụng vào trường hợp nào. Mỗi công nghệ là một công cụ giải quyết một vấn đề riêng.

3 Likes

Thanks. Nhưng mà phần cuối bạn bị lạc đề rồi

Bạn có thể cho mình biết bạn đang định nghĩa 2 từ lóng này là gì không?

Ý bạn là boilerplate hay cross platform? Viết 1 lần chạy everywhere?!

Codebase thì tùy vào framework chứ, mỗi framework tác giả đặt ra một rule code riêng thì sao mà sao sánh được. App thì có nhiều loại app

  • app thuần CRUD như các app thuộc todo list, notepad hoặc app ERP
  • những loại app đặc thù cần phần cứng điện thoại như định vị, cảm biến gia tốc, cảm biến ánh sáng, camera, … như app giao hàng, bản đồ.
  • Game thì cũng là app
    Mỗi app có cách tổ chức thư mục và rule code khác nhau hoàn toàn. Bạn bảo codebase dễ đọc thì rất phi lý vì có người master dạng app ERP nhưng làm game thì không được, có người làm game mobile rất giỏi nhưng code app chỉ có vài form đăng ký đăng nhập như app tìm nhà trọ lại không làm được.

Có thể do bạn “gà” hoặc chỉ nghe kể chứ chưa trải nghiệm. Web lại có nhiều trường phái:

  • Landing page dành cho chạy ads hoặc dùng cho sự kiện. Dạng web này full CSS
  • web để SEO phần lớn là WordPress, ngoài ra còn có nextJS, nuxtJS cho ai có vốn lớn và nhiều thời gian.
  • web client side như react, angular, vueJS dành cho các trang web không cần SEO hoặc các page sau màn hình login, các web ERP
  • các web chuyên webworker, web webassembly như các web chỉnh sửa ảnh online lại là phạm trù khác nữa.

Không biết cụ thể transfer của bạn là gì? Như mình đã nói ở trên nếu muốn build nhanh viết 1 lần chạy nhiều nền tảng đã có react, reactJS có thể share logic chung giữa app và web. Viết 1 lần chạy được cả web, android, IOS. Tương tự có ionic và Cordova có thể dùng dung source code giữa web và mobile tới 70-80%.

Bạn nên nhớ người ta hiểu “bản chất” để giải thích 'hiện tượng", chứ không ai thấy vài 'hiện tượng" trước mắt rồi kết luận “bản chất”, nếu bạn có code OOP cũng hiểu class và instance.

Mình viết dài vì bạn còn khá mơ hồ ở bước lựa chọn công nghệ nhưng viết bài giọng điệu mỉa mai các khía cạnh trong lập trình.

Thường những chủ đề liên quan benchmark ngôn ngữ, so sánh framework, so sánh web app, so sánh android, ios, samsung vs apple, windows vs macos, … đều không có hồi kết đa phần đều do dev chưa hiểu chức năng của từng công nghệ mà chỉ cưỡi ngựa xem hoa sau đó nghĩ mình đã am hiểu và bắt đầu so sánh.

2 Likes

Để mình ví dụ 1 trường hợp cụ thể nếu không lại bảo nói điêu:
Ví dụ khách hàng yêu cầu làm app thuê 30 phòng trọ ở HCM.
Phân tích nhanh:
Hệ thống sẽ có 4 đối tượng sử dụng

  • App cho khách thuê (android/iOS)
  • Web cho khách thuê (web responsive mobile & desktop)
  • web admin cho chủ trọ quản lý
  • app admin cho chủ trọ nếu có yêu cầu thêm.

Ví dụ như list phòng trọ. Nếu component này được viết bằng reactJS và tailwindCSS thì 95% code ở cả 4 gạch đầu dòng trên y hệt nhau. Thậm chỉ nếu khách yêu cầu viết thêm app desktop cài được cho cả windows và macos thì vẫn có thể tận dụng lại code cũ.

Vậy theo bạn như này đã đủ “transfer” chưa.

Còn nếu “transfer” hiểu theo nghĩa người cũ đang code rồi nghỉ việc “transfer” cho người mới thì vấn đề này cần cả 2 tuân thủ theo rule của framework đang dùng thôi.

Còn nếu bạn hiểu “transfer” theo nghĩa port app ví dụ app VPN mà muốn port sang phiên bản web thì mình xin thua.

Lóng gì bạn =). Từ chuyên ngành mà. Không cần phải xù lông lên đâu. Giải thích đơn giản “từ lóng”: Web browser parse và xử lý HTML, CSS, JS nên môi trường web khác xa so với ring-3(App sử dựng trực tiếp service của hệ điều hành). Hiểu lầm thôi. Đừng nhạy cảm quá ạ ^^

Bạn có chắc không, mình google cả 2 từ đó mà không thấy trang nào đề cập, không biết bạn học được từ nguồn nào.

Hồi mình còn sinh viên năm 4 đi cafe với ông bạn, thấy ổng đọc quyển C++ dày cộp (sách tiếng Việt) mượn thư viện. Rồi ổng hỏi mình biết “lớp chứa” trong C++ là gì không. Mình đứng hình luôn vì chưa nghe bao giờ, sau mới biết nó còn có tên khác là “container class”.

=)). Ring-3 mà google không ra thì chắc wifi nhà bạn bị hỏng rồi. Ba lớp phân quyền của OS classic vậy mà còn nguồn nào nữa trời. Chả lẽ quăng link ở đây quê lắm chứ đùa.

Chắc trên núi mới xuống :sweat_smile: Đưa cái dẫn chứng biết ngay học chưa tới, lấy khái niệm cấp độ kiến trúc CPU bàn về app mobile và web chạy trên browser. Nếu như topic bạn hỏi về so sánh Vmware với promox, KVM, LXC, Docker, … thì còn tí liên quan.
Cái này mới chí mạng: 99% thiết bị cầm tay chỉ sử dụng CPU ARM, mà ARM không liên quan đến “ring” gì cả. “ring” chỉ dành cho kiến trúc x86 thôi.

Thiết bị di động dùng SoC Snapdragon, Apple silicon, samsung dùng CPU Exynos, … toàn là ARM làm gì có khái niệm ring trong OS.

Bạn biết vì sao trong ảnh bạn gửi, người ta lấy ví dụ CPU AMD không, vì AMD dùng x86 đấy =)))

2 Likes

:)). Có thể hiểu tổng quát ring là phân quyền dùng tài nguyên không? :)). App trên android dùng được bao tài nguyên của hệ thống mà không phải dùng ring? Hay phải viết ring-3-equivalent để vừa lòng “chiên gia”. Mình không phải chuyên gia như bạn nhưng chí ít hiểu rõ phân quyền app trên browser chả bao giờ cao hơn app native được. Ai học chưa tới nhỉ? :wink:

Cái thứ hai: “lấy khái niệm cấp độ kiến trúc CPU để bàn app mobile và web chạy trên browser”. Why not? Bạn tính xây app mà không quan tâm vòng đời, không quan tâm phân quyền tài nguyên bạn cho phép dùng à? Ý mình hỏi tính liên quan của phân quyền đối với việc xây codebase.

Mời bạn đưa ra ví dụ về việc web cần sử dụng nhiều tài nguyên CPU. Xin hỏi bạn trên thế giới này web nào cần nhiều CPU máy để hoạt động? Web xin quyền camera, micro, GPS của Browser đã là hiếm rồi. Bạn vẫn chưa hiểu mục đích của web và khi nào dùng web :sweat_smile: lý do Adobe làm app Photoshop trên máy tính và điện thoại mà không có phiên bản web đấy. Bàn luận về vấn gì cho thực tế chút đi bạn. Ví dụ về chính diễn dàn daynhauhoc.com này, mỗi khi user truy cập qua trình duyệt thì OS cấp 1 phần tài nguyên cho Browser đủ render ra page tin tức này cho user đọc là đủ rồi.

Cũng có lý. Nhưng chưa đủ. Bạn tham khảo được ý kiến của mình được thì tốt. Không thì không sao. Ai rảnh đi tranh cãi mấy cái này. Bắt bẻ linh tinh, cứng nhắc nên phải nói thôi. :wink: Dùng tài nguyên phải hỏi ai, ai trực tiếp cấp SDK thì +1 phân quyền thôi. Có gì phải bàn cãi.

Có vẻ bạn không có kinh nghiệm làm software. Việc xây app/web nằm ở tầng high level, chủ yếu tương tác với API/SDK do browser/platform cung cấp. Còn khái niệm “ring” của bạn lại rất low level và chỉ gói gọn trong context CPU thôi, thực tế làm app không ai đụng đến.

3 Likes

@tonghoangvu
You’re right. It’s a matter of knowledge that can only be acquired in computer science. The partitioning of applications has nothing to do with software development; it’s an architectural model that is individual and dependent on the developers. The so-called ring is nothing more than a layer. For example, the Internet is based on TCP/IP and is modeled in four layers:

  • Application layer: HTTP, HTTPS, FTP, SNMP, etc.
  • Transport layer: TCP, UDP
  • Internet layer: IP (e.g., IP4, IP6)
  • Physical layer: Ethernet, WLAN, etc.

The same is modeled differently by OSI (Open System Interconnection), for example:

  • Application layer: HTTP, HTTPS, etc.
  • Presentation layer: HTML, JSON
  • Session layer: e.g., network file system
  • Transport layer: TCP, UDP
  • Network layer: IP (e.g., IP4, IP6)
  • Data connection: e.g., Ethernet, WLAN
  • Physical layer: Fiber optic cable, Bluetooth, etc.
1 Like

@anonymous288
=)). Ring-3 mà google không ra thì chắc wifi nhà bạn bị hỏng rồi.

@anonymous288
:)). Có thể hiểu tổng quát ring là phân quyền dùng tài nguyên không? :)). App trên android dùng được bao tài nguyên của hệ thống mà không phải dùng ring?

Cái thứ hai: “lấy khái niệm cấp độ kiến trúc CPU để bàn app mobile và web chạy trên browser”. Why not?

I think you’re confusing operating system development with application development via interfaces to the operating system, which are usually APIs. As @tonghoangvu already pointed out:

Còn khái niệm “ring” của bạn lại rất low level và chỉ gói gọn trong context CPU thôi, thực tế làm app không ai đụng đến.

Direct access to your mentioned RING (at any level) means access to the operating system. This can be done via operating system commands or, more deeply, via C-to-assembly and then via SVCs (supervisor calls), which give you (in)direct access to the hardware or privileged mode (superuser). From the perspective of an app, web, or smartphone app, direct access to the hardware/privileges is not possible, but only via special APIs. For example, in Java or C/C++, you can run “exec” to execute an OS command to access certain operating system services .

Như thế này: Chúng ta có một khái niệm tên là Isomorphism. Đây là cách suy luận nội suy từ các tính chất tương đương giữa 2 hai khái niệm trừu tượng.

Anyway, cái phía trên có thể làm @TranMinhHoang nghĩ @anonymous288 lại nói kiến thức ở trên núi xuống :)). Nhưng thực tình là vì nhiều khái niệm CS có tính chồng lấp nên có khi nên hiểu “lỏng lẻo” một chút. Chả ai đi nói lợn và heo hoàn toàn khác nhau cả.

Web bị giới hạn resource và chỉ tương tác với DOM và thực hiện HTTP request(roughly). Tài nguyên mà được cho phép truy cập cực kì ít vì lý do bảo mật + nhu cầu sử dụng để thực hiện tác vụ. Web app không làm gì hơn ngoài ngáp đợi API của Bờ-rao-giơ để truy cập tài nguyên. Cái này ảnh hưởng đến codebase chứ sao không?

Program = Data structure + Algorithm.

80% thời gian làm software không ai nghĩ về “ring”(isomorphic to “PHÂN QUYỀN TÀI NGUYÊN”); 20% còn lại là nghĩ về nó VL. Nếu chỉ có 3-bit dữ liệu để tương tác thì codebase khéo chỉ cần 20 dòng để thực hiện tập tác vụ nó cho phép. Thân gửi 3 chuyên gia phía trên :wink:

Thực ra khi làm software thì 99.9% không ai dùng khái niệm Ring cả vì về cơ bản tất cả đều dựa trên API và SDK có sẵn, chỉ là API và SDK do ai cung cấp OS hoặc VM (VM ở đây là runtime trên nền OS). Vì không ai dùng nên rất nhiều người sẽ không hiểu bạn nói gì là bình thường trừ khi họ cũng đã học và làm qua về phần OS (Thậm chí như một bạn trên có thắc mắc, Ring nó còn thậm chí không phải từ lóng trong ngành mà phải dựa vào context cụ thể)

4 Likes

Perhaps there’s a misunderstanding here, and @anonymous288 didn’t clearly express his opinion in his posts.
I suspect @anonymous288 meant that software development should always consider the operating system aspect (which he unfortunately referred to as the RING). If so, he was right. A running app doesn’t mean it’s complete or perfect. However, it should be checked whether the app is running optimally or whether optimizations still need to be made to improve performance or throughput. This approach refers to the operating system, which includes access details to hardware such as the CPU, disks, etc. An unoptimized loop can completely exhaust the CPU. Unoptimized disk access can bring the system to a halt. This is even more true when an app is developed without considering the operating system.
And this requires a deep understanding and knowledge of the operating system—or the RING.

muốn nhanh thì dùng no code để build app, vd: google appsheet, microsoft power apps,… còn khi nào có đủ nhân lực, thời gian thì build code.

Đây chính là lý do web không thể truy cập sâu vào hệ thống, chính bạn cũng đã nhận ra điều đó!

Để publish một app android lên Google Play không phải đơn giản như post một bài viết Facebook hoặc upload một video lên Youtube. Publish được 1 app phải khai báo 77 49 bước không khác gì khai báo hải quan. Google thì không dễ qua mặt, không phải được Google duyệt lần đầu là xong, Google vẫn check định kỳ và monitor app thường xuyên ngay chính thiết bị end user, nếu app có các hoạt động bất thường hoặc truy cập quá sâu vào thiết bị cũng bị chú ý. Android 16 và các phiên bản android về sau rất hạn chế app chạy backround và truy cập sâu vào OS, Android cung cấp API nào thì app dùng API đó thôi, nguyên nhân cũng xoay quanh vấn đề bảo mật và tiết kiệm pin. Những bài viết với tiêu đề “Google gỡ hàng triệu app trên Google Play Store trong quý X năm Y” chưa bao giờ hết hot. Google Play đã làm gắt kiểm duyệt app như vậy thì Apple cứ x10 lên, không phải tự nhiên mà Apple thu 100USD/năm (300USD/năm đối với doanh nghiệp) để duy trì app trên Apple Store. Còn trên Windows dễ thở hơn chút nhưng cũng không phải thích làm gì cũng được, để Windows không thông báo file không rõ nguồn gốc và Windows Defender không cảnh báo virus thì bạn cũng phải làm “giấy khai sinh cho app”.

Vấn đề mấu chốt là ở đây:
Không biết bạn làm app gì mà API của OS vẫn không đủ dùng, cần phải truy cập sâu đến context CPU mà dùng đến khái niệm RING

Web khác app ở chỗ là nó tự do, chỉ cần đăng ký cái domain là xong, tự động đăng ký ICANN. Chỉ những trường hợp nặng như phishing, có người report thì nhà cung cấp mới thu hồi domain. Chắc bạn cũng biết việc ISP Việt Nam chặn domain, các web vi phạm pháp luật không thể gỡ được do đăng ký domain tại nước ngoài, mà chủ đề 18+, cờ bạc, chính trị, … không vị phạm policy của nhà cung cấp, nhà cung cấp thì ưu tiên bảo vệ quyền lợi khách hàng. Thậm chí web virus, trojan vẫn tồn tại rất nhiều mà không bị gỡ lý do là không có tổ chức nào rảnh đến mức kiểm duyệt toàn bộ internet, để tạo ra một web virus và phát tán cực kỳ dễ, nó tồn tại cho đến khi có người report. Browser không giới hạn quyền của web thì có mà loạn. Chưa bàn đến việc web có truy cập được tới những nơi liên quan đến “RING” hay không, cho web tự do truy cập ổ đĩa C của user cũng đủ loạn thiên hạ rồi. Ừ thì nếu cố chấp bảo “chỉ cần có tổ chức xét duyệt là được” thì chắc bạn chưa biết để một app android tới tay người dùng cần mất tối thiểu 14 ngày qua nhiều vòng kiểm duyệt, app cần ít nhất 12 tester cài app và giữ app trong 14 ngày, sau đó mới đến các vòng kiểm duyệt của google. Nếu áp dụng quy trình này sang web thì chắc bị ăn gạch đá, rồi tổ chức nào đảm bảo trung lập để kiểm duyệt, web cần release nhanh, ai đủ kiên nhẫn để chờ kiểm duyệt các ngày săn sale, black friday.

App và web vẫn tồn tại song song từ xưa đến giờ, tùy vào cách thiết kế hệ thống thôi, tại sao end user có thể tiếp cận được AI trên mọi thiết bị, thì web chỉ là phần giao diện (frontend) thôi, AI nó run ở server, mà đã là server thì code gì chẳng được, bạn ép xung CPU còn được nói chi là ring 1 ring 2 ring 3. Adobe vừa có version web vừa có version app đó thây, user có PC cấu hình mạnh GPU khỏe thì dùng app để tận dụng sức mạnh phần cứng, còn PC yếu thì dùng cloud đóng tiền theo subscription plan như firefly.adobe.com.
Còn bạn nhìn web thấy mỗi cái giao diện

mà không biết web có frontend, backend thì không còn gì để nói. Để tạo web chỉ có DOM thì đầy nơi cho host free, chỉ tốn tiền mỗi cái domain. Thế những cty cho thuê VPS hít khí trời sống à.

vậy theo bạn web thực hiện http request đi đâu? thì đi đến backend xử lý đấy. Backend nếu bạn dùng linux thì bạn sửa luôn kernel còn được. Nếu web có mỗi DOM và http thì thế giới có JS client side được rồi chứ tạo ra các công nghệ server side như nodejs, ASP, laravel, java, go, … để làm gì nữa.

Thế giới bây giờ đang dùng cloud đó thây, bạn lưu file ở google drive, S3, code lưu ở git, … bạn có thể nối chúng lại với qua API đấy. Thế bạn chưa thấy các hệ thống bán hàng đa kênh à, đồng bộ dữ liệu từ shopee, lazada tới tiktok, facebook cho đến app ngân hàng, hệ thống kế toán. Thậm chí có những thiết bị nhìn trông giống PC nhưng thật ra chỉ mở được đúng tab chrome để quản lý mọi thứ trên cloud, không màn hình desktop, không list icon app.

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?