🌌 Jamku Technology Stack

As a leader in Practice management software, we often get questions like

1. Will Jamku become slow when there are many users using the software at the time time?
2. How come Jamku is so fast, when other software so slow?
3. Jamku is built on which technology?
4. How is data protected in Jamku?
5. What kind of encryption is used?
6. If a server goes down, how much time will be required to get it back?

This blog post attempts to answer these questions and explain the technology used in Jamku. We also hope that sharing our technology stack will help the Practice Management Software industry as a whole become more mature.

Table of content

• Overall Architecture
• API Tech Stack
• Database Tech
• UI Tech
• Monitoring Tech

Overall Architecture

Key considerations for deciding overall architecture

1. Modular - Helps in maintaining the software as it evolves without breaking other stuff
2. Cost Effective - Jamku market segment has high price sensitivity, hence being cost effective is a must
3. Simplicity - Wherever possible use existing service than reinventing the wheel. This make the software development cycle short and builds on rock solid security and industry best practices.
4. Managed Dev ops - Frees the development team to focus on quality of the software instead of delivery.
5. Auto update - It's practically not possible to keep abreast of all the security vulnerabilities. Hence, all the critical system needs to be set to auto update as and when required without manual intervention.
6. Embrace Open Source

Decisions taken

1. The API and Front end (i.e GUI) are completely separate
   This helps in faster rollout of the updates. Is there is a bug in front end, the same can be released without requiring backend to be updated.

2. AWS & Google Cloud for all the Infrastructure requirements.
   Choosing industry leaders ensures Reliability, Security of the apps. It also helps gaining trust of users for their data confidentiality.

API Tech Stack

Key considerations for deciding API technology

1. Performance - It's the heart of any software, hence it has to be super fast.
2. Security - API are the most vulnerable part of any modern application.
3. Simplicity - Simple system are easy to manage and understand, thus lower risks and lower cost of maintenance.
4. Scalable - As number of users using the software increases, the system should be able to automatically scale too.

Detailed explanation below the image. Click on image to view full screen & zoom in. We use AWS for end to end API hosting.

WAF (Web Application Firewall)

Whenever a request is received, it first reaches WAF (Web Application Firewall). WAF is responsible for:

1. Preventing D-Dos Attacks
2. Providing comprehensive protection against infrastructure layer attacks like UDP floods, NTP reflection, SSDP reflection
3. Automatic scrubbing of bad traffic at Layer 3 and 4 to protect API
4. Protecting against reflection attacks or SYN floods that frequently targets DNS

Load Balancer

If the request is not blocked by WAF, it reaches load balancer. Load balancer is a separate system with it's own CPU power and RAM. It is responsible for:

1. Scaling - Starting new App Servers and shutting down App Servers which are no longer needed
2. Fault Tolerance - Checks health of the App Server and starts new App Server if required.
3. Balancing - Distributing traffic between App Servers
4. HTTPS Decryption (When Request is received by user)
5. HTTPS Encryption (When Response is sent back to the user)
6. Renew SSL certificate when nearing expiry. The SSL certificate expires typically every year. Load balancer is set to automatically renew certificate without any intervention.
7. Logging of network issues. Which helps in debugging any issues with networking of API.

Having a dedicated system for handling Encryption and Decryption gives performance benefits. It offloads CPU intensive workloads from the app server. The load balancer is capable of handling rapid changes in network traffic patterns.

App Server

The app server is divided into 2 components - NGNIX & Node JS

NGINX is an HTTP and reverse proxy server. It is responsible for

1. Decompression of Request
2. Compression of Response
3. Network Handling (Actual request and response)
4. Dropping long running requests as a security measure
5. Handling request timeouts (So that there is no performance degradation)

To speed up network time, we server all the data in compressed form using Gzip. Example: If say 100Kb of data is required to be sent from server to browser, it will be compressed to just 11Kb. Having a separate layer to handle CPU intensive workload such as data compression and decompression improves performance.

Node JS is the "Brain" 🧠 of the API. All the business logic and code resides here. It is responsible for

1. Business Logic
2. Authentication & Authorization
3. Database connection handling

Database Tech

Key considerations for deciding database

1. Performance - Ofcource 😉
2. Able to handle complex queries
3. Fault Tolerance - In case one database server goes down, it automatically shifts to another database server without data loss.
4. Burstable Performance & Scaling - Ability to burst CPU power occasionally.
5. Encryption - Ability to encrypt data for best in class confidentially. After all, this is where all the data is stored.

Our selection

"Aurora". It is Amazon's proprietary high performance enterprise grade database engine.

Detailed explanation below the image

1. The App server does not connect directly to the database. Instead we have a connection proxy which handles database authentication. This layer is responsible to reject all the malicious & unauthorized connection requests
2. Main Instance is the main database engine server which allows us to read and write data.
3. A second database engine acts like a failover mechanism in case main instance goes down. This is a read only database engine which is replica of main instance.
   Being read only it offers better caching and helps in faster data fetching. This is one of the secret of super fast Jamku.

UI Tech

Key considerations for deciding frontend

1. Performance - By this time, you would have understood that how much importance we give to performance 😉 .
2. Simple - Using a simple framework allows us hire developers from a larger pool set.
3. Open Source - To embrace cutting edge technology and the fast development cycle.
4. Single Code Base - Write single code and deploy to all (Browser, Android App, iOS App, Desktop App on Windows, Mac OS, Linux)
5. Well Maintained & Popular - A framework which is well documented and lot of learning material is available. In case we get stuck, a big community which is ready to help with our questions.

Our Framework

We choose the most popular UI framework "Vue" to develop the frontend.
The design principles are governed by Google's Material Design.

Monitoring Tech

As the software usage grows, it is essential that we track the speed of the software for end users and also usage patters to improve the features.

Key considerations for deciding monitoring tech

1. Privacy - Since Jamku handles highly confidential data, it becomes paramount to only use well reputed monitoring tools
2. Performance - Any performance or analytical tool will have an impact on the performance. Hence the goal is to keep this impact to bare minimum.

There some practice management software which use screen recording based analytical tool. We consider it to be invasion of privacy and breach of confidential data. We at Jamku only use tools which respects privacy.

Tools used for Monitoring

1. Google Analytics
   To track the usage of Jamku. To get insights on how users use Jamku, buttons clicked, pages visited, etc.
   It is pretty much industry standard.

2. Firebase Performance Monitoring (By Google)
   To track the performance of the API. How fast the server is responding to the requests. What errors are generated when requesting for the data.
   No personally identifiable information is captured.

---

Author Details

Written by Development team of Jamku & CA Adarsh Madrecha