Proxying API Gateway Lambdas

manage-frontend has a standardised mechanism for proxying API Gateway frontend Lambdas from guardian/support-service-lambdas, notably...

• holiday-stop-api
• delivery-records-api
• cancellation-sf-cases-api

Following guardian/manage-frontend/pull/351, we use CloudFormation and APIGateway clients of the aws-sdk to 'discover' by name the API gateway hostnames and API keys, rather than having to maintain that config in S3 or ParameterStore.

As with all AJAX calls made by the client, we proxy services (see wiki/Server-side-Proxying for general rationale), and in this case...

• adds the x-api-key header using the retrieved API keys (see above)

• adds the x-identity-id header using the value which came from IDAPI (see wiki/Identity-Integration)

• selects the host for the right STAGE instance of the API Gateway Lambda, based on the X-Gu-Membership-Test-User header sent from the client to the Node backend and denotes whether the user is a test-user

  Stage of manage-frontend	normal mode	test user mode
  DEV (local machine)	DEV Lambda* (DEV SF/Zuora)	CODE Lambda (UAT SF/Zuora)
  CODE	DEV Lambda* (DEV SF/Zuora)	CODE Lambda (UAT SF/Zuora)
  PROD	PROD Lambda (DEV SF/Zuora)	CODE Lambda (UAT SF/Zuora)

  * Yes indeed there is a DEV Stack for the lambda, which is available in riff-raff as of guardian/prism/pull/75

We do it this way so that the lambdas can be simpler (in that they don't need to understand cookies, connect to IDAPI or understand test-user - because manage-frontend has already done all that stuff) - so we just invoke the correct instance of the lambda.

It also means the lambdas can remain able to understand other ways to identify contacts (such as x-salesforce-contact-id header - which is used when Salesforce makes callouts to these Lambdas).