AsyncAPI specification website
716
stars
3,287
commits
TypeScript
primary language
Sep 9, 2026
updated
This repository contains the sources of AsyncAPI website:
Use the following tools to set up the project:
Icons used across the AsyncAPI website are part of the AsyncAPI design system. All icons follow a 24px grid, 1.5px stroke outline style. To find and use icons:
Open the AsyncAPI design system Figma file
Right-click any icon β Copy as β SVG
Paste inline in your component
For the full icon audit, style rules, and contribution guidelines see the Icon System documentation.
Fork the repository by clicking on Fork option on top right of the main repository.
Open Command Prompt on your local computer.
Clone the forked repository by adding your own GitHub username in place of <username>.
For multiple contributions it is recommended to have proper configuration of forked repo.
git clone https://github.com/<username>/website/
cd website
npm install
npm run dev
Access the live development server at localhost:3000.
To run the storybook locally:
npm run dev:storybook
To bootstrap a new post, run this command:
npm run write:blog
Follow the interactive prompt to generate a post with pre-filled front matter.
In order to prepare and spin up a Gitpod dev environment for our project, we configured our workspace through a .gitpod.yml file.
To spin up a Gitpod codespace, go to http://gitpod.io/#https://github.com/asyncapi/website.
npm run build
Generated files of the website go to the .next folder.
npm run build:storybook
Generated files of the storybook go to the storybook-static folder.
After cloning repository to your local, run the docker compose in watch mode from the root of the repository.
docker compose up --watch
Now you're running AsyncAPI website in a development mode. Container is mapped with your local copy of the website. Whenever you make changes to the code, the website will refresh and changes visible in localhost:3000.
To minimize the duplication of content and make it easier to maintain, there are shared fragments you can use when working with Markdown files. These fragments are stored in the /assets/docs/fragments directory.
To include a fragment in a Markdown file:
Import the fragment at the top of the file (but below the frontmatter) using the following syntax:
import DesiredFragmentName from '@/assets/docs/fragments/fragmentYouWantToImport.md';
Add the imported fragment to the desired location in the Markdown file using the following syntax:
<DesiredFragmentName />
To lint the code, run the following command:
npm run lint
To fix the linting issues, run the following command:
npm run lint:fix
To lint the mdx files, run the following command:
npm run lint:mdx
To build and run a production-ready website, run the following command:
npm run build && npm run start
Generated files of the website go in the .next folder.
Start a local development server for the build tool using the configuration and environment variables set for local development with the Netlify CLI:
netlify dev
To start the server using the configuration and environment variables set for dev or all deploy contexts, run the following command:
netlify dev --context production
AsyncAPI Financial Summary page aims to provide transparency and clarity regarding the organization's financial activities. It serves as a platform to showcase how donations are accepted, different sponsorship options, and how the generated funds are utilized.
YAML files must be stored in the config/finance directory.
Create separate folders for each year under config/finance, such as config/finance/2023. Inside each year's folder, include two YAML files: Expenses.yml and ExpensesLink.yml.
In Expenses.yml, record expenses for each month, specifying the Category and Amount.
In ExpensesLink.yml, provide discussion links related to expense categories.
When a new year begins, create a corresponding folder for that year under config/finance and place the YAML files inside the folder for that specific year. For example, create a folder named config/finance/2024 for the year 2024 and config/finance/2025 for the year 2025. Place the YAML file for each respective year inside its designated folder.
Modify the years within the scripts/finance/index.js , lib/getUniqueCategories.js and components/FinancialSummary/BarChartComponent.js to handle data for different years effectively.
A case study is a special document that any end-user company can provide. An end-user company is a company that uses AsyncAPI to solve technical challenges. A case study is not a document where a vendor company can describe how they build their commercial AsyncAPI-based product. On the other hand, it is completely fine if a case study of some end-user mentions some commercial tools that helped them to work with AsyncAPI or event-driven architecture. An example of such a case can be a case study from an end-user where at some point, Confluent Schema Registry is mentioned in an explanation about schemas and runtime message validation.
A case study is documented in the form of a YAML file. Anyone can open a pull request with a new case study.
config/casestudies.public/resources/casestudies directory.public/img/casestudies.Once you collect all information and create a case study, open a pull request. It must be authored or at least approved by a representative of the given company. Such a representative is probably already a contact person mentioned in the case study.
A case study becomes publicly available right after merging and rebuilding the website.
All AsyncAPI JSON Schema definition files are being served within the /definitions/<file> path. The content is being served from GH, in particular from https://github.com/asyncapi/spec-json-schemas/tree/master/schemas.
This is possible thanks to the following:
/definitions/<file> path, serving the content from GH without having an HTTP redirect.Content-Type header of the rewrite response to become application/schema+json. This lets tooling, such as Hyperjump, to fetch the schemas directly from their URL.flowchart TD
Request(Request) -->schema-related{Is it requesting Schemas?}
schema-related -->|No| req_no_schemas[Let the original request go through]
req_no_schemas --> Response(Response)
schema-related -->|Yes| req_schemas[Fetch from GitHub]
req_schemas-->req_json{Was requesting a .json file?}
req_json -->|No| Response(Response)
req_json -->|Yes| response_status{Response Status?}
response_status -->|2xx| response_ok[OK]
response_status -->|304| response_cached[Not Modified]
response_status -->|Any other| response_ko
response_ok --> set_headers[Set Response Content-Type header to application/schema+json]
set_headers --> send_metric_success[Send success metric]
response_cached -- cached:true --> send_metric_success
response_ko --> send_metric_error[Send error metric]
send_metric_success -- file served from raw GH --> Response(Response)
send_metric_error --the errored response --> Response(Response)
This repository has the following structure:
βββ .github # Definitions of GitHub workflows, pull request and issue templates
βββ .storybook # Storybook configuration for UI components
βββ assets # Various assets
| βββ docs # Documentation assets
| | fragments # Documentations for CLI installation and contribution.
βββ cheatsheet # Markdown based cheatsheets used in the website
βββ components # Various generic components such as "Button", "Figure", etc.
βββ config # Transformed static data to display on the pages such as blog posts etc.
βββ context # Various React's contexts used in website
βββ cypress # End-to-end tests for the website
βββ development # Development utilities and helper scripts
βββ docs # Documentation related resources
βββ locales # Translations for the website
βββ markdown # Markdown files for the website
βββ about # Markdown files for the /about page
βββ blog # Markdown files for the blog posts
βββ docs # Markdown files for the /docs/* pages
βββ netlify # Contains Netlify serverless functions to run on Netlify
βββ pages # Website's pages source. It includes raw markdown files and React page templates.
β βββ about # Raw blog for /about page
β βββ blog # Blog posts
β βββ docs # Blog for /docs/* pages
β βββ tools # Various pages to describe tools
βββ public # Data for site metadata and static blog such as images
βββ scripts # Scripts used in the build and dev processes
βββ styles # Various CSS files
βββ templates # Various template markdown files
βββ tests # Test files for the project
βββ types # Various TypeScript types used in the website
βββ utils # Various JS code for preparing static data to render in pages
βββ next.config.mjs # Next.js configuration file
βββ README.md # Project's README file
βββ tailwind.config.ts # TailwindCSS configuration file
βββ tsconfig.json # TypeScript configuration file
This project's source code is licensed under the Apache License, Version 2.0. A copy of the license is available in LICENSE file.
This project's documentation is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0). A copy of the license is available in LICENSE-docs.
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
(top 30 of 323)
TypeScript
93.7%
JavaScript
4.2%
CSS
1.1%
AsyncAPI specification website
716
stars
3,287
commits
TypeScript
primary language
Sep 9, 2026
updated
This repository contains the sources of AsyncAPI website:
Use the following tools to set up the project:
Icons used across the AsyncAPI website are part of the AsyncAPI design system. All icons follow a 24px grid, 1.5px stroke outline style. To find and use icons:
Open the AsyncAPI design system Figma file
Right-click any icon β Copy as β SVG
Paste inline in your component
For the full icon audit, style rules, and contribution guidelines see the Icon System documentation.
Fork the repository by clicking on Fork option on top right of the main repository.
Open Command Prompt on your local computer.
Clone the forked repository by adding your own GitHub username in place of <username>.
For multiple contributions it is recommended to have proper configuration of forked repo.
git clone https://github.com/<username>/website/
cd website
npm install
npm run dev
Access the live development server at localhost:3000.
To run the storybook locally:
npm run dev:storybook
To bootstrap a new post, run this command:
npm run write:blog
Follow the interactive prompt to generate a post with pre-filled front matter.
In order to prepare and spin up a Gitpod dev environment for our project, we configured our workspace through a .gitpod.yml file.
To spin up a Gitpod codespace, go to http://gitpod.io/#https://github.com/asyncapi/website.
npm run build
Generated files of the website go to the .next folder.
npm run build:storybook
Generated files of the storybook go to the storybook-static folder.
After cloning repository to your local, run the docker compose in watch mode from the root of the repository.
docker compose up --watch
Now you're running AsyncAPI website in a development mode. Container is mapped with your local copy of the website. Whenever you make changes to the code, the website will refresh and changes visible in localhost:3000.
To minimize the duplication of content and make it easier to maintain, there are shared fragments you can use when working with Markdown files. These fragments are stored in the /assets/docs/fragments directory.
To include a fragment in a Markdown file:
Import the fragment at the top of the file (but below the frontmatter) using the following syntax:
import DesiredFragmentName from '@/assets/docs/fragments/fragmentYouWantToImport.md';
Add the imported fragment to the desired location in the Markdown file using the following syntax:
<DesiredFragmentName />
To lint the code, run the following command:
npm run lint
To fix the linting issues, run the following command:
npm run lint:fix
To lint the mdx files, run the following command:
npm run lint:mdx
To build and run a production-ready website, run the following command:
npm run build && npm run start
Generated files of the website go in the .next folder.
Start a local development server for the build tool using the configuration and environment variables set for local development with the Netlify CLI:
netlify dev
To start the server using the configuration and environment variables set for dev or all deploy contexts, run the following command:
netlify dev --context production
AsyncAPI Financial Summary page aims to provide transparency and clarity regarding the organization's financial activities. It serves as a platform to showcase how donations are accepted, different sponsorship options, and how the generated funds are utilized.
YAML files must be stored in the config/finance directory.
Create separate folders for each year under config/finance, such as config/finance/2023. Inside each year's folder, include two YAML files: Expenses.yml and ExpensesLink.yml.
In Expenses.yml, record expenses for each month, specifying the Category and Amount.
In ExpensesLink.yml, provide discussion links related to expense categories.
When a new year begins, create a corresponding folder for that year under config/finance and place the YAML files inside the folder for that specific year. For example, create a folder named config/finance/2024 for the year 2024 and config/finance/2025 for the year 2025. Place the YAML file for each respective year inside its designated folder.
Modify the years within the scripts/finance/index.js , lib/getUniqueCategories.js and components/FinancialSummary/BarChartComponent.js to handle data for different years effectively.
A case study is a special document that any end-user company can provide. An end-user company is a company that uses AsyncAPI to solve technical challenges. A case study is not a document where a vendor company can describe how they build their commercial AsyncAPI-based product. On the other hand, it is completely fine if a case study of some end-user mentions some commercial tools that helped them to work with AsyncAPI or event-driven architecture. An example of such a case can be a case study from an end-user where at some point, Confluent Schema Registry is mentioned in an explanation about schemas and runtime message validation.
A case study is documented in the form of a YAML file. Anyone can open a pull request with a new case study.
config/casestudies.public/resources/casestudies directory.public/img/casestudies.Once you collect all information and create a case study, open a pull request. It must be authored or at least approved by a representative of the given company. Such a representative is probably already a contact person mentioned in the case study.
A case study becomes publicly available right after merging and rebuilding the website.
All AsyncAPI JSON Schema definition files are being served within the /definitions/<file> path. The content is being served from GH, in particular from https://github.com/asyncapi/spec-json-schemas/tree/master/schemas.
This is possible thanks to the following:
/definitions/<file> path, serving the content from GH without having an HTTP redirect.Content-Type header of the rewrite response to become application/schema+json. This lets tooling, such as Hyperjump, to fetch the schemas directly from their URL.flowchart TD
Request(Request) -->schema-related{Is it requesting Schemas?}
schema-related -->|No| req_no_schemas[Let the original request go through]
req_no_schemas --> Response(Response)
schema-related -->|Yes| req_schemas[Fetch from GitHub]
req_schemas-->req_json{Was requesting a .json file?}
req_json -->|No| Response(Response)
req_json -->|Yes| response_status{Response Status?}
response_status -->|2xx| response_ok[OK]
response_status -->|304| response_cached[Not Modified]
response_status -->|Any other| response_ko
response_ok --> set_headers[Set Response Content-Type header to application/schema+json]
set_headers --> send_metric_success[Send success metric]
response_cached -- cached:true --> send_metric_success
response_ko --> send_metric_error[Send error metric]
send_metric_success -- file served from raw GH --> Response(Response)
send_metric_error --the errored response --> Response(Response)
This repository has the following structure:
βββ .github # Definitions of GitHub workflows, pull request and issue templates
βββ .storybook # Storybook configuration for UI components
βββ assets # Various assets
| βββ docs # Documentation assets
| | fragments # Documentations for CLI installation and contribution.
βββ cheatsheet # Markdown based cheatsheets used in the website
βββ components # Various generic components such as "Button", "Figure", etc.
βββ config # Transformed static data to display on the pages such as blog posts etc.
βββ context # Various React's contexts used in website
βββ cypress # End-to-end tests for the website
βββ development # Development utilities and helper scripts
βββ docs # Documentation related resources
βββ locales # Translations for the website
βββ markdown # Markdown files for the website
βββ about # Markdown files for the /about page
βββ blog # Markdown files for the blog posts
βββ docs # Markdown files for the /docs/* pages
βββ netlify # Contains Netlify serverless functions to run on Netlify
βββ pages # Website's pages source. It includes raw markdown files and React page templates.
β βββ about # Raw blog for /about page
β βββ blog # Blog posts
β βββ docs # Blog for /docs/* pages
β βββ tools # Various pages to describe tools
βββ public # Data for site metadata and static blog such as images
βββ scripts # Scripts used in the build and dev processes
βββ styles # Various CSS files
βββ templates # Various template markdown files
βββ tests # Test files for the project
βββ types # Various TypeScript types used in the website
βββ utils # Various JS code for preparing static data to render in pages
βββ next.config.mjs # Next.js configuration file
βββ README.md # Project's README file
βββ tailwind.config.ts # TailwindCSS configuration file
βββ tsconfig.json # TypeScript configuration file
This project's source code is licensed under the Apache License, Version 2.0. A copy of the license is available in LICENSE file.
This project's documentation is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0). A copy of the license is available in LICENSE-docs.
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
(top 30 of 323)
TypeScript
93.7%
JavaScript
4.2%
CSS
1.1%