This snapshots thinking as of maybe two weeks ago. I'm preparing to
do a big overhaul of all of the write-ups, and specifically start on the
Mu.yaml file format spec, and so I want to archive everything that's in flight.
This was an interesting example I found in the Mulesoft GitHub repos. It seemed like
a perfect candidate for Riff/Mu/Lambda, so I sketched out what it might look like.
This change adds a .mu/ directory to the vote50 app. Inside are the "expected"
contents that the Mu compiler should output. Eventually we will validate against
this that the (currently non-existent) compiler generates the correct thing.
This isn't complete, although I can manually create bits and pieces of the stacks
using CloudFormation. More files will come; for example, the code packages.
In a nutshell:
.mu/ # Shared files agnostic to the cloud target
aws-native-cf/ # Files specific to the AWS CloudFormation target
app.template.yaml # The CloudFormation stack for the overall app
services/ # A directory containing service-specific stacks
voting.template.yaml # The CloudFormation stack for the VotingService
services/ # Service files agnostic to the cloud target
voting.proto # The gRPC definition for VotingService's API
mu.yaml # The Mu package manifest (minimal for now)
Instead of leading in with the Service-based voting application, and then
simplifying it to a serverless Function-based one, do it in the reverse order.
This allows us to "grow" the sample, motivating each change as we go.
