Admin/Pro vs Normal user|| System design || iOS

Admin vs Normal user

• In a application, an admin (administrator) user has higher privileges and permissions compared to a normal user.
• Admin user is authorized to perform actions that can affect the system as a whole.
• A normal user is restricted in terms of their access and permissions.
• Normal user has restricted permission to view the content
• Admin user can add/remove another users

Why there is concept of admin or normal user vs unassigned user?

• Whenever end user open the applications for first time, there is high chances that he want to explore applications and see the features that might help him to complete his job.
• You want to showcase minimal feature to accomplished by normal user
• Admin user has additional benefit .
• Subscription-Based App like Hotstar, JioCinema , Netflix, Shadhi.com, Tinder, Fitness give privilege to view premium content.
• Based on userType application show different type of content in the applications

What we are going to solve ?

• How application can handle different kinds of users?
• Show different screen layout based on user type?
• Different kind of actions based on user type?
• Run time change in user permission?
• Security mechanism to prevent attacker to change user type?
• Update in user type when application is in background mode?
• Analytics
• Data encryption
• Man in the middle attack

Challenges faced by Mobile developer ?

• Reset UI after change in user type.
• Update button text dynamically based on user type
• Check user type permission in run time.
• Different action based on user type.
• Show different kinds of layout/screen based on user type.
• Performance

Let’s start from User flow for subscription based application:-

What are the ways we can know user type ?

getUserInfo

• Short polling mechanism
• Long polling mechanism
• Websocket mechanism
• SSE mechanism
• Before every new screen render
• After first time launch
• Moving from background to foreground
• Silent Notification
• API Interceptor*

What are the information that we can get from getUserInfo API ?

{
  "userId": "uyufgfeytrmkjhk",
  "userName": "Shrawan",
  "email": "shrawan@gmail.com",
  "firstName": "Shrawan",
  "lastName": "Shrawan",
  "profilePicture": "https://aws.server1.com/profile-picture.jpg",
 
   "role": "user",
  
  "subscription": {
    "level": "premium",
    "paymentMethod": "creditCard",
    "status": "active",
    "expirationDate": "2023-06-30"
  },
  
  "registrationDate": "2022-01-01",
  "lastLoginDate": "2022-04-19",
  "preferences": {
    "theme": "dark",
    "notifications": {
      "email": true,
      "push": false,
      "sms": true
    }
  },
  "activity": {
    "loginCount": 5,
    "lastLoginIP": "192.168.0.1",
    "lastActivityDate": "2022-04-18"
  }
}

Currently we are focused to role and subscription data. Based on it, we will be showing different layout/features in the screen.

  "role": "user",
  "subscription": {
    "level": "premium",
    "paymentMethod": "creditCard",
    "status": "active",
    "expirationDate": "2023-06-30"
  },

Before moving to UI part to show different UI Configuration, let’s short out mechanism which we can use to pull out user info in our application .

• Short polling mechanism :-

Short polling is a client-server communication mechanism in which the client regularly sends requests to the server at a fixed interval to check for updates or new data.

For our use case role & subscription data won’t be updated frequently in getUserInfo API. So using Short polling will be resource-intensive, as it requires the client to constantly send requests to the server, even if there is no new data available.

• Long polling mechanism

Long polling is a client-server communication mechanism that allows the server to push data to the client as soon as it becomes available, rather than waiting for the client to make a request for data.

For our use case role & subscription data won’t be updated frequently in getUserInfo API. So using long polling can be resource-intensive for both the client and server, as it requires an open connection between the two for extended periods of time

• Web socket mechanism

WebSockets is a client-server communication mechanism that enables real-time, bi-directional communication between a client (such as a web browser or a mobile app) and a server. WebSockets provide a more efficient and reliable alternative to traditional HTTP-based communication, as they eliminate the need for the client to repeatedly poll the server for new data.

Again same story. Data won’t be updated frequently so we will not go with web socket.

• SSE mechanism

Server-Sent Events (SSE) is a server push technology that enables a server to send real-time updates to the client over a single HTTP connection

We will be using SSE when we start subscription process. After subscribing to the plan/converting from normal user to pro user, application need server validation to get updated getUserInfo. Sometimes payment process take some time, instead of going to short polling mechanism which will consume a lot of resource, we will be using SSE.

SSE is particularly useful for applications that require real-time updates. After getting real time updates, we will close the connection.

• Before every new screen render

It is not a good practice to call getUserInfo every time before moving to new screen.

• After first time launch

It is good place to call getUserInfo before showing home screen. We won’t be calling getUserInfo in launchscreen. Instead we will be creating intermediate screen between homescreen and launchscreen.

• Moving from background to foreground

What will happen if end user subscribe to Netflix using website and move back to Netflix application ? If we won’t check getUserInfo then end user won’t be using premium feature and might get confused.

• API Interceptor*

What will happen if end user permission changed, user get blocked, subscription plan cancel/Update while using application ?

For that Backend will play critical role. If anything get changed in the backend related to subscription/user profile data then they can use 2 technique:-

- Send “xxx” status code in the api response.
- Expire the access token.

In both the cases, frontend can intercept and can easily get updated getUserInfo.

Conclusion

We will be using SSE mechanism , After first time launch, Moving from background to foreground, API Interceptor to get updated data from getUserInfo

Second part will be coming soon

Let’s hope you enjoyed first part of Admin/Pro/Subscriber vs Normal user || System design || iOS.

SOLID Principles Analogy + Swift