The Structure of Polly

Now that we have seen some of the components of a Coreograph project, let’s return to the Polly example and study its structure.

Look at the panel structure on the left. The names of the panels here all come from patterns, i.e., standard configurations of resources and dataflow from our library of standard building blocks. While the names will look a little daunting at first, we provide examples that show how these patterns can be combined in various ways to accomplish common tasks in the cloud.

The ApiGatewayHttpApi panel creates an API Gateway API. This is a network endpoint that clients, like web browsers for example, can connect to in order to access a cloud application, in this case the Polly application. Cloud applications are organized into APIs. The creation of a cloud application consists of creating the APIs that make up the application, and Coreograph can be looked at as a tool for implementing APIs. In the case of Polly, the only API is one in which the client sends some text to translate, and receives back an audio file of the translation. In other words, this API translates the text into another language and converts the result into audio.

The LambdaBackedApiGatewayApi creates a Lambda function that performs the translation. Lambda is one of several execution services that AWS provides. The three major execution services are Lambda, Fargate, and EC2. One of the goals of Coreograph is to make it easy to move programs between these services, in order to experiment with performance and cost tradeoffs. Anyway, in this case we are using Lambda to perform the API calls that do the translation and audio conversion.

Looking a little further down in the nesting of circuits, we see TranslateText and ConvertTextToSpeech. Those two circuits do the actual work of this application – they invoke AWS services for text translation and audio transliteration.

In order to make use of this application, two steps are required:

In the next two sections we walk through these steps.