In this post, we will write a very basic example which showcases content moderation for web applications using:
Tracking logs and errors in a software product is very essential for reliability and maintainability. Kafka is one of the most powerful solution for collecting/storing logs and activities. Use cases can be seen in this blog.
In this post, we will use Upstash Kafka to collect errors and logs occurred while users are using the mobile application which is built by React Native. Once the logs are stored in Kafka, there are endless possibilities how to consume them and integrate to log analysis tools.
In this post, we will use React Native, Serverless framework and Upstash to develop a mobile application for viewing and updating a leaderboard.
We will use React Native to develop the mobile application backed by the Serverless framework, which consists of Python functions running on AWS Lambda.
Upstash started its journey with a mission to be the best database option for your AWS Lambda functions. Meanwhile, we discovered another great option to build your serverless functions: Cloudflare Workers. It is an exciting product because it promises a better latency all over the world with a lower cost and no cold starts. But it has many limitations when compared to AWS Lambda. Extra limitations makes the list of database options shorter. We saw this as an opportunity to position Upstash as a great solution for the question: CF Workers are stateless. Where should I keep my data then?
In this article, I will compare AWS Lambda and Cloudflare Workers based on my experiences and observations during developing applications to showcase Upstash use cases.
Both are similar in that they provide a serverless runtime for developers to run their functions. But there are many differences between them and I will list them in the following categories: Performance, Pricing, Runtime and Language Support, Tools and Resources, Ecosystem and Integrations, Configurability and Limitations. I will declare a winner for each category from my point of view.
AWS Lambda pioneered serverless space. Many developers think that serverless is the future of development. It gives you the true pay-per-use model, relieves you from the maintenance and scaling of the backend infrastructure. But it also comes with challenges. One of those is its statelessness. You need to keep the state in an external data store. Unfortunately most of the popular data stores are connection based. But as we explained in this post, managing connections can become painful in serverless. That’s why, we have developed a high performance REST API on top of Upstash Redis. In this blog post, I will implement a very basic stateful api (page counter) on AWS Lambda and Upstash Redis using the REST API.
Designing a database for serverless, the biggest challenge in our mind was to build an infrastructure which supports per request pricing in a profitable way. We believe Upstash has achieved this. After we launched the product, we saw that there was another major challenge: Database connections!
As you know, Serverless Functions scale from 0 to infinity. This means when your functions get a lot of traffic, the cloud provider creates new containers (lambda functions) in parallel and scales out your backend. If you create a new database connection within the function then you can rapidly reach the connection limit of your database.
If you try to cache the connection outside the lambda functions then another problem occurs. When AWS freezes your Lambda function, it does not close the connection. So you may end up with many idle/zombie connections which can still threaten.