A code binding concept should make it possible to transform a code asset expressed at the MetaMu layer into a logical symbol in MetaIL, and then to bind that symbol to a physical code asset in the respective resource provider. For this, I am envisioning a new CodeAsset
intrinsic type.
To illustrate why we want this, consider how you would express an AWS Lambda in your favorite MetaMu. There will be a function written in code separate from the configuration language; we will then zip up that code; describe the code to configuration in terms of dynamic entrypoints; transfer the zip file to an S3 bucket; reference that bucket in the configuration; and then (hopefully) clean up that S3 bucket afterwards (or not, as is commonly the case, due to the race conditions involved).
This can be mapped to stack types in Mu simply by exposing the raw properties as-is. Of course, since those are what AWS deals with, we must translate whatever a developer writes into them. But I envision this higher level CodeAsset
type enabling a simpler expression of all of this.
The real motivating examples come when you look at MetaMu coexisting side-by-side with their regular language counterparts. For example, in the lambda case, perhaps we write code like:
let func = new aws.Lambda((ctx) => {
// lambda code goes here
});
In this example, we can pass a true lambda as the argument to a Lambda
stack. This is typed as CodeAsset
and the MetaMu compiler knows how to prepare the lambda as a CodeAsset
-- carrying the physical package's location on disk, entrypoint information, and necessary runtime (in this case, NodeJS version X) -- and then the resource provider will translate this intermediate CodeAsset
information into the properties required by AWS Lambda (zipping, S3 bucketing, etc).
There are other examples. For instance, we probably want something similar for an API gateway:
let website = new aws.WebSite({
"/": (req, res) => { /* handle "GET /" */ },
"/customer", (req, res) => { /* handle "GET /customer" */ },
... etc ...
});
In this case, the WebSite
constructor is just taking an array of CodeAsset
s. Note that because these types add some "artistic license" atop the raw AWS abstractions, they probably would exist in a separate package devoted to handling common AWS coding patterns.
As yet another example, imagine we have an RPC server. We might even envision nicer programming models than callbacks for this, perhaps using decorators:
class MyServer extends mu.x.RPC {
@api public async register(customer: Customer): Promise<void> {
// registration code goes here
}
}
In this example, we can imagine that @api
is a decorator that derives from @mu.codeasset
; this directs the MetaMu compiler to handle it must like a lambda binding to a CodeAsset
, enabling the resource provider for the mu.x.RPC
type to grovel all public members, and bind them to API endpoints. This could be just a simple way of defining an aws.WebSite
, or perhaps it could even lead to a pluggable RPC server which uses gRPC or Thrift.