Software Architecture in Moodah POS

Michael Sudirman
Nov 7 · 3 min read
Build your software like you build your house

Elegant applications that we use on a daily basis involves elegant architecture as well. Like building a house, designing a good software will have a series of components cooperating with each other. A decent architecture will reward you with a usable, maintainable and secure software.

To give you an better visualization of software architecture, I am going to use Moodah POS as an example.

Software Architecture in Moodah POS

Our Moodah POS architecture includes frontend for client-side scripting, backend for server-side scripting, and middleware for connecting these two services.

Below is a visualization diagram of how our Moodah POS’s services interact with each other:

Moodah POS Software Architecture Diagram

Dockerized Frontend

For Moodah POS’ frontend, we have a React JS based app in a dockerized environment. The Dockerfile inside the gitlab repository helps in building and running the application(s) within the environment. From the Dockerfile, the registry will also pull the Dockerfile, which is needed for running the application.

Portainer Visualization of Frontend Containers

Portainer is a GUI tool used for container management. Using this tool, we can see that the apps are running within the cs.ui.ac.id server. It is a helpful tool for visualizing the containers within the Docker.

Serverless Middleware

GraphQL Apollo Server is used in our project, which is a serverless architecture and adopted with AWS Lambda. In our case, we are using this architecture for “Function as a Service” (FaaS) platform. To deploy our middleware to AWS Lamdba, we need to run serverless deploy, which will create a endpoint url calling functions.

GraphQL Appolo

This particular language is commonly used to handle API requests and responses for the frontend, so that the frontend does not need to do the dirty work! This includes handling multiple API calls to the backend, as well as to handle naming conventions.

Moodah POS’s currently uses two different conventions from the backend and fronend. Backend uses snake_case convention, whereas frontend uses camelCase convention. With the help of this middleware, we can make sure that every variable and functions in either end are using their own naming convention. Very neat!

Odoo API, and more

Our project is only limited to the POS (Point of Sale) section of a larger, already running application called Moodah. Sadly, we are not delegated to develop the backend service. As far as our understanding goes, Moodah uses PostgreSQL database and to access it, Moodah uses Odoo API backend.

Michael Sudirman

Written by

Moodah POS

IT Project 2019 Group 2

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade