The following documents the overall design of how we will deploy the RocReadaR Portal and Recognition Server. 

This diagram can be accessed with the proper permissions at



Element Catalog

  • RocReadaR App
    • This is the mobile application that sends images to be recognized. In this view, this is the many possible concurrent users using the system.
  • Load Balancer
    • This component takes requests from the RocReadaR App and distributes them to the next available recognition server
    • This component should not be developed by us. Many "off the shelf" versions are available, and most cloud services should have this built in.
  • Recognition Server
    • This server contains the software to recognize images uploaded by the RocReadaR App and responds with the appropriate media.
    • The Load Balancer should have the capability to create new servers at runtime on demand, based on the current request traffic. Most cloud services have this scaling capability built in.
    • Express Server
      • This provides the HTTP routes necessary to the RocReadaR App and Load balancer to perform image recognition
    • Loopback Server
      • This provides the capabilities to the application to access the database as a local HTTP ORM (Object-Relational-Mapper). 
  • RocReadaR Database
    • This is a singleton instance of a database that contains all of our recognition images and media.
    • Files stored in the database should be serialized. No files relevant to media or image recognition should be stored locally on the recognition servers.
    • A cache manager may be used "on top" of the database. Redis is a good example of a cache manager that could be used.
  • Publisher Portal Server
    • Hosts the publisher portal. This connects to the database to create and update media and recognition images used by the Recognition Server
    • Load is not a major concern of this system, as it can only be accessed by publishers. 
    • Uses Node and Loopback in a similar fashion to the Recognition Server.