@pwrdrvr/microapps-cdk 0.4.0-alpha.11 → 0.4.0-alpha.13

package/.jsii

@@ -3100,7 +3100,7 @@
   },
   "name": "@pwrdrvr/microapps-cdk",
   "readme": {
-    "markdown": "[![CI](https://github.com/pwrdrvr/microapps-core/actions/workflows/ci.yml/badge.svg)](https://github.com/pwrdrvr/microapps-core/actions/workflows/ci.yml) [![Merge to Main Build](https://github.com/pwrdrvr/microapps-core/actions/workflows/main-build.yml/badge.svg)](https://github.com/pwrdrvr/microapps-core/actions/workflows/main-build.yml) [![Release Packages](https://github.com/pwrdrvr/microapps-core/actions/workflows/release.yml/badge.svg)](https://github.com/pwrdrvr/microapps-core/actions/workflows/release.yml)\n\n# Overview\n\nThe MicroApps project enables rapidly deploying many web apps to AWS on a single shared host name, fronted by a CloudFront Distribution, serving static assets from an S3 Bucket, and routing application requests via API Gateway. MicroApps is delivered as a CDK Construct for deployment, although alternative deployment methods can be used if desired and implemented.\n\nMicroApps allows many versions of an application to be deployed either as ephemeral deploys (e.g. for pull request builds) or as semi-permanent deploys. The `microapps-router` Lambda function handled routing requests to apps to the current version targeted for a particular application start request using rules as complex as one is interested in implementing (e.g. A/B testing integration, canary releases, per-user rules for logged in users, per-group, per-deparment, and default rules).\n\nUsers start applications via a URL such as `[/{prefix}]/{appname}/`, which hits the `microapps-router` Lambda@Edge OriginRequest handler that looks up the version of the application to be run, and either forwards the request to the target Lambda Function URL (`--startupType direct` invoke mode) or returns a transparent `iframe` (`--startupType iframe`) with a link to that version.  `direct` mode works with frameworks, like Next.js, that can return pages that have build-time computed relative URLs to static resources and API calls.  `iframe` mode works with frameworks that do not write computed relative URLs at build time and/or that do not use URLs that are completely relative to wherever the applications is rooted at runtime; this mode is primarily for quick prototyping as it has other complications (such as indirect access to query strings). The URL seen by the user in the browser (and available for bookmarking) has no version in it, so subsequent launches (e.g. the next day or just in another tab) will lookup the version again. All relative URL API requests (e.g. `some/api/path`) will go to the corresponding API version that matches the version of the loaded static files, eliminating issues of incompatibility between static files and API deployments.\n\nFor development / testing purposes only, each version of an applicaton can be accessed directly via a URL of the patterns `[/{prefix}]/{appname}?appver={semver}` for `direct` mode or `[/{prefix}]/{appname}/{semver}/` for `iframe` mode. These \"versioned\" URLs are not intended to be advertised to end users as they would cause a user to be stuck on a particular version of the app if the URL was bookmarked. Note that the system does not limit access to particular versions of an application, as of 2023-03-04, but that can be added as a feature.\n\n# Table of Contents <!-- omit in toc -->\n\n- [Overview](#overview)\n- [Why MicroApps](#why-microapps)\n- [Request Routing for Static Assets / App - Diagram](#request-routing-for-static-assets--app---diagram)\n- [Request Dispatch Model for Multi-Account Deployments](#request-dispatch-model-for-multi-account-deployments)\n- [Video Preview of the Deploying CDK Construct](#video-preview-of-the-deploying-cdk-construct)\n- [Installation / CDK Constructs](#installation--cdk-constructs)\n- [Tutorial - Bootstrapping a Deploy](#tutorial---bootstrapping-a-deploy)\n- [Limitations / Future Development](#limitations--future-development)\n- [Related Projects / Components](#related-projects--components)\n- [Why Lambda @ Origin and Not Lambda @ Edge for Apps](#why-lambda--origin-and-not-lambda--edge-for-apps)\n- [Architecure Diagram](#architecure-diagram)\n- [Project Layout](#project-layout)\n- [Creating a MicroApp Using Zip Lambda Functions](#creating-a-microapp-using-zip-lambda-functions)\n- [Creating a MicroApp Using Docker Lambda Functions](#creating-a-microapp-using-docker-lambda-functions)\n  - [Next.js Apps](#nextjs-apps)\n    - [Modify package.json](#modify-packagejson)\n    - [Install Dependencies](#install-dependencies)\n    - [Dockerfile](#dockerfile)\n    - [next.config.js](#nextconfigjs)\n- [Troubleshooting](#troubleshooting)\n  - [CloudFront Requests to API Gateway are Rejected with 403 Forbidden](#cloudfront-requests-to-api-gateway-are-rejected-with-403-forbidden)\n    - [SignatureV4 Headers](#signaturev4-headers)\n\n# Why MicroApps\n\nMicroApps are like micro services, but for Web UIs. A MicroApp allows a single functional site to be developed by many independent teams within an organization. Teams must coordinate deployments and agree upon one implementation technology and framework when building a monolithic, or even a monorepo, web application.\n\nTeams using MicroApps can deploy independently of each other with coordination being required only at points of intentional integration (e.g. adding a feature to pass context from one MicroApp to another or coordination of a major feature release to users) and sharing UI styles, if desired (it is possible to build styles that look the same across many different UI frameworks).\n\nMicroApps also allow each team to use a UI framework and backend language that is most appropriate for their solving their business problem. Not every app has to use React or Next.js or even Node on the backend, but instead they can use whatever framework they want and Java, Go, C#, Python, etc. for UI API calls.\n\nFor internal sites, or logged-in-customer sites, different tools or products can be hosted in entirely independent MicroApps. A menuing system / toolbar application can be created as a MicroApp and that menu app can open the apps in the system within a transparent iframe. For externally facing sites, such as for an e-commerce site, it is possible to have a MicroApp serving `/product/...`, another serving `/search/...`, another serving `/`, etc.\n\n# Request Routing for Static Assets / App - Diagram\n\n![Request Routing for Static Assets and App](https://user-images.githubusercontent.com/5617868/222913451-0e6ed906-b6ee-461f-99a7-61db13135ce1.png)\n\n# Request Dispatch Model for Multi-Account Deployments\n\nNote: requests can also be dispatched into the same account, but this model is more likely to be used by organizations with many AWS accounts.\n\n![Request Dispatch Model for Mulit-Account Deployments](https://user-images.githubusercontent.com/5617868/218237120-65b3ae44-31ba-4b6d-8722-4d3fb7da5577.png)\n\n# Video Preview of the Deploying CDK Construct\n\n![Video Preview of Deploying](https://raw.githubusercontent.com/pwrdrvr/microapps-core/main/assets/videos/microapps-core-demo-deploy.gif)\n\n# Installation / CDK Constructs\n\n- `npm i --save-dev @pwrdrvr/microapps-cdk`\n- Add `MicroApps` construct to your stack\n- The `MicroApps` construct does a \"turn-key\" deployment complete with the Release app\n- [Construct Hub](https://constructs.dev/packages/@pwrdrvr/microapps-cdk/)\n  - CDK API docs\n  - Python, DotNet, Java, JS/TS installation instructions\n\n# Tutorial - Bootstrapping a Deploy\n\n- `git clone https://github.com/pwrdrvr/microapps-core.git`\n  - Note: the repo is only being for the example CDK Stack, it is not necessary to clone the repo when used in a custom CDK Stack\n- `cd microapps-core`\n- `npm i -g aws-cdk`\n  - Install AWS CDK v2 CLI\n- `asp [my-sso-profile-name]`\n  - Using the `aws` plugin from `oh-my-zsh` for AWS SSO\n  - Of course, there are other methods of setting env vars\n- `aws sso login`\n  - Establish an AWS SSO session\n- `export AWS_REGION=us-east-2`\n  - Region needs to be set for the Lambda invoke - This can be done other ways in `~/.aws/config` as well\n- `./deploy.sh`\n  - Deploys the CDK Stack\n  - Essentially runs two commands along with extraction of outputs:\n    - `npx cdk deploy --context @pwrdrvr/microapps:deployReleaseApp=true microapps-basic`\n    - `npx microapps-publish publish --app-name release --new-version ${RELEASE_APP_PACKAGE_VERSION} --deployer-lambda-name ${DEPLOYER_LAMBDA_NAME} --app-lambda-name ${RELEASE_APP_LAMBDA_NAME} --static-assets-path node_modules/@pwrdrvr/microapps-app-release-cdk/lib/static_files/release/${RELEASE_APP_PACKAGE_VERSION}/ --overwrite --no-cache`\n  - URL will be printed as last output\n\n# Limitations / Future Development\n\n- AWS Only\n  - For the time being this has only been implemented for AWS technologies and APIs\n  - It is possible that Azure and GCP have sufficient support to enable porting the framework\n  - CDK would have to be replaced as well (unless it's made available for Azure and GCP in the near future)\n- `microapps-publish` only supports Lambda function apps\n  - There is no technical reason for the apps to only run as Lambda functions\n  - Web apps could just as easily run on EC2, Kubernetes, EKS, ECS, etc\n  - Anything that API Gateway can route to can work for serving a MicroApp\n  - The publish tool needs to provide additional options for setting up the API Gateway route to the app\n- Authentication\n  - Authentication requires rolling your own API Gateway and CloudFront deployment at the moment\n  - The \"turn key\" CDK Construct should provide options to show an example of how authentication can be integrated\n- Release Rules\n  - Currently only a Default rule is supported\n  - Need to evaluate if a generic implementation can be made, possibly allowing plugins or webhooks to support arbitrary rules\n  - If not possible to make it perfectly generic, consider providing a more complete reference implementation of examples\n\n# Related Projects / Components\n\n- Release App\n  - The Release app is an initial, rudimentary, release control console for setting the default version of an application\n  - Built with Next.js\n  - [pwrdrvr/microapps-app-release](https://github.com/pwrdrvr/microapps-app-release)\n- Next.js Demo App\n  - The Next.js Tutorial application deployed as a MicroApp\n  - [pwrdrvr/serverless-nextjs-demo](https://github.com/pwrdrvr/serverless-nextjs-demo)\n\n\n# Why Lambda @ Origin and Not Lambda @ Edge for Apps\n\nCalling resources (DBs and other services) and waiting for a long synchronous response is an anti-pattern in Lambda as the Lambda function will be billed for the time spent waiting for the response. This is especially true for Lambda@Edge as the cost is 3x higher than Lambda at the origin.\n\nWith Lambda@Edge (even with Origin Requests) the cost is 3x higher per GB-second and the time spent waiting for a 1 ms service response from an origin that is 250 ms away is 750x higher (250 ms / 1ms * 3x higher cost) than making that same request within the region where the resource resides.\n\n- Lambda@Edge is _at least_ 3x more expensive than Lambda at the origin:\n  - In US East 1, the price per GB-Second is $0.00005001 for Lambda@Edge\n    - Source: https://aws.amazon.com/lambda/pricing/ (bottom of page)\n    - Updated: 2023-03-04\n  - In US East 1, the price per GB-Second is $0.0000166667 for Lambda at the origin on x86\n    - Source: https://aws.amazon.com/lambda/pricing/\n    - Updated: 2023-03-04\n  - Ratio\n    - Lambda@Edge / Lambda@Origin = $0.00005001 / $0.0000166667 = 3.0006x\n- Any DB or services calls from Lambda@Edge back to the origin will pay that 3x higher per GB-Second cost for any time spent waiting to send the request and get a response. Example:\n  - Lambda@Edge\n    - 0.250s Round Trip Time (RTT) for EU-zone edge request to hit US-East 1 Origin\n    - 0.200s DB lookup time\n    - 0.050s CPU usage to process the DB response\n    - 0.500s total billed time @ $0.00005001 @ 128 MB\n    - $0.000003125625 total charge\n  - Lambda at Origin\n    - RTT does not apply (it's effectively 1-2 ms to hit a DB in the same region)\n    - 0.200s DB lookup time\n    - 0.050s CPU usage to process the DB response\n    - 0.250s total billed time @ $0.0000166667 @ 128 MB\n    - Half the billed time of running on Lambda@Edge\n    - 1/6th the cost of running on Lambda@Edge:\n      - $0.000000520834375 total charge (assuming no CPU time to process the response)\n      - $0.000003125625 / $0.000000520834375 = 6x more expensive in Lambda@Edge\n\n# Architecure Diagram\n\n![Architecure Diagram](https://raw.githubusercontent.com/pwrdrvr/microapps-core/main/assets/images/architecture-diagram.png)\n\n# Project Layout\n\n- [packages/cdk](https://github.com/pwrdrvr/microapps-core/tree/main/packages/cdk)\n  - Example CDK Stack\n  - Deploys MicroApps CDK stack for the GitHub Workflows\n  - Can be used as an example of how to use the MicroApps CDK Construct\n- [packages/demo-app](https://github.com/pwrdrvr/microapps-core/tree/main/packages/demo-app)\n  - Example app with static resources and a Lambda function\n  - Does not use any Web UI framework at all\n- [packages/microapps-cdk](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-cdk)\n  - MicroApps\n    - \"Turn key\" CDK Construct that creates all assets needed for a working MicroApps deployment\n  - MicroAppsAPIGwy\n    - Create APIGateway HTTP API\n    - Creates domain names to point to the edge (Cloudfront) and origin (API Gateway)\n  - MicroAppsCF\n    - Creates Cloudfront distribution\n  - MicroAppsS3\n    - Creates S3 buckets\n  - MicroAppsSvcs\n    - Create DynamoDB table\n    - Create Deployer Lambda function\n    - Create Router Lambda function\n- [packages/microapps-datalib](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-datalib)\n  - Installed from `npm`:\n    - `npm i -g @pwrdrvr/microapps-datalib`\n  - APIs for access to the DynamoDB Table used by `microapps-publish`, `microapps-deployer`, and `@pwrdrvr/microapps-app-release-cdk`\n- [packages/microapps-deployer](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-deployer)\n  - Lambda service invoked by `microapps-publish` to record new app/version in the DynamoDB table, create API Gateway integrations, copy S3 assets from staging to prod bucket, etc.\n  - Returns a temporary S3 token with restricted access to the staging S3 bucket for upload of the static files for one app/semver\n- [packages/microapps-publish](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-publish)\n  - Installed from `npm`:\n    - `npm i -g @pwrdrvr/microapps-publish`\n  - Node executable that updates versions in config files, deploys static assets to the S3 staging bucket, optionally compiles and deploys a new Lambda function version, and invokes `microapps-deployer`\n  - AWS IAM permissions required:\n    - `lambda:InvokeFunction`\n- [packages/microapps-router](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-router)\n  - Lambda function that determines which version of an app to point a user to on a particular invocation\n\n# Creating a MicroApp Using Zip Lambda Functions\n\n[TBC]\n\n# Creating a MicroApp Using Docker Lambda Functions\n\nNote: semi-deprecated as of 2022-01-27. Zip Lambda functions are better supported.\n\n## Next.js Apps\n\nCreate a Next.js app then follow the steps in this section to set it up for publishing to AWS Lambda @ Origin as a MicroApp. To publish new versions of the app use `npx microapps-publish --new-version x.y.z` when logged in to the target AWS account.\n\n### Modify package.json\n\nReplace the version with `0.0.0` so it can be modified by the `microapps-publish` tool.\n\n### Install Dependencies\n\n```\nnpm i --save-dev @pwrdrvr/microapps-publish\n```\n\n### Dockerfile\n\nFIXME: Out of date 2023-03-04\n\nAdd this file to the root of the app.\n\n```Dockerfile\nFROM node:15-slim as base\n\nWORKDIR /app\n\n# Download the sharp libs once to save time\n# Do this before copying anything else in\nRUN mkdir -p image-lambda-npms && \\\n  cd image-lambda-npms && npm i sharp && \\\n  rm -rf node_modules/sharp/vendor/*/include/\n\n# Copy in the build output from `npx serverless`\nCOPY .serverless_nextjs .\nCOPY config.json .\n\n# Move the sharp libs into place\nRUN rm -rf image-lambda/node_modules/ && \\\n  mv image-lambda-npms/node_modules image-labmda/ && \\\n  rm -rf image-lambda-npms\n\nFROM public.ecr.aws/lambda/nodejs:14 AS final\n\n# Copy in the munged code\nCOPY --from=base /app .\n\nCMD [ \"./index.handler\" ]\n```\n\n### next.config.js\n\nFIXME: Out of date 2023-03-04\n\nAdd this file to the root of the app.\n\nReplace `appname` with your URL path-compatible application name.\n\n```js\nconst appRoot = '/appname/0.0.0';\n\n// eslint-disable-next-line no-undef\nmodule.exports = {\n  target: 'serverless',\n  webpack: (config, _options) => {\n    return config;\n  },\n  basePath: appRoot,\n  publicRuntimeConfig: {\n    // Will be available on both server and client\n    staticFolder: appRoot,\n  },\n};\n```\n\n# Troubleshooting\n\n## CloudFront Requests to API Gateway are Rejected with 403 Forbidden\n\nRequests to the API Gateway origin can be rejected with a 403 Forbidden error if the signed request headers are not sent to the origin by CloudFront.\n\nThe error in the API Gateway CloudWatch logs will show up as:\n\n```log\n\"authorizerError\": \"The request for the IAM Authorizer doesn't match the format that API Gateway expects.\"\n```\n\nThis can be simulated by simply running `curl [api-gateway-url]`, with no headers.\n\nTo confirm that API Gateway is allowing signed requests when the IAM Authorizer is configured, establish credentials as a user that is allowed to execute the API Gateay, install `awscurl` with `pip3 install awscurl`, then then use `awscurl --service execute-api --region [api-gateway-region] [api-gateway-url]`.\n\nSignature headers will not be sent from CloudFront to API Gateway unless the `OriginRequestPolicy` is set to specifically include those headers on requests to the origin, or the `headersBehavior` is set to `cfront.OriginRequestHeaderBehavior.all()`.\n\nSimilarly, if `presign` is used, the `OriginRequestPolicy` must be set to `cfront.OriginRequestQueryStringBehavior.all()` or to specifically forward the query string parameters used by the presigned URL.\n\n### SignatureV4 Headers\n- `authorization`\n- `x-amz-date`\n- `x-amz-security-token`\n- `x-amz-content-sha256`\n"
+    "markdown": "[![CI](https://github.com/pwrdrvr/microapps-core/actions/workflows/ci.yml/badge.svg)](https://github.com/pwrdrvr/microapps-core/actions/workflows/ci.yml) [![Merge to Main Build](https://github.com/pwrdrvr/microapps-core/actions/workflows/main-build.yml/badge.svg)](https://github.com/pwrdrvr/microapps-core/actions/workflows/main-build.yml) [![Release Packages](https://github.com/pwrdrvr/microapps-core/actions/workflows/release.yml/badge.svg)](https://github.com/pwrdrvr/microapps-core/actions/workflows/release.yml)\n\n# Overview\n\nThe MicroApps project enables rapidly deploying many web apps to AWS on a single shared host name, fronted by a CloudFront Distribution, serving static assets from an S3 Bucket, and routing application requests via API Gateway. MicroApps is delivered as a CDK Construct for deployment, although alternative deployment methods can be used if desired and implemented.\n\nMicroApps allows many versions of an application to be deployed either as ephemeral deploys (e.g. for pull request builds) or as semi-permanent deploys. The `microapps-router` Lambda function handled routing requests to apps to the current version targeted for a particular application start request using rules as complex as one is interested in implementing (e.g. A/B testing integration, canary releases, per-user rules for logged in users, per-group, per-deparment, and default rules).\n\nUsers start applications via a URL such as `[/{prefix}]/{appname}/`, which hits the `microapps-router` Lambda@Edge OriginRequest handler that looks up the version of the application to be run, and either forwards the request to the target Lambda Function URL (`--startupType direct` invoke mode) or returns a transparent `iframe` (`--startupType iframe`) with a link to that version.  `direct` mode works with frameworks, like Next.js, that can return pages that have build-time computed relative URLs to static resources and API calls.  `iframe` mode works with frameworks that do not write computed relative URLs at build time and/or that do not use URLs that are completely relative to wherever the applications is rooted at runtime; this mode is primarily for quick prototyping as it has other complications (such as indirect access to query strings). The URL seen by the user in the browser (and available for bookmarking) has no version in it, so subsequent launches (e.g. the next day or just in another tab) will lookup the version again. All relative URL API requests (e.g. `some/api/path`) will go to the corresponding API version that matches the version of the loaded static files, eliminating issues of incompatibility between static files and API deployments.\n\nFor development / testing purposes only, each version of an applicaton can be accessed directly via a URL of the patterns `[/{prefix}]/{appname}?appver={semver}` for `direct` mode or `[/{prefix}]/{appname}/{semver}/` for `iframe` mode. These \"versioned\" URLs are not intended to be advertised to end users as they would cause a user to be stuck on a particular version of the app if the URL was bookmarked. Note that the system does not limit access to particular versions of an application, as of 2023-03-04, but that can be added as a feature.\n\n# Table of Contents <!-- omit in toc -->\n\n- [Overview](#overview)\n- [Why MicroApps](#why-microapps)\n- [Request Routing for Static Assets / App - Diagram](#request-routing-for-static-assets--app---diagram)\n- [Request Dispatch Model for Multi-Account Deployments](#request-dispatch-model-for-multi-account-deployments)\n- [Video Preview of the Deploying CDK Construct](#video-preview-of-the-deploying-cdk-construct)\n- [Installation / CDK Constructs](#installation--cdk-constructs)\n- [Tutorial - Bootstrapping a Deploy](#tutorial---bootstrapping-a-deploy)\n- [Limitations / Future Development](#limitations--future-development)\n- [Related Projects / Components](#related-projects--components)\n- [Why Lambda @ Origin and Not Lambda @ Edge for Apps](#why-lambda--origin-and-not-lambda--edge-for-apps)\n- [Architecure Diagram](#architecure-diagram)\n- [Project Layout](#project-layout)\n- [Creating a MicroApp Using Zip Lambda Functions](#creating-a-microapp-using-zip-lambda-functions)\n- [Creating a MicroApp Using Docker Lambda Functions](#creating-a-microapp-using-docker-lambda-functions)\n  - [Next.js Apps](#nextjs-apps)\n    - [Modify package.json](#modify-packagejson)\n    - [Install Dependencies](#install-dependencies)\n    - [Dockerfile](#dockerfile)\n    - [next.config.js](#nextconfigjs)\n- [Troubleshooting](#troubleshooting)\n  - [CloudFront Requests to API Gateway are Rejected with 403 Forbidden](#cloudfront-requests-to-api-gateway-are-rejected-with-403-forbidden)\n    - [SignatureV4 Headers](#signaturev4-headers)\n\n# Why MicroApps\n\nMicroApps are like micro services, but for Web UIs. A MicroApp allows a single functional site to be developed by many independent teams within an organization. Teams must coordinate deployments and agree upon one implementation technology and framework when building a monolithic, or even a monorepo, web application.\n\nTeams using MicroApps can deploy independently of each other with coordination being required only at points of intentional integration (e.g. adding a feature to pass context from one MicroApp to another or coordination of a major feature release to users) and sharing UI styles, if desired (it is possible to build styles that look the same across many different UI frameworks).\n\nMicroApps also allow each team to use a UI framework and backend language that is most appropriate for their solving their business problem. Not every app has to use React or Next.js or even Node on the backend, but instead they can use whatever framework they want and Java, Go, C#, Python, etc. for UI API calls.\n\nFor internal sites, or logged-in-customer sites, different tools or products can be hosted in entirely independent MicroApps. A menuing system / toolbar application can be created as a MicroApp and that menu app can open the apps in the system within a transparent iframe. For externally facing sites, such as for an e-commerce site, it is possible to have a MicroApp serving `/product/...`, another serving `/search/...`, another serving `/`, etc.\n\n# Request Routing for Static Assets / App - Diagram\n\n![Request Routing for Static Assets and App](https://user-images.githubusercontent.com/5617868/222913451-0e6ed906-b6ee-461f-99a7-61db13135ce1.png)\n\n# Request Dispatch Model for Multi-Account Deployments\n\nNote: requests can also be dispatched into the same account, but this model is more likely to be used by organizations with many AWS accounts.\n\n![Request Dispatch Model for Mulit-Account Deployments](https://user-images.githubusercontent.com/5617868/218237120-65b3ae44-31ba-4b6d-8722-4d3fb7da5577.png)\n\n# Video Preview of the Deploying CDK Construct\n\n![Video Preview of Deploying](https://raw.githubusercontent.com/pwrdrvr/microapps-core/main/assets/videos/microapps-core-demo-deploy.gif)\n\n# Installation / CDK Constructs\n\n- `npm i --save-dev @pwrdrvr/microapps-cdk`\n- Add `MicroApps` construct to your stack\n- The `MicroApps` construct does a \"turn-key\" deployment complete with the Release app\n- [Construct Hub](https://constructs.dev/packages/@pwrdrvr/microapps-cdk/)\n  - CDK API docs\n  - Python, DotNet, Java, JS/TS installation instructions\n\n# Tutorial - Bootstrapping a Deploy\n\n- `git clone https://github.com/pwrdrvr/microapps-core.git`\n  - Note: the repo is only being for the example CDK Stack, it is not necessary to clone the repo when used in a custom CDK Stack\n- `cd microapps-core`\n- `npm i -g aws-cdk`\n  - Install AWS CDK v2 CLI\n- `asp [my-sso-profile-name]`\n  - Using the `aws` plugin from `oh-my-zsh` for AWS SSO\n  - Of course, there are other methods of setting env vars\n- `aws sso login`\n  - Establish an AWS SSO session\n- `export AWS_REGION=us-east-2`\n  - Region needs to be set for the Lambda invoke - This can be done other ways in `~/.aws/config` as well\n- `./deploy.sh`\n  - Deploys the CDK Stack\n  - Essentially runs two commands along with extraction of outputs:\n    - `npx cdk deploy --context @pwrdrvr/microapps:deployReleaseApp=true microapps-basic`\n    - `npx pwrdrvr publish --app-name release --new-version ${RELEASE_APP_PACKAGE_VERSION} --deployer-lambda-name ${DEPLOYER_LAMBDA_NAME} --app-lambda-name ${RELEASE_APP_LAMBDA_NAME} --static-assets-path node_modules/@pwrdrvr/microapps-app-release-cdk/lib/static_files/release/${RELEASE_APP_PACKAGE_VERSION}/ --overwrite --no-cache`\n  - URL will be printed as last output\n\n# Limitations / Future Development\n\n- AWS Only\n  - For the time being this has only been implemented for AWS technologies and APIs\n  - It is possible that Azure and GCP have sufficient support to enable porting the framework\n  - CDK would have to be replaced as well (unless it's made available for Azure and GCP in the near future)\n- Release Rules\n  - Currently only a Default rule is supported\n  - Need to evaluate if a generic implementation can be made, possibly allowing plugins or webhooks to support arbitrary rules\n  - If not possible to make it perfectly generic, consider providing a more complete reference implementation of examples\n\n# Related Projects / Components\n\n- Release App\n  - The Release app is an initial, rudimentary, release control console for setting the default version of an application\n  - Built with Next.js\n  - [pwrdrvr/microapps-app-release](https://github.com/pwrdrvr/microapps-app-release)\n- Next.js Demo App\n  - The Next.js Tutorial application deployed as a MicroApp\n  - [pwrdrvr/serverless-nextjs-demo](https://github.com/pwrdrvr/serverless-nextjs-demo)\n\n\n# Why Lambda @ Origin and Not Lambda @ Edge for Apps\n\nCalling resources (DBs and other services) and waiting for a long synchronous response is an anti-pattern in Lambda as the Lambda function will be billed for the time spent waiting for the response. This is especially true for Lambda@Edge as the cost is 3x higher than Lambda at the origin.\n\nWith Lambda@Edge (even with Origin Requests) the cost is 3x higher per GB-second and the time spent waiting for a 1 ms service response from an origin that is 250 ms away is 750x higher (250 ms / 1ms * 3x higher cost) than making that same request within the region where the resource resides.\n\n- Lambda@Edge is _at least_ 3x more expensive than Lambda at the origin:\n  - In US East 1, the price per GB-Second is $0.00005001 for Lambda@Edge\n    - Source: https://aws.amazon.com/lambda/pricing/ (bottom of page)\n    - Updated: 2023-03-04\n  - In US East 1, the price per GB-Second is $0.0000166667 for Lambda at the origin on x86\n    - Source: https://aws.amazon.com/lambda/pricing/\n    - Updated: 2023-03-04\n  - Ratio\n    - Lambda@Edge / Lambda@Origin = $0.00005001 / $0.0000166667 = 3.0006x\n- Any DB or services calls from Lambda@Edge back to the origin will pay that 3x higher per GB-Second cost for any time spent waiting to send the request and get a response. Example:\n  - Lambda@Edge\n    - 0.250s Round Trip Time (RTT) for EU-zone edge request to hit US-East 1 Origin\n    - 0.200s DB lookup time\n    - 0.050s CPU usage to process the DB response\n    - 0.500s total billed time @ $0.00005001 @ 128 MB\n    - $0.000003125625 total charge\n  - Lambda at Origin\n    - RTT does not apply (it's effectively 1-2 ms to hit a DB in the same region)\n    - 0.200s DB lookup time\n    - 0.050s CPU usage to process the DB response\n    - 0.250s total billed time @ $0.0000166667 @ 128 MB\n    - Half the billed time of running on Lambda@Edge\n    - 1/6th the cost of running on Lambda@Edge:\n      - $0.000000520834375 total charge (assuming no CPU time to process the response)\n      - $0.000003125625 / $0.000000520834375 = 6x more expensive in Lambda@Edge\n\n# Architecure Diagram\n\n![Architecure Diagram](https://raw.githubusercontent.com/pwrdrvr/microapps-core/main/assets/images/architecture-diagram.png)\n\n# Project Layout\n\n- [packages/cdk](https://github.com/pwrdrvr/microapps-core/tree/main/packages/cdk)\n  - Example CDK Stack\n  - Deploys MicroApps CDK stack for the GitHub Workflows\n  - Can be used as an example of how to use the MicroApps CDK Construct\n- [packages/demo-app](https://github.com/pwrdrvr/microapps-core/tree/main/packages/demo-app)\n  - Example app with static resources and a Lambda function\n  - Does not use any Web UI framework at all\n- [packages/microapps-cdk](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-cdk)\n  - MicroApps\n    - \"Turn key\" CDK Construct that creates all assets needed for a working MicroApps deployment\n  - MicroAppsAPIGwy\n    - Create APIGateway HTTP API\n    - Creates domain names to point to the edge (Cloudfront) and origin (API Gateway)\n  - MicroAppsCF\n    - Creates Cloudfront distribution\n  - MicroAppsS3\n    - Creates S3 buckets\n  - MicroAppsSvcs\n    - Create DynamoDB table\n    - Create Deployer Lambda function\n    - Create Router Lambda function\n- [packages/microapps-datalib](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-datalib)\n  - Installed from `npm`:\n    - `npm i -g @pwrdrvr/microapps-datalib`\n  - APIs for access to the DynamoDB Table used by the `pwrdrvr` CLI, `microapps-deployer`, and `@pwrdrvr/microapps-app-release-cdk`\n- [packages/microapps-deployer](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-deployer)\n  - Lambda service invoked by the `pwrdrvr` CLI to record new app/version in the DynamoDB table, create API Gateway integrations, copy S3 assets from staging to prod bucket, etc.\n  - Returns a temporary S3 token with restricted access to the staging S3 bucket for upload of the static files for one app/semver\n- [packages/pwrdrvr](https://github.com/pwrdrvr/microapps-core/tree/main/packages/pwrdrvr)\n  - Installed from `npm`:\n    - `npm i -g pwrdrvr`\n  - Node executable that updates versions in config files, deploys static assets to the S3 staging bucket, optionally compiles and deploys a new Lambda function version, and invokes `microapps-deployer`\n  - AWS IAM permissions required:\n    - `lambda:InvokeFunction`\n- [packages/microapps-router](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-router)\n  - Lambda function that determines which version of an app to point a user to on a particular invocation\n\n# Creating a MicroApp Using Zip Lambda Functions\n\n[TBC]\n\n# Creating a MicroApp Using Docker Lambda Functions\n\nDocker Lambdas are great for large applications.  These used to be slower to cold start but as of early 2023 that appears to no longer be an issue.\n\n## Next.js Apps\n\nCreate a Next.js app then follow the steps in this section to set it up for publishing to AWS Lambda @ Origin as a MicroApp. To publish new versions of the app use `npx pwrdrvr --new-version x.y.z` when logged in to the target AWS account.\n\n### Modify package.json\n\nReplace the version with `0.0.0` so it can be modified by the `pwrdrvr` CLI.\n\n### Install Dependencies\n\n```\nnpm i --save-dev pwrdrvr\n```\n\n### Dockerfile\n\nFIXME: Out of date 2023-03-04\n\nAdd this file to the root of the app.\n\n```Dockerfile\nFROM node:15-slim as base\n\nWORKDIR /app\n\n# Download the sharp libs once to save time\n# Do this before copying anything else in\nRUN mkdir -p image-lambda-npms && \\\n  cd image-lambda-npms && npm i sharp && \\\n  rm -rf node_modules/sharp/vendor/*/include/\n\n# Copy in the build output from `npx serverless`\nCOPY .serverless_nextjs .\nCOPY config.json .\n\n# Move the sharp libs into place\nRUN rm -rf image-lambda/node_modules/ && \\\n  mv image-lambda-npms/node_modules image-labmda/ && \\\n  rm -rf image-lambda-npms\n\nFROM public.ecr.aws/lambda/nodejs:14 AS final\n\n# Copy in the munged code\nCOPY --from=base /app .\n\nCMD [ \"./index.handler\" ]\n```\n\n### next.config.js\n\nFIXME: Out of date 2023-03-04\n\nAdd this file to the root of the app.\n\nReplace `appname` with your URL path-compatible application name.\n\n```js\nconst appRoot = '/appname/0.0.0';\n\n// eslint-disable-next-line no-undef\nmodule.exports = {\n  target: 'serverless',\n  webpack: (config, _options) => {\n    return config;\n  },\n  basePath: appRoot,\n  publicRuntimeConfig: {\n    // Will be available on both server and client\n    staticFolder: appRoot,\n  },\n};\n```\n\n# Troubleshooting\n\n## CloudFront Requests to API Gateway are Rejected with 403 Forbidden\n\nRequests to the API Gateway origin can be rejected with a 403 Forbidden error if the signed request headers are not sent to the origin by CloudFront.\n\nThe error in the API Gateway CloudWatch logs will show up as:\n\n```log\n\"authorizerError\": \"The request for the IAM Authorizer doesn't match the format that API Gateway expects.\"\n```\n\nThis can be simulated by simply running `curl [api-gateway-url]`, with no headers.\n\nTo confirm that API Gateway is allowing signed requests when the IAM Authorizer is configured, establish credentials as a user that is allowed to execute the API Gateay, install `awscurl` with `pip3 install awscurl`, then then use `awscurl --service execute-api --region [api-gateway-region] [api-gateway-url]`.\n\nSignature headers will not be sent from CloudFront to API Gateway unless the `OriginRequestPolicy` is set to specifically include those headers on requests to the origin, or the `headersBehavior` is set to `cfront.OriginRequestHeaderBehavior.all()`.\n\nSimilarly, if `presign` is used, the `OriginRequestPolicy` must be set to `cfront.OriginRequestQueryStringBehavior.all()` or to specifically forward the query string parameters used by the presigned URL.\n\n### SignatureV4 Headers\n- `authorization`\n- `x-amz-date`\n- `x-amz-security-token`\n- `x-amz-content-sha256`\n"
   },
   "repository": {
     "type": "git",
@@ -3464,7 +3464,7 @@
       "kind": "interface",
       "locationInModule": {
         "filename": "src/MicroApps.ts",
-        "line": 318
+        "line": 323
       },
       "name": "IMicroApps",
       "properties": [
@@ -3477,7 +3477,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 320
+            "line": 325
           },
           "name": "cf",
           "type": {
@@ -3493,7 +3493,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 326
+            "line": 331
           },
           "name": "s3",
           "type": {
@@ -3509,7 +3509,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 329
+            "line": 334
           },
           "name": "svcs",
           "type": {
@@ -3525,7 +3525,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 332
+            "line": 337
           },
           "name": "apigwy",
           "optional": true,
@@ -3542,7 +3542,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 323
+            "line": 328
           },
           "name": "edgeToOrigin",
           "optional": true,
