Understanding the architecture of Pictorial Translator 

Following the architecture template defined in Chapter 2, Anatomy of a Modern AI Application, here is the architectural design for Pictorial Translator:

We will provide a web user interface for users to upload photos containing foreign text and then view the translation of the foreign text. The web user interface will interact with the Orchestration Layer containing two RESTful endpoints to handle the image upload and translation:

• Upload Image Endpoint will delegate the image upload to our Storage Service:
  •  Storage Service provides an abstraction layer to AWS S3, where the uploaded photos will be stored, processed, and displayed from.
• Translate Image Text Endpoint will delegate the detection of text within the photos to our Recognition Service and the translation of the detected text to our Translation Service:
  • The Recognition Service provides an abstraction layer to the Amazon Rekognition service, more specifically, the text detection capability of Rekognition. We named our service Recognition, which is more generic and doesn't directly tie us in with AWS Rekognition.
  • The Translation Service provides an abstraction layer to the Amazon Translate service to perform the language translation.

The Service Implememntation might seem redundant to some readers. Why not just have the endpoints talk to the AWS services directly instead of talking through another layer of abstraction? There are many benefits to architecting the application this way. Here are a few examples:

• During development time, we can more easily build and test the application without dependency on AWS services. Any stub or mock implementation of these services can be used during development for speed, cost, and experimentation reasons. This lets us develop and iterate the application faster.
• When other services that provide better storage, recognition, or translation capabilities come along, our application can switch to those capabilities by swapping to a new service implementation with the same abstraction interface. The user interface and the endpoints will not need to be modified to leverage these better capabilities. This gives our application more flexibility to adapt to changes.
• This makes our code base more composable and reusable. The capabilities provided by these AWS services can be reused by other applications. These services are modular packages that can be more easily reused than the orchestration endpoints. The orchestration endpoints usually contain application-specific business logic that limits reuse.