Table of Contents

System Architecture

Project Architecture Diagram

SmartMirror Detailed Architecture Diagram

Message and data models

Data flow on the system and format of the messages

On the flow of data and usage of Kafka
The main stream of data is exchanged between our two main services: the core application and the emotion detection module. This communication is achieved through a Kafka Broker already deployed.
The messages are exchanged between two main topics: “p30-photos” and “p30-classification”.
Data structure
Since we are essentially dealing with a proof of concept system, and we don’t actually have strict guidelines on how data should look like or even flow, the decision was to stick with a simple data structure.

The message structure always follows a JSON like format:
  • For the first mentioned topic (“p30-photos”), we are essentially encoding the image taken as a photo in the main application, encoding it as a base 64 string, and building a JSON object as following before sending it to the “p30-photos” topic:
    p30-photos-json = {id: UNIQUE_IDENTIFIER, image: “data:image/png;base64, iVBORw…”}

  • The classification topic (“p30-classification”) aims to answer this first topic information. This is, the core application sends the previously shown JSON message to the corresponding topic read by the emotion detection module, and this last should parse the information, compute the necessary information and respond with a similar message to the emote classification topic. The information structure is, once again, similar to the previously shown:
    p30-classification-json = {id: UNIQUE_IDENTIFIER, emote: “happy”}

    The desired information, in this case the computed emotion, is then displayed in the front-end section of the core application giving the user the ability to understand what is being sent to the main application endpoints, and ultimately, regarding the doctor scenarios, his doctor or therapist.

  • It’s also worth mentioning that the “p30-classification” topic is listened by the application database controller where the information is saved. The main idea is that the application endpoint reads the stored information before returning it, making information consistent in the database as well as maintaining parsed and structured data before being made available in the main endpoints. Each entry on the database has the following structure:
    id: integer | timestamp: integer | user: string | value: string

arrow_upward Return to Top