Software Architecture in Moodah POS

thorough picture of the path from browser to Odoo

Ever wonder whats behind the curtain of some application? From performing an action through the user interface until the request is completed somewhere far away.

Here I will show the structure and how data flows in our project application, Moodah POS, in hopes that it may inspire the technology stack for your next application.

Architecture

Its the process of converting software characteristics such as scalable, extensible, modular, security into a structured solution that meets the technical and the business expectations. Examples include: monolithic, microservices and the rising serverless architecture.

In Moodah, we have a React-based front end app in docker-based architecture and Odoo’s API, a company management software as the back end fulfilling requests. Between the two, we have a middleware GraphQL Apollo server that makes multiple calls and join them to one simplified response to front end.

Moodah POS Software Architecture

Dockerized Frontend

Docker helps to build and run applications with container. A Dockerfile includes all information and code necessary for application to run.

Dockerfile for front end production

Above file will be used to create a Docker image which is pushed to faculty’s docker registry. Then we use a GUI tool for container management called Portainer. It simplifies getting containers up and running quickly.

Details of running front end container

Serverless middleware

For the GraphQL Apollo Server, serverless architecture is adopted with AWS Lambda. Serverless architecture is where applications are hosted by a third-party service, eliminating the need for server software and hardware management.

Deploying functions to AWS Lambda with the help of serverless framework is as easy as running one command and the endpoint url to call these functions will be printed to the terminal.

$ serverless deploy
...
Stack Outputs
...
ServiceEndpoint: https://xx.execute-api.us-east-1.amazonaws.com/stag

GraphQL is a query language for an API to simplify requests and response sent and received by front end. As well as delegate the task of firing multiple API calls and stitching the results to another entity, which is the GraphQL server. Another quirk is that front end can choose what fields to request, so under fetch or over fetching will not happen. Comparisons of REST and GraphQL will be touched upon below.

In REST, urls are used as identifier which function to call whereas in GraphQL url stays the same but POST request payload specifies which information to retrieve.

# REST
GET /posconfig/ # fetch all w/ all available fields
GET /posconfig/:id # read specified id
# GraphQL
POST /graphql # fetch all w/ specified fields
query {
  posConfigs {
    id
    name
  stockLocation {
      name
    }
  }
}
POST /graphql # read specified id
query {
  posConfig(input: {
    id: 47
  }) {
    id
    name
    active
  }
}

In REST, when requesting complex information, multiple API calls may be needed and it is also the front end’s load to combine the results. In GraphQL, multiple calls can be specified in the payload. Relationships defined in GraphQL schema can also be fetched in one request.

# get dropdown values for create pos config form
query {
  discountProducts {
    name
  }
  availablePricelists {
    name
  }
  paymentMethods {
    name
  }
}

Remaining elements

Since our project is to build a subsection called point of sale of a larger application called Moodah, a complete management app for companies that uses Odoo API as back end. There are several part of the architecture provided by RubyH such as their seeded demo database and API server. Also some conventions are expected to be followed for end product to be easily integrated to Moodah.

That concludes my brief overview of our project’s architecture. May it be useful for future projects. Cheers~