In my previous blog. I discussed some In-build functionalities of ScalaGeek that makes it unique and flexible. Now In this blog, I will discuss the architecture and the tech stack that is used in ScalaGeek.
Technology Stack
In the ScalaGeek we have used five primary technologies for Back-end and two are used for front-end:
1. Scala
2. Akka
3. Kafka
4. Real-time database
5. Firestore
6. Angular 8
7. Ionic
Now I will discuss it one by one in detail.
Scala
We choose scala as the primary language. Scala is a pure functional language and object-oriented coding paradigms. Scala’s complex features promote better coding and offer a performance increase. Functions, macros, and tuples are just a few of the advancements Scala offers. It incorporates functional programming and object-oriented programming into a powerful language. It has a learning curve, and all developers know that it takes time to master a new language. Scala attempts to add to Java to make it more functional, and with this functionality, developers gain access to advanced features. Scala can be utilized to program, well, anything if performance is not an issue. The language is versatile, allowing it to be used to develop desktop software, games, web apps, mobile solutions, and software as an engine.
Akka
We used Akka because of concurrency. which is the ability of an algorithm or program to run more than one task at a time. The concept is similar to parallel processing, but with the possibility of many independent jobs doing different things at once rather than executing the same job.
That’s the reason Akka is mostly used for concurrency. Akka is a toolkit and runtime for building highly concurrent, distributed, and fault-tolerant applications on the JVM. Akka is written in Scala, with language bindings provided for both Scala and Java. Akka’s approach to handling concurrency is based on the Actor Model. In an actor-based system, everything is an actor, in much the same way that everything is an object in object-oriented design.
Kafka
we used Kafka to hold the data that is coming from different services. Kafka is often used in real-time streaming data architectures to provide real-time analytics. Learn its specific use cases and why it’s exploding in popularity. Kafka’s growth is exploding. More than one-third of all Fortune 500 companies use Kafka. These companies include the top ten travel companies, seven of the top ten banks, eight of the top ten insurance companies, nine of the top ten telecom companies, and much more. LinkedIn, Microsoft, and Netflix process four-comma messages a day with Kafka. You can read more about it from my Kafka blog. Kafka has higher throughput, reliability, and replication characteristics, which makes it applicable for things like tracking service calls (tracks every call) or tracking IoT sensor data where a traditional MOM might not be considered.
These companies include the top ten travel companies, seven of the top ten banks, eight of the top ten insurance companies, nine of the top ten telecom companies, and much more. LinkedIn, Microsoft, and Netflix process four-comma messages a day with Kafka. You can read more about from my Kafka blog. Kafka has higher throughput, reliability, and replication characteristics, which makes it applicable for things like tracking service calls (tracks every call) or tracking IoT sensor data where a traditional MOM might not be considered.
Firebase
You read about Firebase from Firebase Doc. Firebase makes ScalaGeek cost-efficient. Firebase provides an almost free database. Both Real-time and Firestore both are a good combination for the applications. It’s really very fast and responsive. Firebase provides a realtime database and backend as a service. The service provides application developers with an API that allows application data to be synchronized across clients and stored on Firebase’s cloud.
Architecture Diagram
Now I will discuss how we design architecture from these technologies. Now you have a basic understanding of these techs. I will explain every flow that is going on.
This is the detailed architecture of ScalaGeek. In this, we are using two databases. The first database is RDB which means a real-time database and the second one is CGS which means Cloud Firestore. I discussed more metadata in my previous blog. The second database Firestore is used for the content of the application. All the questions, answers, Hints and video links are stored in Firestore.
Engines
ScalaGeek has different engines. In ScalaGeek we have four engines:
1. MCQ Engine
2. Video Engine
3. Action Line Engine
4. Game Engine
MCQ Engine
MCQ Engine is being used for the MCQ pages. The content on the MCQ page is driven by the MCQ Engine. In this, we have two routes. The first route is GET. It basically hits requests to the Firestore for the MCQ questions. It requests the question Id and Firestore returns the question related to the id as a response. The second route is POST. This route sends the option selected by the user to validation. With the help of these routes, Firebase and front-end code interacts with the backend. In MCQ, the user has to answer right for each and every question otherwise stage will be failed. All the data is produced to Kafka topics
Video Engine
Video Engine is the simplest engine compared to the other engines. This engine has only one route to hit that is GET. This route hits requests to the Firestore and gets back with a video URL as a response. With the help of a URL, front-end can easily play the video. All the data is produced to Kafka topics
Action Line Engine
Action Line Engine is used for Hints. This Engine has two GET routes. One GET route hits request to get the action line and the second route is to get the answer respective to the question id. The validation for the action line is a bit tricky. our algorithm is very strong to get the confidence of both strings, the one that the user enters and the second one is the exact answer get from the route. If the user got less then 90% of confidence the stage will be failed. To pass the stage user have to score at least 90% or above confidence in the action line. All the data is produced to Kafka topics
Game Engine
Game Engine Engine is the brain of the whole app. All the calculations and logics are done in this Engine, but no other Engine is dependent on this Engine. Game Engine has only one route that is, the GET route. This route generates the session ID of each user. This session ID is unique for everyone. The Data is produced by other Engines in the Kafka topic.
This is all about the Architecture of ScalaGeek. In this way, we designed the Architecture.
Thank you for sticking to the end. If you like this blog, please do show your appreciation by giving thumbs-ups. Share this blog and give me a suggestion on how I can improve my future posts to suit your needs. Follow me to get updates on different technologies. For any queries, feel free to contact me at jashan.goyal@knoldus.com.
