EventBridge is used for the whole cloud, and all areas of the cloud work on launching applications, scaling, and other problems internally, so we use EventBridge extensively. If you're using AWS cloud and EventBridge, you can imagine how much massive data is being processed through it. Additionally, when you create your account, there is a default EventBridge responsible for your whole account, which you can see in the other section.
They launched this for customers to integrate things easily. With EventBridge, we don't need a broker. The serverless and even the architecture is more straightforward. You design using an API and define your event structure in the schema. They also have a schema designer where you can allocate schema and match them. Then you put a rule that whenever you receive this kind of event, you do something which can be called to an API or a Lambda function.
You can define a very nice target, and it's straightforward, and it's just a few clicks on the dashboard. Even if you do the infrastructure as code, you can use CloudFormation, CDK, or other tools to integrate the whole ecosystem of EventBridge or Lambda function.
You can use your bridge and Lambda function to derive the whole gamification. You don't need servers, Kubernetes, EC2 instances, or anything. You need EventBridge and maybe an API gateway for some use cases, but you can live with two services of AWS, and EventBridge does not have any charges. It's free.
The biggest factor deciding factor is that when you go for Concept Plus or Craft, you don't need to pay to maintain or run it. It also scales inside, and it has everything inside.
When you design with, let's say, what we did, we had a very nice simple solution. The architecture is very, very simple. There was one API gateway, which was responsible for putting the events into EventBridge; the EventBridge was triggering some Lambda functions.
This Lambda function has all the necessary logic, so they were doing some processing. After processing, we want to store some data in a database, and there's F3 for storing files. That's it, and nothing else is required.
Amazon EventBridge doesn't have the feature of event replay. Let's say a customer reports an issue, and you want to reproduce the error. There is no source or feature where you can click on a button or put in a query and then try to reproduce the problem on a dashboard. So there is no such mechanism for that. The only way to debug it is to pass that particular event again and make it live to reproduce. That's not the only feature we need.
The second thing is about documentation, but they have improved it a lot now. They started it, but it still needs more improvement. They use open API specifications to document events, but Amazon EventBridge is an async model solution. Therefore, it should have async API documentation, not open API. Open API framework documentation works on rest methods like GET, POST, PUT, etc.
However, EventBridge does not work with REST methods at all, and it works with a source and target mechanism or a publisher and subscriber model. So there is a channel, publisher, and subscriber it uses.
And in open API, you don't find these things, and you can only find these things in the async API documentation. When you want to tell people about a particular model or schema that an event looks like, you write it in the documentation. Then, you can generate the code of the whole library.
For example, if you want to consume an event, you can prepopulate the classes and functions, and developers can easily work on it. These features are available in async API but not in AWS.
AWS provides the rest API, which requires a lot of customization. So I would say that's missing in the AWS cloud.
