The Replit Team

Last week, we launched Replit Agent, our AI system that can create and deploy applications. Now, with only a few sentences and a few minutes, you can take an application from idea to deployment.

You can think about the Agent like a pair programmer. It configures your development environment, installs dependencies, and executes code. From your laptop or the Replit mobile app, the Agent is changing how our users build software.

If you'd like to learn more, we've compiled some of our favorite examples, tutorials, and articles on the agent so far. 

Introducing Replit Agent

Søren Rood

With the emergence of blockchain technology, people can get paid from anywhere in the world. This type of transaction is revolutionary because we are able to send value from one person to another with no bank.

The day will come when it is cheaper and faster to send value (ETH, USDC, BTC, etc.) using blockchain than with the current payment system.

This post

This is a start-to-finish Python tutorial on how to send ETH from one wallet to another on Replit. At the time of writing, ETH is at an all-time-high (ATH) of $3,335.

To do this, we are going to use infura.io. Infura is a service that allows users to easily interact with a live Ethereum node. A node is a computer that participates in the Ethereum network. Alternatively, you could spin up your own node.

You can follow along with the code here.

How to send $ETH in 19 lines of Python

Hi 👋🏻, I'm Søren. I'm a computer science student based in Seattle, Washington. I've always been interested in the intersection of finance and computer science and I tend to find myself building things in the space. Before I was offered a position at Replit, I worked as a software engineer at a FinTech startup writing market-making systems for various crypto brokerages. While I was doing this, I was also working on a side-project with my close friends and co-founders Justin and Steven. This project is called Blubbr.

What is Blubbr?

When we first started Blubbr, we just wanted to make a trading bot. We became interested in the relatively new market of SPACs and had developed a strategy we believed would make us money. A SPAC is a company whose entire goal is to buy a private company and take them public. Before a SPAC is allowed to talk about anything to the public, they have to release a special type of form on the SEC website. We discovered that shortly after companies release these specific forms, their stock prices tend to increase. Blubbr was created based on the premise that if you bought within minutes of the form coming out, there was a good chance that you would make money.



How did we build this so fast?

Meet the college students who used Replit to build a startup with $1,000 in monthly revenue in 3 weeks

Sergei Chestakov

Our Hacker plan has always been a great choice if you need more powerful repls. In addition to benefits like private repls, more storage, and always on, the Hacker plan gives all of your repls 4x the CPU and RAM compared to those in our free plan.

However, sometimes, even 4x is not enough. Whether you're building a new Terminal or playing Doom, you could blow past those resource limits pretty quickly. That's why today we're excited to announce Boosts!

Boosts are a new addition to our Hacker plan that allow you to make your repls even faster. Boosted repls come with 4 vCPUs and 4 GB of RAM which is double the resources of standard Hacker repls (and 8x more than free repls). As of today, we're including 5 free boosts as part of the Hacker plan. However, boosts can also be purchased on a free plan using Cycles.

To boost your repl, simply click on your repl's title to bring up the repl info card and click the "Add boost" button underneath the always on toggle like so:

Boosts

Rishabh Anand

Hey there 👋🏻 My name is Rishabh Anand and I am an ex-resident at the National University of Singapore's (NUS) Raffles Hall of residence. It's one of the on-campus student accommodations that houses students from all levels of undergraduate education at NUS with the majority being freshmen and sophomores.

RHDEVS – the software development club at Raffles – was tasked by upper management to build a convenience app for the Hall’s student body. The app itself was nothing new; it has some basic features students would potentially use in their daily hall lives:

Laundry

Facilities Booking for clubs

Events Booking / Management

Calendar and Timetable Planner

Replit Case Study - Creating a 700+ User Web App in a Month

Amjad Masad

Rate limiting is standard practice for services offering an API. It's used for both protecting against bad actors, for example, attempting DOS attacks and to simply enforce limits on the service. There are many resources on the web on how to implement a rate limiter in your favorite language/stack. However, I couldn't find anything on how to rate limit Websocket connections (they differ in that they are persistent connections).[](preview end)

If you're implementing an HTTP API rate limiter and your service endpoint is a single server then it's pretty simple -- you keep an in-memory variable that you increment. Things get trickier, however, when you're serving requests from multiple servers. That's when you start needing a central shared "state". For this, most developers use Redis. In fact, the rate limiting use case is so prevalent in Redis that it gets a mention on the docs for the INCR function:

The requirement here is to limit calls to 10 calls per second per IP address. So a key is constructed by concatenating the user's IP address with the current timestamp. This is then incremented with every call and checked to make sure they haven't exceeded the limit. Simple enough (you can also implement this using your favorite language and Redis library).

In our case, our code execution API gives our customers and users an HTTP and a Websocket interface. The reason you'd need a persistent connection is to build a stateful interpreter/REPL. But persistent connections costs us system resources because we need to start a container and an interpreter/compiler process that waits for the next command to execute. For this reason we have to enforce a limit on concurrent open connections. The challenge with this is implementing it for a distributed service (we serve our users from different servers with no centralized server managing state). As we've seen above, Redis is the go-to technology to solve this problem. However, our use case differs in that we don't limit calls for a certain time interval, instead our limit is one the total number of open connections at any given time.

The first solution that came to mind:

Introducing Replit Agent

How to send $ETH in 19 lines of Python

Meet the college students who used Replit to build a startup with $1,000 in monthly revenue in 3 weeks

Boosts

Replit Case Study - Creating a 700+ User Web App in a Month

Distributed Websocket Rate Limiting