EventBridge i API Destinations

EventBridge i API Destinations

Kilka dni temu AWS umożliwił dodanie do naszego EventBridge subskrybentów, do których zdarzenia będą wysyłane przez zwykły endpoint REST. EventBridge i API Destinations pozwolą na uproszczenie wielu rozwiązań. Tam gdzie do tej pory korzystaliśmy z funkcji Lambda, teraz wystarczy tylko EventBridge i odpowiedni target.
Sprawdziłem jak to działa i pokażę w jaki sposób można wysłać na jakikolwiek endpoint (oczywiście także poza AWS) zdarzenia zarówno z naszych aplikacji jak i samego AWS.

Zdarzenia

Na potrzeby naszego rozwiązania przygotujemy dwie Event rules.

Jedna z nich będzie wywoływana w momencie gdy ktoś np. utworzy bucket w usłudze S3 lub zmieni politykę dla wiaderka.
Tak zwany event pattern będzie wyglądał następująco:

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "source": ["aws.s3"],
  "detail": {
    "eventSource": ["s3.amazonaws.com"],
    "eventName": ["CreateBucket", "PutBucketAcl", "PutBucketPolicy"]
  }
}

 

Druga to już reguła, która będzie obsługiwała nasze zdarzenia, czyli:

{
  "detail-type": ["appliczation-data"],
  "source": ["cloud.malak.app"]
}

 

Endpoint

Wszystkie zdarzenia z tych dwóch reguł będą wysyłane do funkcji Lambda, która będzie wystawiona za pomocą API Gateway.

Sama funkcja zapisze nam po prostu do logów to co wyśle do nas EventBridge.

import json

def lambda_handler(event, context):
    print(json.dumps(event))
    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "OK"
        }),
    }

 

SAM Template

Całość rozwiązania macie dostępne jako template SAM na moim GitHubie. Wystarczy praktycznie wywołać sam deploy i po chwili powinniście mieć gotowy stack CloudFormation z wszystkimi zasobami.

Jednym z nich będzie API Destination w postaci naszego API Gateway, gdzie będą wysyłane zdarzenia z EventBridge.

Sprawdzamy

Na początek przetestujmy naszego stróża S3.

Stwórzmy nowy bucket S3

i sprawdźmy co też znajdziemy z logach funkcji Lambda, która pracuje jako odbiorca danych.

Jak widać wszystko zadziałało i na nasz endpoint EventBeidge wysłał powiadomienie o utworzeniu nowego bucketu. A może bucketa. Nie wnikam… 😉

No to teraz sami wyślijmy coś do naszego event busa i przetestujmy drugą regułę.

Sam event wygląda tak

[
  {
    "Source": "cloud.malak.app",
    "DetailType": "appliczation-data",
    "Detail" : "{\"app\": \"app1\",\"data\": \"Tu jakieś dane z aplikacji\"}"
  }
]

 

i po jego wysłaniu


w logach funkcji widzimy to zdarzenie

Podsumowanie

AWS wprowadza krok po kroku kolejne usługi i rozwiązania, które zdejmują z nas kolejne obowiązki i zmniejszają naszą odpowiedzialność.

Kolejny klocek, za pomocą którego możemy budować nasze rozwiązania CloudNative. Ale nie tylko.

Same API Destinations nie są za darmo

ale za funkcje Lambda, które do tej pory wykonują takie requesty także płacimy. A czas pracy programistów też kosztuje.

Przypominam, że wszystkie źródła macie dostępne tutaj. Zapraszam do przetestowania. Wiecej na temat APi Destinations tutaj.

Comments are closed.