@@ -3646,7 +3646,7 @@
       "kind": "interface",
       "locationInModule": {
         "filename": "src/MicroAppsChildDeployer.ts",
-        "line": 68
+        "line": 70
       },
       "name": "IMicroAppsChildDeployer",
       "properties": [
@@ -3659,7 +3659,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 72
+            "line": 74
           },
           "name": "deployerFunc",
           "type": {
@@ -3872,7 +3872,7 @@
       "kind": "interface",
       "locationInModule": {
         "filename": "src/MicroAppsSvcs.ts",
-        "line": 186
+        "line": 191
       },
       "name": "IMicroAppsSvcs",
       "properties": [
@@ -3885,7 +3885,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsSvcs.ts",
-            "line": 195
+            "line": 200
           },
           "name": "deployerFunc",
           "type": {
@@ -3901,7 +3901,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsSvcs.ts",
-            "line": 190
+            "line": 195
           },
           "name": "table",
           "type": {
@@ -3917,7 +3917,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsSvcs.ts",
-            "line": 200
+            "line": 205
           },
           "name": "routerFunc",
           "optional": true,
@@ -3980,7 +3980,7 @@
         },
         "locationInModule": {
           "filename": "src/MicroApps.ts",
-          "line": 381
+          "line": 386
         },
         "parameters": [
           {
@@ -4010,7 +4010,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/MicroApps.ts",
-        "line": 355
+        "line": 360
       },
       "name": "MicroApps",
       "properties": [
@@ -4022,7 +4022,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 357
+            "line": 362
           },
           "name": "cf",
           "overrides": "@pwrdrvr/microapps-cdk.IMicroApps",
@@ -4038,7 +4038,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 367
+            "line": 372
           },
           "name": "s3",
           "overrides": "@pwrdrvr/microapps-cdk.IMicroApps",
