How to Develop a Mobile App Architecture for E-Learning Project?

Before delivering any mobile app, they would go through multiple stages. One of those is developing a mobile app architecture – something that defines the ultimate success of the entire project.

 

While working on the app architecture, a team makes a set of decisions on:

• the structural elements and interfaces
• linking
• general styling of the project

Apparently, this brings a LOT of benefits. With the well-designed architecture, it’s easier to do modifications, tests, and debugging.

 

Today we will open up the way Fulcrum builds a mobile app architecture for the e-learning project based on our brightest KÖR case.

 

Before we proceed, it’s good to dive into a bit of theory. This helps to fully understand the value of architecture in app development.

 

What is the Architecture of an App

The architecture of an app is the process of transforming the software characteristics (flexibility, scalability, implementability, reusability, and security) into a structured solution that meets both technical and business requirements.

 

Simply put, architecture is a skeleton and a multi-level infrastructure of software.

 

Building the right mobile app architecture is paramount for the entire project. You can avoid most of the unwanted issues by paying due attention to:

• the quality of the code
• scalability of the system
• server API
• reliable technologies

There is a direct connection between architecture and constant debugging in the future.

Good architecture makes the process of app development and maintenance easier and more efficient. Software with a good architecture is easier to expand and change, and also to test, debug, and understand.

 

As a real example from our practice, we took KÖR – educational platform for drivers in Norway. At the pre-development stage, we had to define the type of product’s architecture.

 

Types of App Architecture

Mobile app architecture depends on the project tasks and relations between services:

• Monolithic & N-tier (multi-tier);
• Microservices (decoupled);
• Event-driven & service-oriented.

To define the correct architect type, you first determine the goals of your project. This is an important stage as you don’t want to adjust your app under the needs of the wrong chosen architecture.

 

For the KÖR project, we were choosing between Monolith or Microservices. After comparing these two architectures, their pros and cons, we settled up with Monolithic. Why?

Monolithic Architecture

The app components of a monolithic software combine into one program on one platform. Typically, a monolithic application consists of a database, a client user interface, and a server application. All software parts are unified and managed in one place.

 

Monolithic architecture is super convenient for small teams, especially startups. The components of monolithic software are interconnected and interdependent. It  helps the software to remain self-contained.

 

Monolithic Architecture PROs:

 

Simple development & deployment. You have many tools to simplify the development process. All actions are performed with one directory. Developers do not need to deploy changes or updates individually – they can do it right away and save plenty of time.

 

Fewer cross-cutting issues. Most apps rely on multiple cross-cutting tasks (audit trails, logging, rate-limiting). With Monolithic apps, it’s easier to address issues because of their common codebase.

 

Better performance. Monolithic apps tend to perform better than microservices-based ones. Monolithic apps enable faster communication between software components through shared code and memory.

 

Microservice architecture

Microservices architecture is used when the individual app tasks can be easily divided into small functions. These services can be written in different programming languages. They communicate with each other using REST APIs (JSON or Thrift).

Most often, microservices are launched in so-called containers. These containers are available over the network to other microservices and applications. The orchestration system manages them all.

 

Microservice architecture PROs:

 

Easy to scale applications. To implement a new function, all you’ve got to do is write a new service.

 

Clear division into modules. You’ll have no problems figuring out how the code actually works. And it’s very easy to add new features.

 

High availability. If any part of the monolith breaks, the entire application breaks. It is different with microservices. While some of the services may not work properly (not critical issues), the app will remain accessible.

 

Various technologies. As you design each service, you are free to choose the tools that best fit the specific business logic in that service. You may choose the optimal database and convenient tools for working with it. Microservice architecture also allows you to try some new technology.

 

Easy deployment. Each service goes independently, which makes the deployment and debugging process cleaner.

 

While all of the benefits sound great, microservice architecture indeed has a few challenges to face:

• Not easy to develop. If you need a quick solution (prototype, small application, or your deadline is tight), microservices are not for you. They require more time for development speed and cost more to pay for availability and modularity.
• Not easy management of databases and transactions.
• Not easy to test. Using a monolithic application, we only need to run the WAR / EAR / JAR archive on the server and make sure there is a connection to the database. As for microservices, to start any testing, you must launch each service individually.
• Not easy to support. Each microservice needs separate maintenance, which is why it’s necessary to set up automatic monitoring.

Let’s Compare: Microservice VS Monolith

Why We Chose Monolith Over Microservices

For the KÖR project, we chose the Monolith architecture for the next reasons:

 

Reason 1: We could not 100% define the data flow and service exchange of the future app. The Monolithic architecture type allowed us to set the deployment and then simply adjust one based on ongoing changes.

 

Reason 2: The KÖR’s development team was quite small. For the Monolithic architecture, it’s easier to deploy and set up CI/CD than for Microservices.

 

The Kör project team:

At Fulcrum Rocks, we allocate a team for each project individually. But in general, the team would include:

• Project Manager
• Business Analyst
• QA
• Tech Lead
• Developers

The clients hired Fulcrum Rock to develop the KÖR app as a dedicated team. Dedicated teams are the best decision for:

• Long-term projects (4+ months)
• 100% engagement of the entire team
• Direct participation in the project (client will take part in sync ups & retrospectives)
• Fully-involved communication
• Flexible budgets and functionality (in case the client decides to scale up)

Reason 3: The app’s load wasn’t too high. It was the first iteration and not many users were expected. Monolith is a perfect solution for not-so-high loads.

 

Reason 4: Monolithic app architecture and maintenance costs are much lower, while the process remains easier.

 

Did you know, such well-known giants as Netflix, Amazon.com, and eBay used to start from a monolithic architecture? Most of the web apps developed by the author followed the monolith path too.

 

It always makes sense to start with an MVP, launch a project, and get the first feedback. For such cases, monolithic architecture works best.

 

Fulcrum Rocks – We Help Develop Apps!

The stage of developing an app architecture is a part of the Fulcrum Discovery stage (click to view the presentation). The purpose of the Discovery phase is to make research and plan the project to its tiniest detail.

 

Along with the KÖR project, Fulcrum designed architectures for each of our other projects.

 

It’s worth noting that Fulcrum is a full-cycle app development agency. So far, we have developed 15+ small and large-scale apps for clients worldwide. Among them:

• Buff – an app for a popular loyalty program for gamers;
• Hyfa – a social app for discovering, curating & sharing products and experiences;
• Sync.ai – a toolkit of apps for scheduling meetings, organizing events, and arranging business calls;
• FoodTrucks – a full-fledged delivery app for ordering food;

We are ready to take over ALL stages of app development, from research and planning to branding and technical support.

 

Why Fulcrum Rocks?

• We develop apps of all complexity;
• Ready to integrate with any accounting system & services;
• We are accountable for the final result, hence interested to do our best at each stage;
• We are ready to scale up and optimize your project in the future;

 

FAQ: Mobile App Architecture