domain manager fails to work when an api gateway resource is defined (only)

[bebbi]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Bug Report

Error Description

If I have a separate serverless file with only an api gw definition and exports, why am I not able to run serverless-domain-manager on it? It seems confusing to me that it requires a lambda be present: the base-path mapping seems to live on the gateway and once I have it, other services importing the gateway will be reachable under the same domain.

It appears to be a bug to me that I cannot add the base path mapping to an api gateway if there is no lambda definition in there, because it breaks clean modularization.

Reviving #217 here because I thought about the dummy lambda but it seemed like a work-around than a resolution.
@sampsasaarela Very fortunately I'm not on latest yet and #219 didn't happen to me 😅.

Command Run
When deploying with the domain manager plugin with an api gateway resource but no lambdas such as in the linked example,
sls create_domain works
sls deploy complains about missing deployment.

Domain Manager Configuration

custom:
  customDomain:
    domainName: ${self:custom.apiFQDN}
    stage: whatever
    basePath: ''
    createRoute53Record: true
    enabled: true

Versions

• Domain Manager version(s): 2.6.13
• Node/npm version: 8.12.0/yarn 1.15.2
• Serverless Version: 1.40
• Lambda Code: js

[bebbi]

After lots of playing with #217, with 2 apis and one gateway definition as above, for some reason it doesn't work adding the domain manager to the api-gateway definition and have no domain-manager plugin in the two api definitions (deploy works, resolution for both apis doesn't work).
However, adding the domain manager to the first api that is deployed after the gateway works, also for resolution of the second one.

[bebbi]

@rddimon Do you know if this issue is resolved? I.e., is it now possible to use domain manager on a naked gateway without lambdas?

[rddimon]

@bebbi Hey, could you please try the latest version and the workaround from #217?

[bebbi]

@rddimon After a lot of playing I noticed a key issue:

As soon as the serverless file that defines the shared api gateway gets a function definition for the dummy handler, it will create a second api gateway in addition to the one in resources, which will then receive domain manager's full attention.

The way to avoid that is to "self-reference" the resources api gateway in the api gateway file using a section like this inside provider which is essentially the same we put in the serverless file of the other apis:

provider:
  apiGateway:
    restApiId:
      'Fn::ImportValue': ${self:custom.apiGwRestApiId}
    restApiRootResourceId:
      'Fn::ImportValue': ${self:custom.apiGwRootResourceId}

Then only things start to stay in sync.

Would it be possible to change the domain manager logic so the dummy lambdas and all this additional complexity can be avoided?

[bebbi]

@rddimon I note an additional issue which is blocking for this workaround:

The above accidentally worked when playing with an existing api gateway stack.

However when creating a new stack, deployment of the dummy endpoint fails with this error:

No export named <name of rootResourceId in Outputs> found.

..which seems correct as there is no stack yet to import the values from. They are from this section:

Outputs:
  apiGatewayRestApiId:
    Value:
      Ref: ApiGateway
    Export:
      Name: ${self:custom.apiGwRestApiId}
  apiGatewayRestApiRootResourceId:
    Value:
      Fn::GetAtt:
        - ApiGateway
        - RootResourceId
    Export:
      Name: ${self:custom.apiGwRootResourceId}

To work around this, I need a convoluted deploy process:

1. comment out the apiGateway block in the provider.
2. run sls deploy (which creates 2 api gateways and assigns the domain to the wrong one)
3. run sls delete_domain

..to avoid the error

An error occurred: ApiGatewayRestApi - Deleting RestApi xxxx failed.
Please remove all base path mappings related to the RestApi in your domains: <url> (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: xxxx; Proxy: null).

4. Remove commenting from the apiGateway block again.
5. Then deploy again after waiting for the stack.

.. and finally, it works!

Is this how the separate gateway is expected to work?
Or can you suggest how to simplify this, perhaps a way of using in-file references from apiGateway to the gateway defined in resources?

[rddimon]

Hi @bebbi

It's no activity for a long time and hope you have found a solution!
I have just realized that you have this issue with version 2.6.13 and we have released support of Fn::ImportValue in version 4.2.2
I believe it should solve the issue but please Domain Manager version 5.x or above those versions also support Fn::ImportValue

Closing it but feel free to reopen it in case of any related issues

[bebbi]

Hi @rddimon, it's been a while since I started that issue. I believe I was on "^5.1.0" while on that last issue comment. Something that would help might be a simple example of how to add this plugin to a serverless config that has no endpoints (just preparing its config for other, separate api configs). Thanks in any case!

[rddimon]

Hi @bebbi

You can a look at the enabled option it might help you.

Also, in case you have any kind of solution for the issue, which you solved, you can create a PR with changes.
We will review and merge it.