@@ -4054,7 +4054,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 377
+            "line": 382
           },
           "name": "svcs",
           "overrides": "@pwrdrvr/microapps-cdk.IMicroApps",
@@ -4070,7 +4070,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 372
+            "line": 377
           },
           "name": "apigwy",
           "optional": true,
@@ -4087,7 +4087,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroApps.ts",
-            "line": 362
+            "line": 367
           },
           "name": "edgeToOrigin",
           "optional": true,
@@ -4818,7 +4818,7 @@
         },
         "locationInModule": {
           "filename": "src/MicroAppsChildDeployer.ts",
-          "line": 84
+          "line": 86
         },
         "parameters": [
           {
@@ -4848,7 +4848,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/MicroAppsChildDeployer.ts",
-        "line": 78
+        "line": 80
       },
       "name": "MicroAppsChildDeployer",
       "properties": [
@@ -4860,7 +4860,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 80
+            "line": 82
           },
           "name": "deployerFunc",
           "overrides": "@pwrdrvr/microapps-cdk.IMicroAppsChildDeployer",
@@ -4895,29 +4895,13 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 37
+            "line": 39
           },
           "name": "appEnv",
           "type": {
             "primitive": "string"
           }
         },
-        {
-          "abstract": true,
-          "docs": {
-            "stability": "experimental",
-            "summary": "ARN of the IAM Role for the Edge to Origin Lambda Function."
-          },
-          "immutable": true,
-          "locationInModule": {
-            "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 22
-          },
-          "name": "edgeToOriginRoleARN",
-          "type": {
-            "primitive": "string"
-          }
-        },
         {
           "abstract": true,
           "docs": {
@@ -4945,7 +4929,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 45
+            "line": 47
           },
           "name": "assetNameRoot",
           "optional": true,
@@ -4964,7 +4948,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 53
+            "line": 55
           },
           "name": "assetNameSuffix",
           "optional": true,
