This repository contains the sources of AsyncAPI website:
Use the following tools to set up the project:
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
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.
To build a production-ready website, run the following command:
npm run build
Generated files of the website go to the .next
folder.
After cloning repository to your local, perform the following steps from the root of the repository.
docker build -t asyncapi-website .`
docker run --rm -it -v "$PWD":/async -p 3000:3000 asyncapi-website
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 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.A Netlify Edge Function that modifies the 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.
Please find a flowchart explaining the flow this edge function should accomplish:
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
├── assets # Various assets
| ├── docs # Documentation assets
| | fragments # Docuentations for CLI installation and contribution.
├── 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
├── 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
├── 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.js # TailwindCSS configuration file
└── tsconfig.json # TypeScript configuration file
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!