Fri, Nov 11, 2022See Your Currently Running Repls
Have you ever wondered which of your repls are running at a given time? Do you know which ones are currently serving traffic, and which ones need to be woken up? Do you wish you had more visibility into when your repls have stopped in the past and when they've been restarted? If any of the above describe you, we have just launched a new feature made especially for you: the Repl Status Manager. To use it, go to the Status tab on the My Repls page. When you get there, you'll see a list of all the repls you've ever run in your account, sorted by recent activity -- including the ones that are currently running!
- Wed, Oct 12, 2022
Analytics For Every Repl
Web hosting on Replit is simple yet effective. When you start a server in your repl, we automatically detect which port it opened on and provide a public endpoint for you to access it. In other words, every HTTP request that goes to a *.repl.co domain is reverse-proxied through our secure infrastructure. This lets us do some cool things that more basic hosting providers simply can't do. One of these is analytics for your website or API. Have you ever wondered how many people visited your web site, what browsers they used, and whether they had any issues? Now you can find out! As of today, web analytics on Replit is automatically available in every repl, without installing any third-party JavaScript packages. To access it, just add /analytics to the end of your repl's URL, such as https://replit.com/@user/slug/analytics after enabling the Explorer role on your account. Web Analytics Dashboard
Fri, Sep 23, 2022Worldwide Repls, part 2: Load balancing for fun (although not quite profit)
In our previous blog post about Worldwide Repls, we talked about how we revamped part of our infrastructure to build a new abstraction that allowed us to build other components on top of it: the control plane. In this entry, we'll talk about the very first thing we built on top: a load balancer. The need for an alternative load balancer All of our infrastructure currently runs in Google Cloud Platform, and it comes with several options for very robust load-balancing across services in the form of the Google Cloud Load Balancer (a.k.a. GCLB). Since it's very easy to get started, that's what we used for several years. It has all sorts of very neat features like SSL termination, geographical routing to minimize latency, integrates with their autoscaling solution to let us grow and shrink the size of our fleet to reflect the number of concurrent users, and is even optimized to support a request load that is not quite homogeneous: a few requests that are 10,000x more expensive than others is totally supported. So far everything looks great on paper. Why did we need an alternative load balancer? When we originally announced that we were going to support non-US compute regions, we discovered that there was a small disconnect between how the GCLB operates and how we would like it to operate: back then, when a user made a request to start or connect to a container, the container would be created geographically near where the user made the request if possible, and would fall back to where we had capacity. This unfortunately meant that there were several cases where a user in India would start a container, it was created in the US, and all network packets would still need to perform one earth-sized roundtrip. To make things worse, this also happened to some folks in the US, so we had to revert that change. By this point in time it was clear that we had to create an intermediate layer that could allow us to make decisions as to where the containers were created, since we had all the information about the Repl upfront, but GCLB alone was not able to use this information. A bit later, our team of SREs found something even more disturbing: the distribution of load across our fleet was all over the place!
- Fri, Jul 8, 2022
Worldwide Repls, part 1: The Control Plane
During the ReplCon 2022 keynote, we announced that we were going to geo-distribute our infrastructure so that your Repls are much faster when accessed outside of the United States. The speed of electrons / light in a medium is a fundamental speed limit. Most of our users are several thousand kilometers away from the data centers where we host Repls (currently limited to the United States), so the round trip from them to the users' homes is going to necessarily take several hundred milliseconds just to traverse the series of tubes that is the Internet. Today, we have finished the first milestone to make this a reality, and that comes with some pretty neat side-effects! The control / data plane separation Up to this point, our infrastructure was designed in a way that allows for horizontal scalability: being able to have more capacity to run Repls by adding more VMs to our infrastructure. This allows us to quickly react to having more users at certain times of day without making any code changes, and is built upon having a Load Balancer that routes requests to connect to a container using the WebSockets protocol to individual VMs in our infrastructure. Some of you might remember that we had announced global routing last year, which we achieved by having a small set of servers in Mumbai, India. That worked well during testing, but after enabling it for everybody we discovered an interesting edge case: since the Load Balancer is the component that decides where any WebSockets connection goes and we have little control over that whole process, sometimes the India servers were a bit busier than servers elsewhere and the Load Balancer decided to route a connection to the United States. But what if this was a multiplayer Repl, or a reconnect to a Repl that was already running? In those cases, the VM where the request lands performs a transparent proxy of the WebSockets connection to the VM where the Repl is actually running. So now users would have to connect to a server in the United States (which was the old "normal"), but then that server had to talk to a server in India, which added an unnecessary ~250ms worth of roundtrip to the previous behavior. We had accidentally made things slower! Sadly, we had to revert this change 😢. So back to the drawing board we go. What became obvious is that we had to make changes such that the Load Balancer was not the source of truth of where Repls are placed. Enter the Control Plane. In Networking, there is a distinction between what are called Control and Data Planes: where the Control Plane is concerned with making changes to the network to make sure that packets go to their destination in the best way possible at that moment, and the Data Plane is the part of the system that actually moves the internet packets (a.k.a. the data). There is also the Management Plane, which is analogous to the Control Plane but manages other non-networking systems. So for us, we wanted to have a Control / Data Plane separation to clearly distinguish making modifications to the shape of the system: making a Repl start / stop in a particular VM vs. the WebSockets communication between the Linux container and the Workspace. A new abstraction to build upon
Sun, Apr 17, 2022QLTY SZN 1
A commitment to quality One of our competitive advantages is making bets on technologies before the rest of the market catches on. One such bet we've made is on CodeMirror. We switched our editor from a proven but stagnant technology, Monaco, and towards CodeMirror. We know we made the right decision because: We can now make changes, most importantly bug fixes, much more quickly. The new search panel we were able to build is much better than the version that shipped with Monaco. The new editor's improved performance is already showing up in better user onboarding success. CodeMirror's extensibility will enable us to ship one of the most most long-awaited features: Themes!
Wed, Mar 30, 2022We Built a Search Engine
For the past few months, we have been building a Replit-native search engine. It is remarkably powerful, and we are really excited for you all to try it out. We believe that you should be able to find anything on Replit in less than 30 seconds. This might sound simple, but when you have 100 million+ Repls, it becomes complicated. :) When you search for something on Replit today, you'll see a page with relevant results from the following categories: Repls Templates Code (yes, code)
Wed, Feb 23, 2022All New Repls are Powered By Nix
For the past year we have been working hard to integrate Nix into our platform and rebuild our existing language experiences with package from Nix. We are excited to announce that all new repls are now powered by Nix. In this post we'll talk about what this means for the future of the platform and all the work that it took to get here. With Nix you can easily create templates for languages Replit didn't support before, pull in more development tools than ever, and access any cli application in the shell without installing anything: Every new repl being powered by Nix means that we've be able to make vast improvements to our existing languages: Long awaited Node.js v16 support 100x faster Python package management
Fri, Feb 11, 2022Announcing File Persistence in Hosted Apps… for Everyone!
Replit is your computer — for whatever you need to do. We announced last year that Hackers would be able to have their hosted apps be able to persist file changes since that made it possible to build a lot more apps. But we were not quite satisfied that only Hackers were going to get this new feature. Today we are announcing that we are opening this up for everyone! Why the change? Back in November, we knew that this new feature was going to have a small, but measurable, impact to our infrastructure. This meant that opening this up for everyone from the get-go was not ideal. We wanted to get this out to users as soon as possible, so we decided to be iterative. We crafted a plan to open this up for Hackers first to observe what a realistic load would look like, while pondering some potential optimizations that we could use to improve it. In addition, we added more monitoring just in case anything came up. After enabling this and blogging about it, we saw a very small difference between our predictions and reality. The plan had worked! And our hunch about something unexpected appearing was right on the money: the extra monitoring enabled us to find (and fix) an extremely low-probability bug that could only be observed when operating at Replit scale. With the new data, we could make data-driven decisions. We went through the planned optimizations and the additional load is now in a much better place, so we're comfortable opening this up for everyone.
Fri, Feb 4, 2022Making new Python repls 100x faster to start up
Python is currently the world's (and Replit's) most popular programming language. We've improved the Python experience during last year, with a Python package cache to make installs faster, and an integrated, multiplayer debugger to increase the understanding of what programs do. But there are still a few problems with Python. Packages are often very space-consuming, so they are installed into an ephemeral 2 GiB scratch disk to avoid filling up repl directories. Unfortunately this means that every time a Python repl starts, a lengthy package installation process must happen. This makes some Python repls take forever to start! Some other packages that have a large number of dependencies (like TensorFlow and Torch) were completely unusable because they don't even fit on the scratch directory. We decided to address these shortcomings and make Python a bit faster on top of that! Today, we're releasing a brand new Python template that has a lot of neat things. Newly created Python repls will now be based on nix so that additional programs and libraries can be installed, have a standard virtual environment stored inside the repl, and a brand new caching mechanism so that packages are installed even faster and they don't take up too much space. I had the wildest dream, that I was able to run the TensorFlow 2 quickstart on replit without running out of disk space or memory How does it work? We had a few goals in mind when we started designing this:
Tue, Dec 14, 2021Repl Space and Templates
When we want to support a new technology, we're faced with the question: "Do we (the Replit team) build this capability into the Replit directly, or can our users add it themselves?". Usually, we want the answer to be the latter. Repls are like personal computers for your projects. And the more these personal computers can be customized, the more they'll be used in creative, unexpected ways. Internally, we refer to the extent to which a Repl can be configured as "Repl Space". So when we talk about building new features, we always ask "can it be done in Repl Space?", which is basically asking if we can build it on Replit. Over the past year, Repl Space has become significantly more powerful, and soon, Replit will be one of the most flexible computing platforms on the planet without compromising its simplicity. Now that we have the technical foundations in place, we're excited to bring more of that power into the product in the form of Templates and some new configuration options. Templates Where can I find templates?
Mon, Dec 13, 2021Ace, CodeMirror, and Monaco: A Comparison of the Code Editors You Use in the Browser
I’ve been working on Replit for roughly six years now, and as the team has grown, I’ve focused on the IDE (what we call the workspace) portion of the product. Naturally, I was increasingly preoccupied with the code editor. While we’ve considered creating a code editor that meets our needs, the complexity involved in developing one, the richness of open-source choices available, and the size of our staff made it a fruitless rabbit hole to enter. Our time is best spent elsewhere. I have had the pleasure (and the pain) of using Ace, Monaco, and CodeMirror in production settings, sometimes simultaneously (more on that later). In this post, I’ll go over some Replit history, my experience using the editors, and how they stack up against one another. If you’re here for a direct comparison, feel free to skip to the end, where I recap and compare. The story Prelude: Ace In the early days of Replit, around 2011, there was no code editor. It was a pure REPL interface, a console with a simple input box. Adding a code editor was an obvious next step, especially if we cater to more complex programs. Code editors give us features like syntax highlighting, editor shortcuts, auto-indentation, search and replace, etc. Cloud9 released Ace at the time as a feature-full, performant web code editor. Ace editor is still actively maintained; it has a rich ecosystem and supports many languages, keybindings and works great in the browser.
Mon, Nov 29, 2021Will Nix Overtake Docker?
In many discussions about Nix, the comparison of Nix and Docker comes up frequently. This question could be dismissed by saying that Nix and Docker are different tools that solve different problems. One is a toolkit for building and deploying containers and the other is a package and configuration manager. However, these tools do have some overlap: they can both be used to create reproducible environments. A reproducible environment is one that can be recreated from scratch in an identical way (ideally bit-for-bit). Practically, this means having the same tools, versions, and configuration between the environments. Reproducible environments are useful to ensure all developers on a project have the exact same set of tools. Additionally, you can develop in an environment that is similar to the production environment -- leading to less surprises when deploying. Both tools can solve the age-old problem of "it works on my machine". While both tools aim to solve this problem, they take different approaches.
- Thu, Nov 11, 2021
Announcing File Persistence in Hosted Apps for Hackers
We mostly think of repls as being full computers in the cloud, and one of the goals of the platform team at Replit is to enable people to build almost anything in replspace. In the past, when a file was stored in a repl, it would only be saved when the editor was opened. This went against our goal and made it impossible to write certain servers that changed files at runtime. This was especially hard for newcomers, because that's the easiest way to persist information. Starting today, Hacker and Teams subscribers will be able to write services that accept file uploads or store data in a local database (think SQLite) or text file, regardless of how the repl was started. A demo of what it looks like for a server to be able to save its files: https://sqlite.luisreplit.repl.co What is replspace? replspace is a term we coined up. In operating systems, memory is divided into kernel space and user space. Kernel space is where the kernel executes and provides its services. The kernel can access all of the memory, but the user cannot access the kernel's memory directly. By contrast, user space is all the memory that a user can access without modifying the kernel sources (or creating a kernel module). The term user space has also been used to refer to the programs that are run by users. This memory separation is important because the kernel manages all hardware resources, providing access control and coordination, and provides abstractions that let programs that run in user space make requests to interact with those resources. The kernel has several interfaces so that the user space programs can communicate with the kernel, the most important one being the system call interface. These use the abstractions laid out by the kernel to ensure that users and programs don't interfere with each other and also iron out differences in the underlying hardware and provide a uniform "view" of the resources available to the machine.
Tue, Oct 12, 2021Faster Nix Repl Startup
For the past few months we have been working on improving our Nix integration. Nix allows users to easily use over 80,000 Linux packages in a repl. Nix opens the door to many exciting tools and applications on the platform. Our goal is for every repl to be backed by Nix. Before we can do that, we need to ensure that the Nix experience is just as good, if not better, than our existing Polygott solution. If you've used a Nix repl, you may have noticed additional loading time when opening your repl. The console would show "Loading Nix environment..." and you'd have to wait for a few seconds. In some cases, you might have waited for tens of seconds. We care about making repls start up as fast as possible and this additional loading time wasn't acceptable. Through some additional caching, we have entirely removed this loading time on many Nix repls. Now, Nix repls will start up just as fast as Polygott-based repls. See below for a before and after demonstration. Before: After:
Fri, Sep 10, 2021Data Loss: a sad tale with a happy ending
Earlier this year, we discovered that we were losing data for some of our users. This manifested as either repls being completely empty after reloading, or some of the changes to files not being present after reloading. Obviously losing data is the worst we can do, so we had to fix this immediately. This blog post narrates the adventure of how we discovered this, how we fixed it, and the lessons we learned during the way. The discovery Throughout the year, we had had some worries about some theoretical cases in which users could lose data. We have had a few complaints from people that their code wasn't correctly saved, and since we weren't sure what caused them, we just tried to fix bugs here and there one at a time in an unstructured fashion. Around mid-July, we got an alarmingly large number of reports of people about their code not saving correctly in a short amount of time, ironically just after deploying one such fix. This meant two things: our intuition about folks losing data was correct, but the way we were fixing it was not! This led to the immediate discovery that there were months- or years-old bugs that were silently losing or corrupting data, and some of them turned out to be load-bearing bugs that couldn't be fixed in isolation (since fixing them triggered other kinds of data loss). This made us start a much larger project to have better guarantees and incrementally fix things without regressions. Homer Simpson doing a dramatic impression of this whole situation