@@ -4983,7 +4967,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 62
+            "line": 64
           },
           "name": "deployerTimeout",
           "optional": true,
@@ -4991,6 +4975,24 @@
             "fqn": "aws-cdk-lib.Duration"
           }
         },
+        {
+          "abstract": true,
+          "docs": {
+            "remarks": "For child accounts this can be blank as it is retrieved from the parent Deployer",
+            "stability": "experimental",
+            "summary": "ARN of the IAM Role for the Edge to Origin Lambda Function."
+          },
+          "immutable": true,
+          "locationInModule": {
+            "filename": "src/MicroAppsChildDeployer.ts",
+            "line": 24
+          },
+          "name": "edgeToOriginRoleARN",
+          "optional": true,
+          "type": {
+            "primitive": "string"
+          }
+        },
         {
           "abstract": true,
           "docs": {
@@ -5002,7 +5004,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsChildDeployer.ts",
-            "line": 31
+            "line": 33
           },
           "name": "removalPolicy",
           "optional": true,
@@ -5692,6 +5694,28 @@
             }
           }
         },
+        {
+          "abstract": true,
+          "docs": {
+            "stability": "experimental",
+            "summary": "Additional IAM Role ARNs that should be allowed to invoke apps in child accounts."
+          },
+          "immutable": true,
+          "locationInModule": {
+            "filename": "src/MicroApps.ts",
+            "line": 317
+          },
+          "name": "edgeToOriginRoleARNs",
+          "optional": true,
+          "type": {
+            "collection": {
+              "elementtype": {
+                "primitive": "string"
+              },
+              "kind": "array"
+            }
+          }
+        },
         {
           "abstract": true,
           "docs": {
@@ -5806,7 +5830,7 @@
           "abstract": true,
           "docs": {
             "example": "[ 'AROA1234567890123' ]",
-            "remarks": "AROAs of the IAM Role to exclude from the DENY rules on the S3 Bucket Policy.\nThis allows sessions that assume the IAM Role to be excluded from the\nDENY rules on the S3 Bucket Policy.\n\nTypically any admin roles / users that need to view or manage the S3 Bucket\nwould be added to this list.\n\nRoles / users that are used directly, not assumed, can be added to `s3PolicyBypassRoleNames` instead.\n\nNote: This AROA must be specified to prevent this policy from locking\nout non-root sessions that have assumed the admin role.\n\nThe notPrincipals will only match the role name exactly and will not match\nany session that has assumed the role since notPrincipals does not allow\nwildcard matches and does not do wildcard matches implicitly either.\n\nThe AROA must be used because there are only 3 Principal variables available:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable\n  aws:username, aws:userid, aws:PrincipalTag\n\nFor an assumed role, aws:username is blank, aws:userid is:\n  [unique id AKA AROA for Role]:[session name]\n\nTable of unique ID prefixes such as AROA:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-prefixes\n\nThe name of the role is simply not available for an assumed role and, if it was,\na complicated comparison would be requierd to prevent exclusion\nof applying the Deny Rule to roles from other accounts.\n\nTo get the AROA with the AWS CLI:\n   aws iam get-role --role-name ROLE-NAME\n   aws iam get-user -–user-name USER-NAME",
+            "remarks": "AROAs of the IAM Role to exclude from the DENY rules on the S3 Bucket Policy.\nThis allows sessions that assume the IAM Role to be excluded from the\nDENY rules on the S3 Bucket Policy.\n\nTypically any admin roles / users that need to view or manage the S3 Bucket\nwould be added to this list.\n\nRoles / users that are used directly, not assumed, can be added to `s3PolicyBypassRoleNames` instead.\n\nNote: This AROA must be specified to prevent this policy from locking\nout non-root sessions that have assumed the admin role.\n\nThe notPrincipals will only match the role name exactly and will not match\nany session that has assumed the role since notPrincipals does not allow\nwildcard matches and does not do wildcard matches implicitly either.\n\nThe AROA must be used because there are only 3 Principal variables available:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable\n  aws:username, aws:userid, aws:PrincipalTag\n\nFor an assumed role, aws:username is blank, aws:userid is:\n  [unique id AKA AROA for Role]:[session name]\n\nTable of unique ID prefixes such as AROA:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-prefixes\n\nThe name of the role is simply not available for an assumed role and, if it was,\na complicated comparison would be requierd to prevent exclusion\nof applying the Deny Rule to roles from other accounts.\n\nTo get the AROA with the AWS CLI:\n   aws iam get-role --role-name ROLE-NAME\n   aws iam get-user --user-name USER-NAME",
             "see": "s3StrictBucketPolicy",
             "stability": "experimental",
             "summary": "Applies when using s3StrictBucketPolicy = true."
@@ -6242,7 +6266,7 @@
         },
         "locationInModule": {
           "filename": "src/MicroAppsSvcs.ts",
-          "line": 224
+          "line": 229
         },
         "parameters": [
           {
@@ -6272,7 +6296,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/MicroAppsSvcs.ts",
-        "line": 207
+        "line": 212
       },
       "name": "MicroAppsSvcs",
       "properties": [
@@ -6284,7 +6308,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsSvcs.ts",
-            "line": 215
+            "line": 220
           },
           "name": "deployerFunc",
           "overrides": "@pwrdrvr/microapps-cdk.IMicroAppsSvcs",
@@ -6300,7 +6324,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsSvcs.ts",
-            "line": 210
+            "line": 215
           },
           "name": "table",
           "overrides": "@pwrdrvr/microapps-cdk.IMicroAppsSvcs",
@@ -6316,7 +6340,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/MicroAppsSvcs.ts",
-            "line": 220
+            "line": 225
           },
           "name": "routerFunc",
           "optional": true,
@@ -6464,6 +6488,28 @@
             "fqn": "aws-cdk-lib.Duration"
           }
         },
