diff --git a/config/casestudies/hdi.yml b/config/casestudies/hdi.yml index 521f8aa9004..9d43467d0d1 100644 --- a/config/casestudies/hdi.yml +++ b/config/casestudies/hdi.yml @@ -4,29 +4,31 @@ company: description: The HDI brand operates in Germany and internationally, offering life and property/casualty insurance services. They cater to both private individuals and corporate clients, and have been providing industrial insurance since 2016. customers: "5000" industry: Insurance - revenue: 9.1 Mrd. EUR + revenue: 9.1B EUR website: https://www.hdi.global/ logo: /img/casestudies/hdi/hdi_logo.svg contact: - name: Vladislav Zwenihorodski link: https://www.linkedin.com/in/vladislav-zwenihorodski-9680a1209/ challenges: | - The HDI has various platform teams, among them the Integration Platform Team, which offers three products: Azure API Management, Azure Event Hub, and the Azure Service Bus. - For synchronous communication, we already use OpenAPI, as such we want to ensure the same level of transparency and discoverability for asynchronous scenarios as well. - Our central platform team offers the Azure Service Bus with self-service capabilities. - Customers are able to manage their own topics and subscriptions by simply modifying the according values in their repositories. - This means that most of the data required to document asynchronous communication is already available, although distributed between different repositories. - This necessitated the creation of a comprehensive catalog of existing topics, allowing potential subscribers easy access to messages from any topics of their choosing. + The HDI has various platform teams, among them the Integration Platform team, which offers three products: Azure API Management, Azure Event Hub, and the Azure Service Bus. + For synchronous communication OpenAPI is used as a standard. For asynchronous scenarios we want to use AsyncAPI to achieve the same level of transparency and discoverability. + We as platform team offer the Azure Service Bus with self-service capabilities. Our customers are able to manage their own topics and subscriptions by maintaining a custom + configuration model in a GitOps fashion. + We want to establish AsyncAPI as documentation standard in HDI's organization. Information about the available message formats and topics is already available in distributed + sources (e.g. repositories) and needs to be aggregated. + To achieve discoverability the creation of a comprehensive catalog of existing topics is necessary, allowing potential subscribers access to information about + messages from the available topics, so they can choose which ones to subscribe to. solution: | - The solution was to create an an AsyncAPI document where each topic owned by the customer is represented as a channel. - This document is automatically generated by a pipeline whenever there's a change in the topic configuration. + The solution is to create AsyncAPI documents where each topic owned by the customer is represented as a channel. + As we are using the GitOps setup it is straightforward to run pipeline whenever there is a change (commit) in the topic configuration. The necessary information is read from the customer repositories and then passed to a bash script as input. After successful creation, this file, along with a generated markdown for it, is saved within a documentation repository. This documentation repository serves as the basis for our Azure DevOps wiki, ensuring that all project documentation is centralized and easily accessible. - This ensures that the information is readily accessible to every developer, allowing easy access to messages from any topics of their choosing. - This approach makes our asynchronous communication is as transparent and discoverable as our synchronous communication. + As the documentation wiki is public the information is accessible to every developer, allowing easy access to messages from any topics of their choice. + This approach makes our asynchronous communication as transparent and discoverable as our synchronous communication. technical: #We need some more technical information related to case study. languages: - java, .net, bash @@ -198,7 +200,9 @@ asyncapi: #More specific details about AsyncAPI itself and how is it used. usecase: | - The AsyncAPI documents are used for documentation purposes by the platform team. It provides a comprehensive overview of the asynchronous communication in our system, including the available topics and the structure of the messages. - - (Future Plans) The AsyncAPI document will be used to generate Java DTOs using the AsyncAPI Java generator, ensuring type safety and clear data structure understanding. + - (Outlook) The AsyncAPI document will be used to generate Java DTOs, ensuring type safety and clear data structure understanding. + - (Outlook) Having the AsyncAPI documents at hand we are currently planning to use them to configure an internal developer portal (IDP) that will aggregate async and sync APIs among other things. + - (Outlook) Evaluate if replacing the custom configuration model and use AsyncAPI documents in the center to configure asynchronous communication instead. versions: - '3.0.0' storage: | @@ -209,7 +213,7 @@ asyncapi: #More specific details about AsyncAPI itself and how is it used. This pipeline uses a bash script to read the updated configuration from the customer's repository. It then generates a new AsyncAPI document reflecting these changes. - The AsyncAPI document is validated using the AsyncAPI CLI to confirm that the document is correctly formatted and adheres to the AsyncAPI specification right after creation and befor being commited to the documentation repository. + The AsyncAPI document is validated using the AsyncAPI CLI to confirm that the document is correctly formatted and adheres to the AsyncAPI specification right after creation and before being commited to the documentation repository. maintainers: | Customers maintain this document automatically by maintaining their own topic configurations. audience: #Specify if AsyncAPI audience is internal or external or both. diff --git a/markdown/blog/asyncapi-github-actions.md b/markdown/blog/asyncapi-github-actions.md index 54d0c365508..1af6c08c183 100644 --- a/markdown/blog/asyncapi-github-actions.md +++ b/markdown/blog/asyncapi-github-actions.md @@ -16,7 +16,7 @@ excerpt: AsyncAPI community got rich with two GitHub Actions that you can use fo --- > tl;dr -> AsyncAPI community got rich with two GitHub Actions that you can use for [validation](https://github.com/marketplace/actions/asyncapi-github-action) and [generation](https://github.com/marketplace/actions/generator-for-asyncapi-documents). +> AsyncAPI community got rich with two GitHub Actions that you can use for [validation](https://github.com/marketplace/actions/asyncapi-github-action) and [generation](https://github.com/marketplace/actions/generator-validator-converter-and-others-all-in-one-for-your-asyncapi-docs). GitHub organized a [hackathon for GitHub Actions](https://githubhackathon.com/#hackathon). There is no better reason to work on a solution if there is a bag of swags waiting for you @@ -25,7 +25,7 @@ The hackathon was only a trigger, the right moment to decide that we should enga Two AsyncAPI related actions we crafted in March are: - Our community member, [Waleed Ashraf](https://twitter.com/WaleedAshraf01/) created [an action](https://github.com/marketplace/actions/asyncapi-github-action) to validate AsyncAPI documents with our [parser](https://github.com/asyncapi/parser-js/) -- We also created [official AsyncAPI action](https://github.com/marketplace/actions/generator-for-asyncapi-documents) for our [generator](https://github.com/asyncapi/generator/). +- We also created [official AsyncAPI action](https://github.com/marketplace/actions/generator-validator-converter-and-others-all-in-one-for-your-asyncapi-docs) for our [generator](https://github.com/asyncapi/generator/). ## Writing a GitHub Action diff --git a/markdown/blog/status-update-47-20.md b/markdown/blog/status-update-47-20.md index 0f8edc497c1..1265e9b470b 100644 --- a/markdown/blog/status-update-47-20.md +++ b/markdown/blog/status-update-47-20.md @@ -39,7 +39,7 @@ Try out the project by following :point_down: instructions: ### Generator GitHub Action 1.0 -Yes, our official [GitHub Action for Generator](https://github.com/marketplace/actions/generator-for-asyncapi-documents) already uses the latest Generator and is released under v1. +Yes, our official [GitHub Action for Generator](https://github.com/marketplace/actions/generator-validator-converter-and-others-all-in-one-for-your-asyncapi-docs) already uses the latest Generator and is released under v1. ```yaml - name: Generating HTML from my AsyncAPI document diff --git a/pages/community/tsc.tsx b/pages/community/tsc.tsx index 755652736f1..03040adfa4b 100644 --- a/pages/community/tsc.tsx +++ b/pages/community/tsc.tsx @@ -1,5 +1,4 @@ import { sortBy } from 'lodash'; -import React, { useState } from 'react'; import type { Tsc } from '@/types/pages/community/Community'; @@ -66,11 +65,9 @@ function addAdditionalUserInfo(user: Tsc) { * @returns The Twitter SVG component. */ function TwitterSVG() { - const [isHovered, setIsHovered] = useState(false); - return ( -
setIsHovered(true)} onMouseLeave={() => setIsHovered(false)}> - +
+
); } @@ -81,11 +78,9 @@ function TwitterSVG() { * @returns The GitHub SVG component. */ function GitHubSVG() { - const [isHovered, setIsHovered] = useState(false); - return ( -
setIsHovered(true)} onMouseLeave={() => setIsHovered(false)}> - +
+
); } @@ -96,12 +91,9 @@ function GitHubSVG() { * @returns The LinkedIn SVG component. */ function LinkedInSVG() { - const [isHovered, setIsHovered] = useState(false); - return ( -
setIsHovered(true)} onMouseLeave={() => setIsHovered(false)}> - {/* Use the imported SVG icon component */} - +
+
); }