Third Party Monitoring Module
  • Third Party Monitoring Module Documentation
  • INTRODUCTION
    • Glossary / Terminology
    • FAQ
    • Releases / Changelog*
    • Report an Issue / Contact us
  • PRODUCT / END-USER DOCUMENTATION
    • Overview
      • User rights and permissions
    • Third Party Monitoring Module Navigation
    • Overall User Interface
    • Third Party Monitors section
      • List of Third Party Monitors
      • TPM partner details screen
    • List of Visits section
      • List of Visits
      • Visit details
      • Statuses and corresponding actions
        • Draft
        • Assigned
        • TPM Accepted
        • TPM Rejected
        • Cancelled
        • TPM Reported
        • Sent Back to TPM
        • UNICEF Approved
      • Emails notifications flow
    • TPM workflow
  • TECHNICAL DOCUMENTATION
    • Architecture
    • Development Setup
    • Deployment / DevOps
    • Backend Module structure
    • Data Model
    • Fixtures & management commands
    • API Documentation
      • Error Handling
    • Synchronization with VISION
    • Permissions framework
    • FSM Transitions conditions
    • FSM Transitions in view
    • API Metadata
    • Serializer Mixins
    • Model Mixins
    • Tests
    • Attachments
    • Email links & Tokens Authorization
    • Frontend
      • Module structure
      • Build process
      • Tests
Powered by GitBook
On this page
  1. TECHNICAL DOCUMENTATION

Architecture

PreviousTPM workflowNextDevelopment Setup

Last updated 6 years ago

Services

The platform is structured in a way that all the functionality is exposed via REST API's. The data from these API's drives the web interface which is a Single Page Application (SPA). There is a proxy that sits in front of the frontend SPA and backend API's. Additionally there is a message broker and asynchronous task / job queue that is used to run long-running and regular (say every 1 hour or 1 day) tasks.

Each of these services is either in the code and has an associated Dockerfile describing how it can be built and deployed on a docker friendly environment. Or this service uses alreadily available Docker image that we configure for our own use.

The implementation details on each of these services are the following:

  • Django API - This is the backend REST API service. Uses and .

  • Polymer frontend - This is the SPA written in .

  • Nginx proxy - This sits in front of the Django and polymer services and routes requests. This helps us to not run these services on different ports, for example, that would cause CORS issues.

  • Redis

  • Celery Beat

  • Celery workers

  • PostgreSQL database

Django
Django REST Framework
Polymer