+        {
+          "abstract": true,
+          "docs": {
+            "stability": "experimental",
+            "summary": "ARN of the IAM Role for the Edge to Origin Lambda Function."
+          },
+          "immutable": true,
+          "locationInModule": {
+            "filename": "src/MicroAppsSvcs.ts",
+            "line": 185
+          },
+          "name": "edgeToOriginRoleARN",
+          "optional": true,
+          "type": {
+            "collection": {
+              "elementtype": {
+                "primitive": "string"
+              },
+              "kind": "array"
+            }
+          }
+        },
         {
           "abstract": true,
           "docs": {
@@ -6541,7 +6587,7 @@
           "abstract": true,
           "docs": {
             "example": "[ 'AROA1234567890123' ]",
-            "remarks": "AROAs of the IAM Role to exclude from the DENY rules on the S3 Bucket Policy.\nThis allows sessions that assume the IAM Role to be excluded from the\nDENY rules on the S3 Bucket Policy.\n\nTypically any admin roles / users that need to view or manage the S3 Bucket\nwould be added to this list.\n\nRoles / users that are used directly, not assumed, can be added to `s3PolicyBypassRoleNames` instead.\n\nNote: This AROA must be specified to prevent this policy from locking\nout non-root sessions that have assumed the admin role.\n\nThe notPrincipals will only match the role name exactly and will not match\nany session that has assumed the role since notPrincipals does not allow\nwildcard matches and does not do wildcard matches implicitly either.\n\nThe AROA must be used because there are only 3 Principal variables available:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable\n  aws:username, aws:userid, aws:PrincipalTag\n\nFor an assumed role, aws:username is blank, aws:userid is:\n  [unique id AKA AROA for Role]:[session name]\n\nTable of unique ID prefixes such as AROA:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-prefixes\n\nThe name of the role is simply not available for an assumed role and, if it was,\na complicated comparison would be requierd to prevent exclusion\nof applying the Deny Rule to roles from other accounts.\n\nTo get the AROA with the AWS CLI:\n   aws iam get-role --role-name ROLE-NAME\n   aws iam get-user -–user-name USER-NAME",
+            "remarks": "AROAs of the IAM Role to exclude from the DENY rules on the S3 Bucket Policy.\nThis allows sessions that assume the IAM Role to be excluded from the\nDENY rules on the S3 Bucket Policy.\n\nTypically any admin roles / users that need to view or manage the S3 Bucket\nwould be added to this list.\n\nRoles / users that are used directly, not assumed, can be added to `s3PolicyBypassRoleNames` instead.\n\nNote: This AROA must be specified to prevent this policy from locking\nout non-root sessions that have assumed the admin role.\n\nThe notPrincipals will only match the role name exactly and will not match\nany session that has assumed the role since notPrincipals does not allow\nwildcard matches and does not do wildcard matches implicitly either.\n\nThe AROA must be used because there are only 3 Principal variables available:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable\n  aws:username, aws:userid, aws:PrincipalTag\n\nFor an assumed role, aws:username is blank, aws:userid is:\n  [unique id AKA AROA for Role]:[session name]\n\nTable of unique ID prefixes such as AROA:\n  https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-prefixes\n\nThe name of the role is simply not available for an assumed role and, if it was,\na complicated comparison would be requierd to prevent exclusion\nof applying the Deny Rule to roles from other accounts.\n\nTo get the AROA with the AWS CLI:\n   aws iam get-role --role-name ROLE-NAME\n   aws iam get-user --user-name USER-NAME",
             "see": "s3StrictBucketPolicy",
             "stability": "experimental",
             "summary": "Applies when using s3StrictBucketPolicy = true."
@@ -6776,6 +6822,6 @@
       "symbolId": "src/MicroAppsTable:MicroAppsTableProps"
     }
   },
-  "version": "0.4.0-alpha.11",
-  "fingerprint": "uOXB8qMkxR37QpDxf5CG3y83vTMivzpmBpK9KX/RFdI="
+  "version": "0.4.0-alpha.13",
+  "fingerprint": "DWXHX6oj5UJpamTw9wgiTVLPFcYLq+wz3SkY3Wd7zNI="
 }

