EventBridge vs API Gateway

Question

I am trying to learn how to work with AWS in the last few days, because I want to deploy some APIs.

So far, I was learning how to use API Gateway with Lambda Functions and it seemed like a nice workflow. But, because I am writting my APIs with flask-restplus, I tried the Zappa framework which uses EventBridge (CloudWatch Events) as a trigger for each Lambda Function I create.

So my questions are:

1. What is the difference between EventBridge and API Gateway and when should I use each one?
2. While working with API Gateway I realised that the best practise was to create a different Lambda Function for each API and theN connect it to the Gateway. So, is a good idea to upload as a Lambda Function the whole python file? (where all the API routes are written there) or should I do a procedure for each API?

Thank you in advance.

Answer 1

1. API Gateway is a service that allows you to create a RESTful APIs. I assume that's exactly what you need if you like to deploy some APIs as you mentioned. EventBridge is a serverless event bus where you can publish events and configure your lambdas to consume those. That's what you use for decoupled communication. E.g. if a POST to your API Gateway creates a new user to your app then your Lambda could dispatch an event "USER_CREATED" into EventBridge event bus. An other Lambda can then subscribe to event "USER_CREATED" and send a welcome email. CloudWatch Events are just timer based EventBridge events that are published to event bus. In that case you could e.g. create a rule that notifies your Lambdas every morning to run some background task. Sending a daily marketing email to your customers could be one such use case.

2. I don't think there is a sigle best practise. It can be more simple to start with one Lambda serving multiple API endpoints. You can also think what kind of permissions and resources/databases your Lambdas need. One example is to divide Lambdas to the command and query Lambdas. That way POST, PATCH, PUT and DELETE could call one Lambda that has write permissions to your database. Then GET endpoints are handled with another Lambda that has only read permissions to your database. This read lambda could use in the future some different kind of database that is optimized for queries. These are just some things to consider when your application grows.