Software Architecture in Moodah POS

Michael Sudirman
Moodah POS
Published in
3 min readNov 7, 2019
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.

--

--