It's common in web applications to serve several small applications, combined through domain routing, to a user as a single service. I could have separate application for login, profile management, and chat being served as:
It's a trivial example, but it serves its purpose. To the user, it's one website, but for developers, it's several small applications. This comes with plenty of advantages that mostly boil down to having a small codebase.
I'm beginning mobile development (react-native) and wondering if this pattern has found it's way into that environment? My hunch is "no" due to the type of deliverable. A mobile application is delivered as one thing to an app store where a website can be "composed" through URL mapping, but I also know developers are smart and I could be totally wrong.
Top comments (1)
This is an interesting idea.
It's challenging on mobile because apps are sand-boxed. Downloading/installing an app is also more of a heavyweight operation than serving a web app and you have to drive engagement to install multiple apps. Android Instant apps tries to solve this problem by allowing users to download/install portions of an application on the fly in a more "web-like" fashion. Hard to say how Instant Apps will pan out yet though since they are still pretty new.
All that said, it's certainly possible today(at least on Android where I spend my time).
My last company, esri has taken an approach similar to this for their suite of mobile apps. Each app is still large on its own, but the functionality is very focused. A user could get by with a single app, or might need multiple apps to complete their daily work.
If you define a constant data scheme between applications, and then expose actions/data in the ways the framework provides (Intents, content providers, etc on Android) you could build an experience where each separate app handled a very specific use case then passed the user on to the next app.