package/API.md

@@ -979,14 +979,6 @@ Application environment, passed as `NODE_ENV` to the Router and Deployer Lambda
 
 ---
 
-##### `edgeToOriginRoleARN`<sup>Required</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsChildDeployerProps.edgeToOriginRoleARN"></a>
-
-- *Type:* `string`
-
-ARN of the IAM Role for the Edge to Origin Lambda Function.
-
----
-
 ##### `parentDeployerLambdaARN`<sup>Required</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsChildDeployerProps.parentDeployerLambdaARN"></a>
 
 - *Type:* `string`
@@ -1024,6 +1016,16 @@ For larger applications this needs to be set up to 2-5 minutes for the S3 copy
 
 ---
 
+##### `edgeToOriginRoleARN`<sup>Optional</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsChildDeployerProps.edgeToOriginRoleARN"></a>
+
+- *Type:* `string`
+
+ARN of the IAM Role for the Edge to Origin Lambda Function.
+
+For child accounts this can be blank as it is retrieved from the parent Deployer
+
+---
+
 ##### `removalPolicy`<sup>Optional</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsChildDeployerProps.removalPolicy"></a>
 
 - *Type:* [`aws-cdk-lib.RemovalPolicy`](#aws-cdk-lib.RemovalPolicy)
@@ -1330,6 +1332,14 @@ Additional edge lambda functions.
 
 ---
 
+##### `edgeToOriginRoleARNs`<sup>Optional</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsProps.edgeToOriginRoleARNs"></a>
+
+- *Type:* `string`[]
+
+Additional IAM Role ARNs that should be allowed to invoke apps in child accounts.
+
+---
+
 ##### `originRegion`<sup>Optional</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsProps.originRegion"></a>
 
 - *Type:* `string`
@@ -1432,7 +1442,7 @@ of applying the Deny Rule to roles from other accounts.
 
 To get the AROA with the AWS CLI:
    aws iam get-role --role-name ROLE-NAME
-   aws iam get-user -–user-name USER-NAME
+   aws iam get-user --user-name USER-NAME
 
 > s3StrictBucketPolicy
 
@@ -1655,6 +1665,14 @@ For larger applications this needs to be set up to 2-5 minutes for the S3 copy
 
 ---
 
+##### `edgeToOriginRoleARN`<sup>Optional</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsSvcsProps.edgeToOriginRoleARN"></a>
+
+- *Type:* `string`[]
+
+ARN of the IAM Role for the Edge to Origin Lambda Function.
+
+---
+
 ##### `httpApi`<sup>Optional</sup> <a name="@pwrdrvr/microapps-cdk.MicroAppsSvcsProps.httpApi"></a>
 
 - *Type:* [`@aws-cdk/aws-apigatewayv2-alpha.HttpApi`](#@aws-cdk/aws-apigatewayv2-alpha.HttpApi)
@@ -1730,7 +1748,7 @@ of applying the Deny Rule to roles from other accounts.
 
 To get the AROA with the AWS CLI:
    aws iam get-role --role-name ROLE-NAME
-   aws iam get-user -–user-name USER-NAME
+   aws iam get-user --user-name USER-NAME
 
 > s3StrictBucketPolicy
 

package/README.md

@@ -86,7 +86,7 @@ Note: requests can also be dispatched into the same account, but this model is m
   - Deploys the CDK Stack
   - Essentially runs two commands along with extraction of outputs:
     - `npx cdk deploy --context @pwrdrvr/microapps:deployReleaseApp=true microapps-basic`
-    - `npx microapps-publish publish --app-name release --new-version ${RELEASE_APP_PACKAGE_VERSION} --deployer-lambda-name ${DEPLOYER_LAMBDA_NAME} --app-lambda-name ${RELEASE_APP_LAMBDA_NAME} --static-assets-path node_modules/@pwrdrvr/microapps-app-release-cdk/lib/static_files/release/${RELEASE_APP_PACKAGE_VERSION}/ --overwrite --no-cache`
+    - `npx pwrdrvr publish --app-name release --new-version ${RELEASE_APP_PACKAGE_VERSION} --deployer-lambda-name ${DEPLOYER_LAMBDA_NAME} --app-lambda-name ${RELEASE_APP_LAMBDA_NAME} --static-assets-path node_modules/@pwrdrvr/microapps-app-release-cdk/lib/static_files/release/${RELEASE_APP_PACKAGE_VERSION}/ --overwrite --no-cache`
   - URL will be printed as last output
 
 # Limitations / Future Development
@@ -95,14 +95,6 @@ Note: requests can also be dispatched into the same account, but this model is m
   - For the time being this has only been implemented for AWS technologies and APIs
   - It is possible that Azure and GCP have sufficient support to enable porting the framework
   - CDK would have to be replaced as well (unless it's made available for Azure and GCP in the near future)
-- `microapps-publish` only supports Lambda function apps
-  - There is no technical reason for the apps to only run as Lambda functions
-  - Web apps could just as easily run on EC2, Kubernetes, EKS, ECS, etc
-  - Anything that API Gateway can route to can work for serving a MicroApp
-  - The publish tool needs to provide additional options for setting up the API Gateway route to the app
-- Authentication
-  - Authentication requires rolling your own API Gateway and CloudFront deployment at the moment
-  - The "turn key" CDK Construct should provide options to show an example of how authentication can be integrated
 - Release Rules
   - Currently only a Default rule is supported
   - Need to evaluate if a generic implementation can be made, possibly allowing plugins or webhooks to support arbitrary rules
@@ -181,13 +173,13 @@ With Lambda@Edge (even with Origin Requests) the cost is 3x higher per GB-second
 - [packages/microapps-datalib](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-datalib)
   - Installed from `npm`:
     - `npm i -g @pwrdrvr/microapps-datalib`
-  - APIs for access to the DynamoDB Table used by `microapps-publish`, `microapps-deployer`, and `@pwrdrvr/microapps-app-release-cdk`
+  - APIs for access to the DynamoDB Table used by the `pwrdrvr` CLI, `microapps-deployer`, and `@pwrdrvr/microapps-app-release-cdk`
 - [packages/microapps-deployer](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-deployer)
-  - Lambda service invoked by `microapps-publish` to record new app/version in the DynamoDB table, create API Gateway integrations, copy S3 assets from staging to prod bucket, etc.
+  - Lambda service invoked by the `pwrdrvr` CLI to record new app/version in the DynamoDB table, create API Gateway integrations, copy S3 assets from staging to prod bucket, etc.
   - Returns a temporary S3 token with restricted access to the staging S3 bucket for upload of the static files for one app/semver
-- [packages/microapps-publish](https://github.com/pwrdrvr/microapps-core/tree/main/packages/microapps-publish)
+- [packages/pwrdrvr](https://github.com/pwrdrvr/microapps-core/tree/main/packages/pwrdrvr)
   - Installed from `npm`:
-    - `npm i -g @pwrdrvr/microapps-publish`
+    - `npm i -g pwrdrvr`
   - Node executable that updates versions in config files, deploys static assets to the S3 staging bucket, optionally compiles and deploys a new Lambda function version, and invokes `microapps-deployer`
   - AWS IAM permissions required:
     - `lambda:InvokeFunction`
@@ -200,20 +192,20 @@ With Lambda@Edge (even with Origin Requests) the cost is 3x higher per GB-second
 
 # Creating a MicroApp Using Docker Lambda Functions
 
-Note: semi-deprecated as of 2022-01-27. Zip Lambda functions are better supported.
+Docker Lambdas are great for large applications.  These used to be slower to cold start but as of early 2023 that appears to no longer be an issue.
 
 ## Next.js Apps
 
-Create a Next.js app then follow the steps in this section to set it up for publishing to AWS Lambda @ Origin as a MicroApp. To publish new versions of the app use `npx microapps-publish --new-version x.y.z` when logged in to the target AWS account.
+Create a Next.js app then follow the steps in this section to set it up for publishing to AWS Lambda @ Origin as a MicroApp. To publish new versions of the app use `npx pwrdrvr --new-version x.y.z` when logged in to the target AWS account.
 
 ### Modify package.json
 
-Replace the version with `0.0.0` so it can be modified by the `microapps-publish` tool.
+Replace the version with `0.0.0` so it can be modified by the `pwrdrvr` CLI.
 
 ### Install Dependencies
 
 ```
-npm i --save-dev @pwrdrvr/microapps-publish
+npm i --save-dev pwrdrvr
 ```
 
 ### Dockerfile