Amazon API Gateway vs Amazon Kinesis Firehose: What are the differences?
Developers describe Amazon API Gateway as "Create, publish, maintain, monitor, and secure APIs at any scale". Amazon API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. On the other hand, Amazon Kinesis Firehose is detailed as "Simple and Scalable Data Ingestion". Amazon Kinesis Firehose is the easiest way to load streaming data into AWS. It can capture and automatically load streaming data into Amazon S3 and Amazon Redshift, enabling near real-time analytics with existing business intelligence tools and dashboards you’re already using today.
Amazon API Gateway can be classified as a tool in the "API Tools" category, while Amazon Kinesis Firehose is grouped under "Real-time Data Processing".
Some of the features offered by Amazon API Gateway are:
- Build, Deploy and Manage APIs
- API Lifecycle Management
On the other hand, Amazon Kinesis Firehose provides the following key features:
- Integrated with AWS Data Stores
- Automatic Elasticity
Repro, Intuit, and Simple Merchant are some of the popular companies that use Amazon API Gateway, whereas Amazon Kinesis Firehose is used by Hooroo, Survata, and Drivy. Amazon API Gateway has a broader approval, being mentioned in 167 company stacks & 62 developers stacks; compared to Amazon Kinesis Firehose, which is listed in 32 company stacks and 7 developer stacks.
What is Amazon API Gateway?
What is Amazon Kinesis Firehose?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose Amazon Kinesis Firehose?
What are the cons of using Amazon API Gateway?
What are the cons of using Amazon Kinesis Firehose?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas
To build #Webapps we decided to use Angular 2 with RxJS
#Devops - GitHub , Travis CI , Terraform , Docker , Serverless
API Gateway in conjunction with Lambda has allowed us to become 'serverless'. We have a number of API endpoints that range from simple CRUD operations, through to triggering chains of complex background jobs. Like Lambda, this service has released us from getting bogged down in infrastructure management, freeing up huge amounts of time to focus on solving business problems.
It provides me with POST endpoints; I don't run servers and some third-party services need to POST data to my application.
Triggers the Lambda function from a GitHub WebHook push into
Excellent API Gateway, some quirks but most are being addressed over time, easy integration with Lambda