Add new basepath mapping to custom domain

Hi I have the same use case as #114 where it would be great if i can get basepath mapping to multiple serverless apis for the same domain.

Would it be possible for the domain manager to assign a basepath mapping in the following way -

/projectA serverless.yml

service: project-a-api
...
custom:
      customDomian: api.projects.com
      basePath: 'projecta' 

/projectB serverless.yml

service: project-b-api
...
custom:
      customDomian: api.projects.com
      basePath: 'projectb' 

So here we have 2 serverless.yml both pointing to the same custom domain, however basePaths are different. In the API gateway settings, it’s possible to map a basepath to a API, in the case of serverless, it’s seems as though new APIs are generated for every serverless.yml

So for project b: Would the domain manager be able to see that project b is requesting to map itself with the custom domain and as the custom domain already exists, rather than creating it again/remapping the first basepath to projectb, it instead checks to see if projectb exists in api.projects.com basepath mappings, and if not then adds a new basepath mapping to the serverless.yml service?

[staslev]

@tsamaya thanks for the quick reply! Your confirmation triggered an extensive trial and error session which I believe has resulted in me understanding a bit better what was going on and I was eventually able to make things work.

The problem I was able to identify is that if you add the custom domain manager plugin and its customDomain section to an existing service (serverless.yml) without first performing sls remove (which removes its existing CloudFormation stack), then the base path mapping will NOT be set up.

This basically means that once one adds a custom domain configuration for the fist time one needs to make sure one runs sls remove && sls deploy --stage [stage], since sls deploy --stage [stage] alone will not get the job done.

Also, just for the record, I believe the createRoute53Record: true can be omitted from the individual services, and put only in a “parent” serverless.yml like so:

...
custom:
  customDomain:
    domainName: my.domain.com
    certificateName: 'myCertificate'
    createRoute53Record: true

Then, this parent serverless.yml may be invoked with sls create_domain just for the sake of creating a custom domain component to be used by all the individual services for that particular domain name.

Note that this parent serverless.yml may fail if it has no functions and you attempt sls deploy , but that’s fine, since you only need it for sls create_domain.

$ sls --version
1.32.0

[rddimon]

Hi there

Hope you are doing well and have already solved this issue!

@billydh you can take a look at preserveExternalPathMappings option in the latest version and let us know

The origin issue looks solved so closing it Feel free to reopen it in case of any related issue