What you’ll learn
  • what does the API project application represent
  • what are the necessary cloud infrastructure resources on which the API project application relies on

The API Project Application
anchor

The API project application represents your project’s GraphQL API, which is utilized by the Admin and Website applications.

But do note that the API application is more than just a simple GraphQL interface. The default Webiny applications not only define and extend the application’s GraphQL schema, but also introduce additional processes and cloud infrastructure resources in order to achieve their goal. For example, in order to serve files and optimize images, the File Manager application brings a couple of dedicated AWS Lambda functions.

Of course, the application can additionally grow in terms of application code and cloud infrastructure on your behalf, if need be.

Diagram
anchor

For brevity, the diagram doesn’t include network-level cloud infrastructure resources, like region, VPC, availability zones, and so on. Check out the Deployment Modes section if you’re interested in that aspect of the deployed cloud infrastructure.

Note that the stateful resources like Amazon S3, Amazon Cognito, Amazon DynamoDB and Amazon OpenSearch are deployed as part of the Core project application. These are still included in the diagram, just so it’s more clear to the reader.

Webiny Cloud Infrastructure - API - OverviewWebiny Cloud Infrastructure - API - Overview
(click to enlarge)

Description
anchor

The diagram gives an overview of the complete cloud infrastructure that is deployed by different Webiny applications, which together form the API project application.

  1. Security
  2. I18N
  3. File Manager
  4. Page Builder (with Prerendering Service)
  5. Form Builder
  6. Headless CMS
  7. Background Tasks

In the following text, we briefly cover how each of the different Webiny applications are utilizing the shown cloud infrastructure.

1. Security
anchor

Although the Security application does work with multiple identity providers, by default, it works with Amazon Cognito, hence its icon in the lower section of the diagram d. The identity checks are performed from the GraphQL Handler C AWS Lambda function.With Amazon Cognito, the application also extends the GraphQL schema located on the GraphQL Handler C.For storing data, the application relies on Amazon DynamoDB E.

2. I18N
anchor

The I18N application doesn’t bring any additional cloud infrastructure resources. It just expands the GraphQL schema with its own types and resolvers, so we can say only the GraphQL Handler AWS Lambda function C gets affected by it.For storing data, the application relies on Amazon DynamoDB E.

3. File Manager
anchor

Besides extending the GraphQL schema located on the GraphQL Handler AWS Lambda function c, the File Manager application also introduces a couple of dedicated AWS Lambda functions. These perform various file-related tasks like uploading, downloading, and also image optimizations. It also introduces a single Amazon S3 bucket G, in which the files are ultimately stored.For storing data and performing search queries, the application relies on Amazon DynamoDB E and Amazon OpenSearch Service F, respectively.

4. Page Builder (With Prerendering Service)
anchor

Besides extending the GraphQL schema, the Page Builder application also introduces a couple of AWS Lambda functions that are responsible for importing and exporting of pages.

Also, via an Amazon EventBridge (part of the Core project application, now shown on the diagram), it interacts with the prerendering service that’s deployed as part of the Website project application (more on this in the Website section.

For storing data and performing search queries, the application relies on Amazon DynamoDB E and Amazon OpenSearch Service F, respectively.

5. Form Builder
anchor

The Form Builder application doesn’t bring any additional cloud infrastructure resources. It just extends the GraphQL schema with its own types and resolvers, so we can say only the GraphQL Handler AWS Lambda function C gets affected by it.For storing data and performing search queries, the application relies on Amazon DynamoDB E and Amazon OpenSearch Service F, respectively.

6. Headless CMS
anchor

For storing data and performing search queries, the application relies on Amazon DynamoDB E and Amazon OpenSearch Service F, respectively.

Learn more about the Headless CMS API in the Headless CMS GraphQL API Overview article.

7. Background Tasks
anchor

For background tasks (jobs)-related requirements, Webiny relies on AWS Step Functionsexternal link and AWS Lambda. The Step Functions are used to orchestrate the execution of the background tasks, while a single AWS Lambda function is used to execute the tasks themselves.

Note that background tasks are triggered via an Amazon EventBridge event. Amazon EventBridge is deployed as part of the Core project application (not shown on the diagram).

For more information on how to create and execute background tasks, check out the Background Tasks article.

Additional Information
anchor

Separate HTTP and WebSockets Amazon API Gateway Instances
anchor

Webiny deploys two separate Amazon API Gateway B instances:
  1. one for HTTP requests
  2. one for WebSockets

This is done because Amazon API Gateway does not support both HTTP and WebSockets in a single instance, and Webiny needs both.

Both instances are utilized by different applications within the Admin Area project application. When it comes to Website, only the HTTP instance is used.

FAQ
anchor

Why Is Webiny Using AWS Lambda to Host a GraphQL Handler and Not AWS AppSync?
anchor

There are a couple of reason for that.

First, implementing a GraphQL Handler using AWS Lambda enables us and our users to make additional customizations to server’s behavior.

The default Webiny applications rely on this fact as well. For example, the I18N application gives you the ability to check what is the current locale that the user is on. The Security application gives you the ability to perform custom authentication and authorization checks inside of your resolvers. Finally, it also makes it possible for the Headless CMS application to generate different GraphQL schemas, based on the current I18N locale.

Secondly, you can test your GraphQL Handler easily with a testing library like Jestexternal link, as you would do with any other JavaScript piece of code.

Finally, this approach makes it much easier for Webiny to be hosted on not just one cloud infrastructure provider (AWS), but on many more, like Microsoft Azure or Google Cloud Platform.

Which GraphQL Implementation Are You Using?
anchor

We started with Apollo GraphQL Serverexternal link, but for Webiny version 5, we migrated to GraphQL toolsexternal link, because it’s more lightweight and both easier to implement and grasp.

Which Amazon API Gateway Is Deployed as Part of the API Application?
anchor

By default, we deploy HTTP APIsexternal link. This can be changed on your behalf, if need be.