Warning: This article contains a lot of information about programming and tech terminology. There will be no mentions of gothic or baroque styles though, it’s not that kind of architecture.
To put it simply, mobile app architecture is a set of techniques and patterns which help developers to create a well-structured application.
At Crypterium we’re building a very complex mobile app that lets users pay with cryptocurrency with the same ease as with cash and cards. Still, we want our users to understand how everything works behind the scene. And we’ll try to keep it as simple as possible so that you’d finally understand how the apps you’re using every day are built.
Front and Back Explained
You’ve probably heard that application architecture is rather different on front and back end, but nobody really explains what it means. Let’s get away from technical terms and make an analogy with everyday life.
Take a look at your own body. Everything on the outside, like your head and body, is “front”, while everything on the inside, like your heart, brain, and internal organs, is a part of your “back.”
We are building a payments application, and while our backend team develops services ensuring all the exchanges, transfers, storing data, etc., our front-enders make sure that all these complicated operations are shown to the app users in a user-friendly and easily understandable way.
Key principles of developing an agile app
Once we understood the difference between the front and back, let’s also puzzle out two key principles that the most progressive developers use in their work today — API First and Loose Coupling. These are contemporary techniques that let you develop a modern application that can be easily improved. Additionally, any separate part of an app can be independently enhanced without the need to change the other parts.
API first method values high speed and novelties above everything else. The idea is simple: you enter key source data and get an API, on top of which back end and front end teams write their codes in parallel, while the testers simultaneously prepare the testing. The benefits of this approach include reducing the cost of developing, increasing the speed, and minimizing the risk of failure.
Here’s an analogy from everyday life: when you are cooking bolognese, you don’t make pasta first and then the sauce, you do everything in parallel. This way you get delicious food faster, nothing gets cold, and your friends can test the results based on what they’ve expected.
One of the features we use within our API-first method is called Swagger (not to be confused with a trend that was popular in hip-hop in 2015 or the urban dictionary’s description). Swagger is an open-source software framework that helps developers build, architect, document and design services. Swagger tooling automatically generates API description for most languages and frameworks for front and back.
The second principle is called Loose Coupling. The situation when your date cancels on you on Valentine’s day is not loose coupling, quite the opposite, in computing and systems design loose coupling means interconnecting the components in a network.
Loose Coupling refers to the degree of direct knowledge that one of the system’s elements has of the other, these elements depend on each other to the least extent possible. The goal is to reduce the risk that a change made within any element will create changes within other elements as well. Limiting interconnections can help isolate and identify problems when things go wrong thus simplifying testing and maintenance.
Microservices vs Monolith
Thanks to API First and Loose Coupling principles, Crypterium runs its app on Microservices. The whole app is made of independent services capable of running on their own memory space and scaling freely from each other across many separate machines.
Microservice architectures are better organized since each microservice has a specific job. Decoupled services are also easier to reconfigure and recompose to serve the purposes of different apps. Additionally, they are characterized by fast deployment, fault tolerance, horizontal scaling, low entry level for teams, small team development and ease of management.
Imagine a smart house, where everything can be controlled and managed via one device. This device is *core*, while controllable elements are *services*. With the core device, you can open windows, turn on the TV or even close curtains. This is basically how microservices architecture works.
But there’s always another option, right? The second type of architecture is the monolithic architecture. This means that an application is written as one unit of code whose components are designed to work together, sharing the same resources and memory space. Services in this kind of apps are closely connected, and you would have problems changing one of them without interfering with the others. Imagine an amazing 12 layer Chocolate cake. Layers might make this cake 12x times tastier, but you can’t change one of the layers without ruining the whole cake. This is basically what Monolith Architecture is.
.NET Core vs JVM platforms
Multifunctional applications, like mobile wallets, usually have hundreds of different services. To make the work more structured, at Crypterium, we have decided to split our back-end developers to 2 different teams. One team works solely on the core products, and the other team works on everything else (authorization, communication etc.)
Each of those teams use their own framework. The “Core team” works on .NET Core more. This platform is characterized by fast development, deployment, and testing. Additionally, the main advantages include high performance, suitability for cross-platform needs and targeting microservices. Meanwhile, the additional services are developed in JVM framework, the main competitor of .NetCore supported by Oracle.
Having two of the most popular frameworks allows us to hire developers who are used to different programming languages. For .NET Core, we use C Sharp Programming languages, while for JVM we use Kotlin and Java. Besides, the languages used in are the same ones our FrontEnd team uses for our Android app.
Front End Explained
The front team makes sure that the app is user-friendly and the interface is readable, controllable and understandable for everyone. We have an app on iOS for iPhone users and on Android for other smartphone users.
The Android version of the Crypterium App is based on Java and Kotlin languages (just like JVM framework), while the iOS app is based on the new, easy-to-use programming language called Swift. Swift was created by Apple and fits perfectly on iPhone and/or MacOS. Features include access control, memory management, debugging, chaining and protocol-oriented programming.
MVVM and Routing style for iOS
Crypterium’s iOS Developer team chose MVVM and Routing style of architectures. These architectures are both user and developer-friendly, additionally, they are very structured.
MVVM stands for Model-View-ViewModel where Model means information about the product, and View shows how customers see the product. There is a layer-type structure in MVVM: the first layer stands for UI (user interface). Other layers include network services and logic services. Meanwhile, the Routing is responsible for transitions behind the screens, determining the customer journey. Where user goes and what he/she sees by clicking any buttons is regulated by Routing.
Let’s analyze an example where a user wants to send his crypto to another address. Network services layer holds an information about the amount of sent crypto and the address. When the user confirms the transaction, the logic services layer checks if there is enough cryptocurrency for transfer and provides the user with a positive or negative answer.
Clean Architecture for Android
In order to increase the easiness of maintenance and flexibility of our applications, our Android team decided to use the method called “Clean Architecture”. This method makes sure that unnecessary coupling is non-existent and makes the App more testable.
The outcome is a clean, new, fresh, easy-to-use app for Android with 4 layers, from the top to bottom: a mobile device (or web, database, UI), controllers (gateways, presenters), use cases and entities.
Conclusion
Application architecture is a very complex topic and everything that is written above is just the tip of an iceberg. However, the good news is that we will continue looking into this and other relevant topics and post more often about the technical part of our product.
About Crypterium
CCrypterium is building a mobile app that will turn cryptocurrencies into money that you can spend with the same ease as cash. Shop around the world and pay with your coins and tokens at any NFC terminal, or via scanning the QR codes. Make purchases in online stores, pay your bills, or just send money across borders in seconds, reliably and for a fraction of a penny.
Join our Telegram news channel or other social media to stay updated!
Website ๏ Telegram ๏ Facebook ๏ Twitter ๏ BitcoinTalk ๏ Reddit ๏ YouTube ๏ LinkedIn