One thing that API Gateway supports but you can’t do with AppSync out-of-the-box yet is custom domain names. Your shiny new AppSync API is available at , but you really want people to use your own domain instead because is much more memorable and informative. XYZ.appsync-api.us-east-1.amazonaws.com/graphql dev.example.com/graphql In this post, let’s look at two ways you can do this. I previously wrote about five reasons you should consider AppSync over API Gateway. . Check out the article here 1. CloudFront This is my preferred way. It’s . easy to set up and cheap to run Assuming your AppSync API resource is called (if you use the with the Serverless framework, then this is the logical id it’ll use). This is the CloudFormation resource you need to configure to route traffic to the AppSync API. GraphQlApi serverless-appsync-plugin AppSyncDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Origins: - Id: AppSync DomainName: Fn: :Select: - '2' - Fn: :Split: - "/" - Fn: :GetAtt: - GraphQlApi - GraphQLUrl CustomOriginConfig: HTTPPort: 80 HTTPSPort: 443 OriginProtocolPolicy: https-only OriginSSLProtocols: - TLSv1 - TLSv1.1 - TLSv1.2 OriginPath: '' Enabled: true HttpVersion: http2 Comment: CloudFront distribution for the Patient AppSync API Aliases: - <INSERT DOMAIN NAME HERE, e.g. dev.example.com> PriceClass: PriceClass_100 DefaultCacheBehavior: AllowedMethods: - HEAD - OPTIONS - GET - DELETE - POST - PUT - PATCH CachedMethods: - HEAD - OPTIONS - GET ForwardedValues: QueryString: true Headers: - x-api-key - Authorization Cookies: Forward: all MinTTL: 0 DefaultTTL: 0 TargetOriginId: AppSync ViewerProtocolPolicy: redirect-to-https Compress: true CustomErrorResponses: [] ViewerCertificate: AcmCertificateArn: <INSERT ARN HERE> SslSupportMethod: sni-only If you’re using the , then you should also check out the plugin. It can make things a lot easier for you. However, at the time of writing, it makes assumptions about the logical Id of the AppSync API (it expects ) as it’s intended to used alongside the aforementioned . Serverless framework serverless-appsync-cloudfront GraphQlApi serverless-appsync-plugin 2. API Gateway Another way you can do this is through API Gateway. You can set up an HTTP proxy that routes traffic to the AppSync API, and then configure a custom domain name in API Gateway. Compared to using CloudFront, this approach takes more work to set up and incurs higher cost and latency (compared to using CloudFront) because every request has to go through API Gateway. If you’re using the Serverless framework, then another stumbling block is that you can’t declare an API Gateway without any Lambda functions. Luckily, you can work around this by bringing SAM’s macro into the like in . easily AWS::Serverless-2016–10–31 serverless.yml this post This lets you configure API Gateway using SAM’s resource type. AWS::Serverless::Api ApiGateway: Type: AWS::Serverless::Api Properties: Name: AppSyncApiProxy StageName: dev OpenApiVersion: "3.0.1" DefinitionBody: openapi: "3.0.1" paths: /{proxy+}: "x-amazon-apigateway-any-method": consumes: - "application/json" produces: - "application/json" parameters: - name: proxy in: path required: true type: string x-amazon-apigateway-integration: uri: Fn: :Join: - '' - - 'https://' - Fn: :Select: - '2' - Fn: :Split: - "/" - Fn: :GetAtt: - GraphQlApi - GraphQLUrl - '/{proxy}' passthroughBehavior: when_no_match httpMethod: ANY type: http_proxy requestParameters: integration.request.path.proxy : method.request.path.proxy EndpointConfiguration: REGIONAL ApiGatewayDomainName: Type: AWS::ApiGateway::DomainName Properties: DomainName: <INSERT DOMAIN NAME> EndpointConfiguration: Types: - REGIONAL RegionalCertificateArn: <INSERT ARN HERE> ApiGatewayBasePathMapping: Type: AWS::ApiGateway::BasePathMapping DependsOn: - ApiGatewayDomainName Properties: DomainName: <INSERT DOMAIN NAME> RestApiId: !Ref ApiGateway Stage: !Ref ApiGateway.Stage One thing to note here is that, by default, SAM creates an API Gateway stage called . This appears to be a long-standing bug with SAM and the workaround is to set to . Stage OpenApiVersion 3.0.1 Route53 As a final step for both of these approaches, you need to configure a Route53 record for them in your hosted zone. For CloudFront, you need something like this: For API Gateway, you need to capture the for the custom domain (in API Gateway) and configure a Route53 record against it. API Gateway domain name You can also configure these using CloudFormation. Summary With both of these approaches, you can create a custom domain name (such as ) for AppSync. Callers can access your AppSync API via which is much more user-friendly and memorable. dev.example.com dev.example.com/graphql As mentioned above, I prefer the CloudFront approach because it’s easier to configure and has a negligible cost overhead. Previously published at https://theburningmonk.com/2020/09/how-to-set-up-custom-domain-names-for-appsync/

Alongside

Amazon

Modeling Hierarchical Access With AppSync In 3 Simple Steps

6 Tips To Scale an AppSync Project To 200+ Resolvers That Will Blow Your Mind

Ask me for help about serverless

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

How to Set up Custom Domain Names for AppSync

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

6 Tips To Scale an AppSync Project To 200+ Resolvers That Will Blow Your Mind

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

6 Tips To Scale an AppSync Project To 200+ Resolvers That Will Blow Your Mind

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps