0:03All right. Welcome, everyone. Good to see you all. So, I'm Fabian. I work with Lovable, and we've been working on serving people web applications for about three years now. And really since the start, we started building this on top of Cloudflare, and it's been a journey in kind of the implementation and the services we've been able to use. So today I thought I would go into a bit of the technical details behind our implementation, how we serve our applications. So first off, just quickly about Lovable. We set out, when we started Lovable, to enable the 99 % of the people who do not necessarily have the knowledge how to code, and we heard talking here on the main main keynote on stage about kind of this new era of creativity and creatives who are able to take an idea in into reality and that's really what we're all about at lovable and so um our our product is basically this chat box that you go in and you you prompt and you'll get a web application or landing page And then you can iterate on that, and you can publish, and you can host it with us.

1:28And today, we'll dive into the technical details on the front -end and back -end hosting of this. Within our platform, we also offer databases, the ability to send email, to receive payments, and a bunch of connectors around this. But we'll focus on kind of the core part of the front-end and back-end hosting. So, just to put... what we're going to go through into perspective of the scale that we're doing here. So, since we started, we've created 70 million applications on Lovable. And every week, we create about 1 million new applications. And every month, these applications get over 1 billion visits.

2:14And I was talking with our Cloudflare FD here in the front, and I got the fresh number that And also, every day, we have about 7 billion requests to these Cloudflare workers that we're going to go through. And so I want to focus on this first number, the 70 million applications. So all of these applications, we need to be ready to serve them at any time, right? And this is way too many applications to have ready and kind of a server live to serve. right? So, we can store the code for these applications, but then we need to be very efficient about spinning up the compute to actually serve them. And that is really what this talk is all about. And so, a quick history here in how we've been serving applications.

3:08So, when we started, we had a simple kind of React single -page application that would render in the browser. And this makes it very easy to build the infrastructure behind this, because the only thing we need to do is route the request and serve some static assets. And so, we save these assets in object storage in R2, and then serve them, right? But we've done this migration earlier this year to 10-stack start, which is this metaframework on top of VIT. So, we've always been... VIT -based. But with 10sec start, we do server -side rendering. And we then need, of course, on compute to kind of handle that rendering. And we need isolation between the applications that we serve.

3:56And so, this move, why did we actually do it? And the main reason that kind of made us really make this migration is that... We wanted to have the best possible SEO, search engine optimization for our users. And to do that, we wanted to give them service-side rendering SSR. The other piece is that before we kind of had a separate backend serving layer to our frontend serving layer, whereas now we have this isomorphic setup where we basically have this one code base that gets deployed into a server bundle and a client bundle. which makes it very easy for the AI to work with the code.

4:45And we also maintain being able to serve the static pages. So in an Intense Stack start application, we can define which routes should be static and which should be dynamic, and so we can still rely on the ease of use of just serving static content when you actually don't need anything dynamic. But the dynamic part is... what is interesting, I think, technically, here, and what we'll talk about. So, a quick primer. We're using Cloudflare workers to serve this, and Cloudflare workers, there is this JavaScript runtime where Cloudflare workers uses worker D, which is the runtime, right? The workers is more of the platform, and it's built on V8 isolates, and this allows us to really densely pack the computer.

5:36of all of these applications that we're serving. And if you would compare it to something like a VM that would give you isolation, this has much less overhead, and so we'll have much quicker cold starts and be able to serve an application much faster. And so on the platform, on Cloudflare, you normally have the normal... deployed worker, you deploy via Cloudflare's control plane or their dashboard, Wrangler Deploy, and you make one deployment for one application that you have. Earlier this year, in March, Cloudflare released dynamic workers, which is really a necessity for doing what we're doing with it.

6:28And a dynamic worker is a way for a normal worker to spawn another. worker. And so we'll go through how we're using this. And so all of this code that we have in these 70 million applications, they're stored in R2, which is, you know, the Soviet storage, and it's very scalable. So that's kind of the easy part. And then the question now is, how do we serve all of these applications? And if we look at how this actually works, um, the, the app starts just having the code in R2, and we'll cache it in KV. And then we have this serving layer that identifies which code is supposed to be served.

7:15And then we load that in, spin up a dynamic worker, and then that dynamic worker is ready to serve the application. And all of this happens in less than one second. So that's the code start before we're able to serve. an application from being totally cold in R2 to having this worker ready, which is quite good. And I think most of our users have no idea when a cold start actually appears because of this. And let's dive into a bit how this actually works. So we can imagine a browser making a request to a URL. And so you can have a custom domain on Lovable, but here we just have the subdomain, myapp.lovable.app. And this request goes to one worker, which is what we call our proxy worker, so all requests goes into this one worker.

8:06And we can derive which level application it is based on the URL. And from that, so this is my app, it's kind of the identifier of this application now, we can go to our database and we can fetch some metadata around this application that would include. first and foremost, where we store the code for this application and then also some other metadata such as which version is the latest published one, do we have some restriction on access to this, is it public to the internet or just in your workspace and so on. And so this we can also cache in Cloud Flares, cache that is co -located with the worker, so any subsequent requests here.

8:53are very fast as well. And then the interesting part comes when once we have all of this metadata, we have two paths that we can go down into. And one is this kind of path that we started with, where we serve the static file. So this might be serving an index.html, a CSS file, and a JavaScript file. And in that case, we don't actually need to spin up any more compute, and we can serve that directly. our proxy worker and but if we have something server-side rendered we need to spin up one of these dynamic workers and that is that is only happening then for a subset of requests and and it's really this kind of new development that we've made that that allows us to have you know best -in -class SEO and also cases, in some cases, you need server -side rendering to have the best kind of performance depending on how you retrieve things from your database.

9:58And so, just two quick concepts that play into this as well. So when we serve applications, we use React predominantly as our framework here, and normally when you render React, you... You end up just having, like, one div that you then execute JavaScript on to render up the React tree that turns into HTML. But there's an optimization here that you can do that happens when we do server-side rendering, which is that the browser will make a request to the worker, and on this worker, we will match that to a route in TanStack. We will kind of run the React code behind that.

10:45route, and we will render the HTML on the server, and we'll also get the data behind this HTML, and we'll separate those two out. That is called dehydration. We serialize the data, and we have the raw HTML, and then we can serve those two separately to the client, where the client will be able to render the HTML directly and then hydrate it with the data. before any JavaScript is executed on the client, you will already have a rendered page. And then, when the JavaScript executes is when you get interactivity. So, you attach the handlers to the existing DOM. The other concept that this meta framework offers is, I touched on it briefly before, is isomorphism, where, actually, this code base, it can, it is written in one way for, you know, humans or in this case mostly AI, and then it can be executed both in the browser and on the server or in the workers.

11:48And the way this happens is that if you execute this function in a server setting, then it will run like normal and you will have access to environment variables and secrets and so on. But if you execute this in the will, of course, not have access to the secrets and any sort of back-end logic. And what will happen instead is that TASTEX Start will, in its build step, it will kind of replace that code with just a request stub that will make an HTTP call to the server that actually runs it. But from the perspective of writing this code, you don't really have to care about this. And you're just able to reuse functionality across the browser and the server.

12:39and going back to kind of the the workers layer here a bit and when when we serve something with secrets and we and we of course separate that from from the application code and so what goes into spinning up one of these dynamic workers is first and foremost the application code but then separately from that and we're buying the secrets into this and into this new worker. And so, the secrets, they're, of course, stored encrypted at rest in our back end. And then, when we spin up one of these workers, we'll load them in into the environment of this new worker. And a cool kind of side effect of this is that we're able to know that if we update the secrets without touching the application code, we know that a request to this worker needs to be invalidated, and we'll actually spin up a new worker with the new secret so that as soon as you update secrets, we're able to invalidate kind of existing isolates that are live and be able to serve requests with any new secrets that you update without actually touching any of the application code or a new deployment step.

13:55So, a question here for the room is, which app do you actually think is the biggest that is hosted on Lovable? I know the question, and I think, or I know the answer. And I actually hope that it will change in the future. I think it will change in the future. But today, the answer to this is Lovable itself.

14:20And Lovable was not always hosted on Lovable, because it's kind of hard to bootstrap these things. You have to build it first. So when we started building Lovable, we're actually building Lovable. built it on XJS. That's just where I set it up in the beginning. And then we did this kind of large migration of rewriting our entire front -end code base to Tanslac Start to be able to deploy it on top of Laval Cloud or these Cloudflare workers. And the reason why we do this is, I think, deeply rooted. within our culture at Lovable, and it's around dogfooding. And we want to make sure that Lovable itself is served like any other application. And so, we know that now, since we're currently the largest application on Lovable, we know that any kind of scaling issues that we incur, we can fix before any of our users would hit those issues.

15:21And so, it's a very virtuous loop. And so, I'll give you... some quick poetry here. So this is some Swedish poetry, but for your convenience it's translated into English. And this is Nils Verlin, and I think it encapsulates kind of this culture we have around dogfooding. So I'll read it for you. My heart is thine, thy heart is mine, and mine shall remain till I die. My happiness thine, thy happiness mine, thy tears stay mine when thou criest. And so this really encapsulates the idea of, you know, our happiness is our customer's happiness, but also our pain is our customer's pain, or maybe the other way around, our customer's pain is our pain, right?

16:07And so we really want to make sure that any issues that our customers have, we actually feel as well, and so that we're always fully incentivized to fix these issues. And there's been a lot of things that we've learned from doing. this that benefit both us and our customers because of this migration I mentioned. And so let's go into some of those lessons learned. So one of the first things is that when you run in one of these isolates, you're quite memory constrained. And so each isolate has a soft limit of 128 megabytes of memory budget. And this has to be shared both with the bundle and any concurrent requests happening too. to this isolate. And so, you have to be a bit conscious about this when you're writing the code.

16:57You have to make sure that anything that should maybe live in the client bundle is in the client bundle and is not leaked into the server bundle. And we had a few examples of this when we migrated Lovable where we got some out of memory errors because we accidentally included a TypeScript compiler, for example. and a syntax highlighter into the server bundle, whereas this should have only been in the client bundle. And so these learnings in how to make sure that you separate the bundles correctly is something that we then encode into our builder agent for all applications that are built for our users, over a million of them per week.

17:43And the other part here is that Cold starts is really the expensive part. So once you have a warm worker running, then everything is extremely fast. But the cold starts is what is the slower part, even though it's less than a second. But you really want to avoid them if you can. And so we cache the worker bundles in KV for faster retrieval. And we also really keep the bundle on a diet, so to say. So, and. And we try to always minimize the size of the bundle because that just makes everything faster from loading and parsing and compiling.

18:25The last part here is that the fastest way to, you know, serve a cold start is to just avoid it. And we do this if we rely on prerendering and we can just serve static files instead. And so, this... relies on actually rendering within Tanstack then the bundle at build time or publish time. And then at request time, we simply have to serve this HTML and the CSS and the JavaScript and hydrate it, as I mentioned before. And so whenever we can, we use this strategy. And when there's benefits to using server -side rendering, be it for SEO or performance, then we do that instead.

19:12So, kind of closing this out, it is this virtuous loop that we have created for ourselves where learnings from Lovable, which again is on the same stack now as any Lovable app that is created, together with the learning from all of the Lovable applications built on our platform is kind of transferred into our building agent. and we make sure that all of these edge cases that you might encounter, that we actually take those learnings and we make sure to encode that knowledge, and we have a whole kind of system around making sure that our agent can retrieve this knowledge efficiently at scale, but that it can actually use that knowledge to make sure that any new application or any new iterations on an illogable application can avoid previous errors.

20:07or previous problems that someone has encountered and this just keeps on looping of us making learnings and making better decisions and scaling more and actually figuring out what we should improve both again from level itself especially when it comes to scale but then just all of the edge cases that we find within our user applications so that is it for my talk here. We've been very happy with our partnership with Cloudflare here and being able to serve these applications and actually quite lucky, I think, in the timing of the release of dynamic workers to be able to support server-side rendering on our platform. And it's really worked well, everything from the tech stack itself with 10 stack migration.

20:59We jumped on that train very early on. and working closely with Tanner and team behind that as well. And so, thank you so much for listening, and I hope you learned something, and I'll be around here for a few minutes also if we want to do some questions.