ButterCMS is a headless or API-first CMS built with Django. We discuss the initial inspiration, caching, performance, hosting, and running a SaaS business at scale.
This podcast does not have any ads or sponsors. To support the show, please consider purchasing a book, signing up for Button, or reading the Django News newsletter.
Will Vincent 0:05
Hi, welcome to another episode of Django Chat, a podcast on the Django web framework. I'm Will Vincent joined by Carlton Gibson. Hi, Carlton
Carlton Gibson 0:13
Hello Will.
Will Vincent 0:14
And we're very pleased to have Jake Lumetta from Butter CMS. Join us. Welcome, Jake.
Jake Lumetta 0:18
Thanks, guys. Pleasure to be on. Super excited.
Carlton Gibson 0:21
Thank you for coming on.
Will Vincent 0:22
So this came about after Django con us you and I were both having breakfast there, I think and as one does just said, Who are you? What do you do? And you said, you worked at butter CMS, which I'd obviously heard of, and then a little bit later you said, You founded it. And you told me a little bit about that story then, but hopefully we can go a bit deeper today. Sure. So I guess as preamble, we always like to ask the origin story of people, but maybe you can just say off the top like, what is butter CMS? What's a headless CMS, and then we'll get into your background and getting up to today.
Jake Lumetta 0:57
Sure. So what are CMS is, I guess the term for it is a headless CMS. I'm debatably on the fence on that term. If I'm if I'm totally honest, it's like the technically accurate term, which is kind of an API first CMS. But the really the important thing there is we're also kind of SaaS based as well. So it's, I like to say we're just kind of a modern approach to CMS. So we can get into what that what that means. Exactly. But yeah, we're have the CMS,
Will Vincent 1:24
Carlton, you're familiar with headless CMS? That also rings a bell for you? No, yeah, no.
Carlton Gibson 1:29
I mean, I like it. I like the the phrasing as API first. I think that's captures it much more, except we're headless.
Will Vincent 1:38
It makes more sense.
Carlton Gibson 1:39
I don't even know what that is.
Jake Lumetta 1:42
And why is it so violent?
Carlton Gibson 1:46
I mean, do we want to just dive straight into this now? Because you've got me all excited. Oh, shoot. Yeah. Go ahead. Okay, well, fine. So okay. So headless CMS, it's quite cool, because, I mean, the idea I think originally was for this kind of model was that you would be producing applications for you allow you to deploy your content and multiple platforms at the same time. So it was like when, when the mobile first design wave came through, and you know, mobile phones, and then we're going to hang on, we're gonna need to define designer content, not just for laptop screens, but also these tiny screens, and then turns out Oh, actually, we're going to need to stick them on 48 inch Teles or 70 inch TVs, and then we're going to need to Yeah, so I mean, you know, can you perhaps riff off that it's that that's the that was how I got into
Jake Lumetta 2:38
these things. Yeah, if I'm, if I'm totally honest, that wasn't what I came about as kind of just, I mean, it is cliche, but it really is kind of scratching my own pain or solving my own pain that I experienced when I was the CTO at some previous startups prior to founding founding butter. And so that is to say, like, to your point, I didn't, I didn't necessarily found butter with kind of the broader vision of what you described of having kind of a multi channel approach to being able to serve content, although that's been a wonderful, a wonderfully important kind of benefit of the approach a butter, like an API for CMS. So that the water came about when I as I mentioned, before, I was working at a previous company, we were like an energy marketplace. So you can comparison shop for for different energy providers. But here here in the US, I know it's quite popular overseas here, but in the US, about half the states are deregulated. So we were building an energy marketplace. And the CMO came to me at the time and said, Hey, Jake, you know, we need to be able to write blog posts. So the business was a marketplace, like, you know, Expedia, or kayak but for energy, and we were building in Jenga, which I'm super happy to say, Yeah, so the freaking Tinker for a really long time. And CES. Exactly, yeah. So we're building this marketplace in Django, the whole business was the marketplace. But we needed to kind of add on CMS capability into that. And so I was like, oh, you know, I've heard of this WordPress thing. Like, that's the thing you used for if you need CMS for blogs. And so let's go and do that. The one kind of catch here is that we didn't want to just, well, there's a few catches, but we didn't want to just like throw the blog on a subdomain, because it's not really optimal for SEO. So we wanted, you know, our site.com/blog. We didn't want to blog to iset.com. Although the latter is technically easier, just throw it out a subdomain and let it be. So we wanted to deeper integration or parts of the URL routing, you know, the sub directory of blog was handled by WordPress, but then everything else was handled by the Django app. And to achieve that, you know, I started when I went on this basically this adventure of like, what it what it takes to achieve that, what it really means to kind of set up a custom WordPress blog where, you know, we didn't want to just like kind of a pickup theme, we wanted it to look nice and like, branded and kind of match the rest of the company site and the colors and the fonts and the logos and like all that kind of stuff. And so we really went about this exercise of completely skinning WordPress to not just say,
Carlton Gibson 5:13
isn't that what the question right?
Will Vincent 5:16
I'm only slightly kidding, right? People do do that. Oh, no,
Carlton Gibson 5:19
no, no, I'm not biting on it. This. How do you match a WordPress theme to eject to the rest of the site is built with presumably Django templates watching ginger templates? Oh, yeah.
Jake Lumetta 5:29
I mean, I outsource that. So I didn't, I
Carlton Gibson 5:32
didn't make it look the same as that. Yeah.
Jake Lumetta 5:36
As like, I focused on building the business. Like, you know, I don't know WordPress, I think I guess I just literally just did not know WordPress, and never worked with it before. So I hired somebody that that did. And kind of have them handle all the headaches. But your question is right on the nose of like, what does it actually take to go in? And just on this point of like, making a WordPress site look like your existing company site? Like what does that take? And what does it mean? And even once you achieve that, and this was learning to, you know, once we had a really great looking company, branded blog, on WordPress, you know, we had the header that matched in the footer that match the links in the menus kind of all match. And when you click back and forth between the blog and the main site, you couldn't really tell. But that lasted for about, I don't know, two weeks until we like change something in the main site, you know?
Carlton Gibson 6:26
And then it's because you're maintaining these two parallel sets.
Jake Lumetta 6:30
And I was like, Oh, this is not going to be easy to keep this in sync, right? And so what are your options there? One, you can just let them drift.
Carlton Gibson 6:38
Just before it before you fix the problem, how do you solve how did you How did you solve the routing problem? So did you were you proxying, from Django to WordPress? Or did you have some sort of Nginx? Or fun? Routing bike path? Do
Jake Lumetta 6:51
you remember offhand to be honest? Yeah, I feel like nginx magic. Yeah. I feel like we did some engine work. Yeah. You know, it's a dark place, it's a dark place to kind of push that down. And
Carlton Gibson 7:05
you can work out with a therapist.
Jake Lumetta 7:07
I'm being overly dramatic here. But yeah, but these are, these are kind of my personal pains that I went through. And these were learnings, you know, I never gone through it before.
Carlton Gibson 7:15
But also from a business point of view, like you, you know, it's all about velocity, right? It's all about you, let's get we want this change, we want to get out quickly. And then all of a sudden, you're running these two parallel implementations, and you like the kind of ability to update is you just your velocity just falls through the floor? Because you got to do twice as much work for each chain?
Jake Lumetta 7:34
That's exactly right. Yeah. I mean, you you it doesn't seem obvious until you've really done it. And so if you've done it, you can relate to this. But like just adopting, you know, adopting WordPress, in our case, eight, like 2x is just the overhead, kind of across the board, right, you now have like two different code bases, you have two databases that you need to worry about, you have possibly two servers. Depending on how you host and run WordPress, you have just two systems to kind of keep up to date, you know, WordPress, you have to kind of keep it patched. And the plugins, you have to keep those patched and that kind of thing. So it's just, it doesn't, it's not the end of the world, but it is a quite a big, big like chunk to to sort of take on, you know, and again, what WordPress was doing for us was, it was just, it was our blog, like, you know, that's what it was. That's what it was doing. So it didn't, it didn't really seem kind of worth all of that work time, effort overhead, just to kind of achieve blogging, when again, our core business was like building his Django application would you know, for our marketplace, so? Yeah, really, really insightful. kind of process that yeah, that I went through there.
Will Vincent 8:39
Did you have that at a couple companies or as for research for the show? You've you had a couple startups. And I think you mentioned that you in the same Django plus WordPress had more than one place or don't have that wrong?
Jake Lumetta 8:50
Yeah, no, that's right. I mean, it's, it's a lot unbelievable, but it actually it's true, like, so the first startup I was at, that got acquired, it was we were based in Chicago, we had raised like a Series A round, that got acquired by a larger company, doing the exact same thing, just a bigger plate, you know, just a bigger fish doing the exact same thing. They were also built us build using Django, which was just a total coincidence, but it was like, you know, from one Gengo to the to the next, doing the exact same business model, same industry, everything. And so that time around, yeah. So, so that can be got acquired. So now part of the the new company, also kind of a venture backed venture backed company, larger team doing things that are a bit bigger scale. Same problem came about though, eventually, and we said, okay, you know, the marketing team came to the engineering team and said, Hey, we need a CMS. And I said, and we want to use WordPress, I said, No, I've, you know, let's not, here's what I've learned. And they said, Well, what do you propose? And as like, Oh, that's a good question. And so we looked around and we've looked for just open source kind of Django, CMS is that we can kind of kind of plug it in Now I personally didn't lead the project. Someone else on the team did, but and I forget the name of the one that we stumbled upon. It was it was not django CMS or or wagtail, or any kind of well known ones, it was, I think something smaller. But you know, from from the dev team side, it plugged in beautifully, it was super easy to set up, you know, we just, you know, installed the CMS and like, from an implementation standpoint, were great. Then we handed over to the marketing team. And we said, Here's your dashboard that you use to, you know, create landing pages and upload images and resize things. And yeah, and you see, this is going and I like, like, this is not, we cannot go no thing. Like I tried to upload the image I lost on my work, like, how do we resize images, you know, like, we can't do just the UX was not quite there. And I was like, oh, man, you know, so I thought I'd want you know, I want the initial battle, but lost the war ultimately. So, you know, I said, Let's not go with WordPress, we went to open source route, because it was more differently. And it was it was great. But the market is didn't like it. So So then they ultimately came in with the veto and said, we need to we want to use WordPress, we're gonna use WordPress, like you guys, you guys had your chance to like, we're gonna go with WordPress. And that was, that was even worse that that time around the scope was just much bigger. But yeah,
Carlton Gibson 11:25
that's so that's such a good story. That's like, I just feel like, because I sort of I lows, like, not lows, but like I sort of started to have lows, these these kind of constrained UIs that CMS is give you and the kind of the way they've got the form and that you put your text in there and you'd like but I just want to add a bit in and you can't because the page definition isn't right. But on the other. That's because I'm a developer. And I basically just want to hang out HTML Exactly. On the other side of that there's real people out there who want to create content. And what they want is a nice UI that gives them the flexible the exactly the flexibility they want, but also the guardrails so they don't go off and you know, it's kind of worked on it safe.
Jake Lumetta 12:15
Exactly. Yep. So no,
Will Vincent 12:17
it's interesting. You're fascinating level in terms of your CTO, and then you were a tech leader, but you also were feeling this pain, because I feel like I mean, every company has this pain, I was at a No matter your stack, you need a blog, and you go to WordPress, and it's terrible. But a lot of times the devs don't feel that pain enough, or it's not someone high enough to change. It is more of like a low level dev kind of gets. gets that in my experience. Yeah. So it's kind of fortuitous. I wonder if it's a function of size, or just that you were, you know, CTO, and you were still dealing with this and still cared on top of doing everything else, because a lot of times it is yeah, lowest on the totem pole, spin up a WordPress. In a startup environment. It's not the most seen as the most important
Jake Lumetta 13:02
thing. Sure. Anybody? Go figure it out? Yeah. No, I
Will Vincent 13:06
mean, I remember doing this when I was before I was technical at a startup in San Francisco. And we had, every time you log in, you have to update all the packages, and there's 12/3 party add ons, and it's like, seems risky, and
Jake Lumetta 13:18
stuff spreads roll the dice, right? Yeah, there's a roll. Yeah.
Will Vincent 13:22
Yeah. But it wasn't like a CTO level of concern.
Jake Lumetta 13:26
Yeah, I think. Yeah, it's a good point. So at the first startup, we weren't we were quite small. I think we were like, 10 people. So I maybe had like myself and a couple other devs on the team. So it was a very small team. So yeah, so at that point, yeah, it was just like, one of my concerns. At the the follow up company, what we when we went the WordPress route, we, we brought on a WordPress agency. So the first time around, I hired just a WordPress freelancer and kind of he just worked on the blog and you know, did a good job. But then the second time around, like I said, it was a much bigger kind of scale project at a bigger company. And so we hired on WordPress agency, pay them quite a bit of money per year, you know, great guys. And they do WordPress, and we just sort of kind of handed it over to them, although we weren't able to totally hand it over to them, which is another kind of challenge here. Because like, even if you think, as an engineering leader, again, to your point, like if I'm VP of Engineering, and I say okay, I have a team of amazing Python, Django engineers, our core business is this like Django platform? Let's not bother our core team with this WordPress stuff. Let's just have an agency deal with it. Who gets called when the marketing site goes down? Right? Like, if you're, if you're if you're good at negotiating, you can make it so that's the agency that's that's called but like, ultimately, you're on the hook. Right? It's like why would you hire that agency? Like what's the deal like you are, you know, the buck stops with you ultimately as engineering leader so you can't totally sort of wave your hands. Wash your hands of responsibility for for the marketing side. All To me, so there was always that tension of like, you know, there's that tension. They're like, Okay, well, if something slow or something went wrong, like, whose fault is it? And all that kind of all that kind of stuff and who's really responsible for what? So that gets beyond the technical challenges more of a people issue, I suppose. But.
Carlton Gibson 15:18
But outsourcing it's not not just like the job disappears. It's not like Spanish. Yeah, you know, it's still
Jake Lumetta 15:25
overhead. Exactly. Yeah. Yeah. So was it
Will Vincent 15:29
2017 Then when you started butter CMS? And was that after you'd been at this place? Or do you do it concurrently? Like, what's the origin story of butter? Yeah. So
Jake Lumetta 15:39
after going through these pains, just like it was really like just a deja vu, you know, pain. And it was like, Okay, maybe not a full pattern. But there was two data points there. And I'm like, Okay, this is like, this is, you know, this has to happen to other folks. Like I
Will Vincent 15:54
write and you paid money. That's the thing. It was like, You were happy to pay money. It's just the money wasn't getting what you want it totally.
Jake Lumetta 16:01
Yeah, totally. Yeah. So you just look back at those those those experiences? And I was like, Okay, well, well, WordPress is great. It's got amazing ecosystem, like, you can do a lot of cool stuff with it. But just, you know, for that circumstance, where you're not using WordPress, you know, you're building technology, that's just not WordPress, if you're starting at that point, and you need to add CMS capability to you need CMS capability, then what's like a what, how should that work? Like, what would be a really great experience there? And so I sort of just tried to sit down from first principles of like, you know, what are some of the kind of the core pillars of what would make a great CMS, in my opinion, in my mind at that point in time, right. And so that's really what led me to like some, some key kind of decision criteria. So I mean, it's really not rocket science, like, the first thing is, that should be an amazing developer experience. So I started with that. And so what does that mean? You should be able to use any technology stack that you want, you should build to add like you should build whatever this new CMS thing is going to be, you should be able to use it with any technology stack. So like, it has to work with Django, you should work with Ruby and Rails dotnet, C sharp, and now all these JavaScript frameworks, react, Angular view, etc. Like, it shouldn't matter what you're using technology wise, you should be able to benefit from this, like new CMS platform, whatever that was going to be. And so is it. Okay, well, that means it should be it needs to be API based, you know, API first, like it can't be. It can't be It can't matter what the CMS is built in what the actual CMS is built and should not matter in determining whether or not you can adopt it. Right. And with WordPress, like that's the case, like it's built in PHP. So if you want to use WordPress, you're going to be adopting PHP, and you're gonna need to care about like how that works, and how to run that kind of thing. So, so that was like one big thing. So a great developer experience API first, second piece, again, this is just from my, from the learnings here, second piece of house have a great market experience, it has to be like a really great dashboard. And so, you know, so that's kind of a given, otherwise, you just going to go through my experience of like losing the battle to the marketing team, if they can't use the CMS ultimately to do their job. Or if they keep need to keep, like looping you in to, to get things done. That's a lose, lose anyways. So now, you know. And then the third piece, and again, this is a little bit unique about our, I suppose. But I guess in hindsight, it's not that unique anymore. But you know, going the SAS based approach, so offering as a software as a service, where what that means is we host and maintain the whole CMS platform. And so that's like, we hosted maintain the content dashboard. And we host to maintain and scale and secure and backup the data and the API side of things as well. So when you're adopting butter, or when you're using butter, it's like, and what I wanted, you know, I was like, What do I want, it's like, I don't really want to host a CMS, like I'm building an energy marketplace, like I don't really want it hosted, I don't want to host anything new, like I just want to add CMS to my current like little stack. And so with butter, you don't have to like, have a new codebase there's no additional database, there's no additional servers, you just literally connect to the API. And pull in content in real time into your application from butter. So like when someone logs blog blog posts on your site, instead of fetching that blog post content from your database, you just make an API call over to butter and butter returns that blog post content in like a structured JSON format is like is literally just how it works. So yeah, so those are some of the kind of key design philosophies around like what I was aiming for with with butter.
Carlton Gibson 19:30
I think the SAS thing works really well as well, you know, so I, you know, freelance for forever. And, you know, you're always looking for each client, you're always like, Well, okay, I can host something for them. But then you know, then you've got If difficulties with, like, getting a support contract from them, and you know, how's that gonna work out and it's always an awkward conversation. They never want to pay upkeep. Whereas if you can just sell them a SAS and it's like, yeah, no, you know, I'll implement it all for you and but you know, it's gonna be the SAS and Azure AD. About 80 bucks a month fee that you know, and then that conversation just goes away. So I think from from my sort of independent point of view, like, you know, developing for clients, that's a great model as well, it's not just like a tech company wants to CMS, but that's not their speciality. It's agencies, it's, you know, any number of people would want that SAS hosted solution
Jake Lumetta 20:20
for sure. And we do see that a lot. Like certainly a large part of our customer base, and folks using butter, you know, are freelancers and agencies for sure. Exactly. to your to your point. So, yeah.
Will Vincent 20:32
Is it developers who come to you? Or do you ever get marketers come to you, I mean, did does the headless CMS thing, throw off a marketer, it's kind of both but like, who's the decision maker, usually,
Jake Lumetta 20:43
it does very complicated company and kind of project by project team by team, most of the time, it's the developer. That might be that's probably probably a function that we do a lot of marketing to, you know, to developers. But, you know, from time to time, we do have a say like 10 to 20% of the time, it's a marketer, or like a business person, or like a project manager or something like that, who kind of discovers butter, and they're trying to solve their own pain, and they see butter, and it's like, oh, this seems like a thing that, you know, our devs would like to work with. So like, they feel safe saying like, Hey, guys, check this out, like what do you what do you think about butter that as well, like come kick the tires. But at the end of the day, it usually is both? For especially for like larger projects. It's pretty rare that like, it should say, rather, it's quite common that, you know, both the marketer and ultimately the end user, whether that's a client of a freelancer or the marketing team, of you know, the company, the developer works at like they ultimately do, kind of have to approve in kind of check, check off on a button saying like, Yeah, this is, this is a nice experience. We're okay, working with this kind of thing.
Carlton Gibson 21:52
Yeah, there's always a process of getting that agreement. Yeah. I've decided you're using
Jake Lumetta 21:59
that doesn't. Exactly, yeah.
Carlton Gibson 22:03
So you've obviously built in Django, and you talked about the marketing side, having that nice UI, and that nice experience for the marketers that and you, you, that's the bit you build, right, so they can log in, and they see all that they've got the editing side of it, that that's, you know, that's sort of the value, the value of that logging into butter to edit your content.
Jake Lumetta 22:24
That's right. So that's from the marketer side, exactly, as you described. So the marketers go log in, and they have our dashboard, that again, the thing I love about the SAS model is just, we're able to, kind of you're like, always, like using the best version of butter, always, you know, like, we're able to kind of roll out changes pretty quickly. And anytime we ship a new feature you on as a customer of butter or user of butter, like just automatically habit, like the next day you log into your account or whatever, which is, I think, a super, super cool thing. So but yeah, so you know, that's the marketer experience. And then the devs also log into butter to do if you've worked with the FSA house before, or if you haven't, basically, you know, butter is kind of built from the ground up to be completely kind of the assumption is that you're sort of building up your own what we call like content model, or, you know, we have like, you know, content types or page types and that kind of thing. So, you know, like, we have a UI in butter, where you go in and you say, like, Okay, we want to set up, we want to add a knowledge base to our site, right. And then the first thing you do in butter is you go use our, our page builder UI, which is basically a data modeling or content modeling kind of UI, where you're just like, Okay, I want to add a short text field, that's called a headline, I want to add a body field, that's a WYSIWYG field, I want to add a date time picker, for what, you know, whatever. And you just kind of go and compose your your page type and butter. And it's built, it's built with that in mind. That's, so it's intended to be like really fast for you to do this kind of custom content modeling, from the developer experience side of things.
Carlton Gibson 23:57
So that's kind of like defining a Django model, right? So you go, you know, my New page, type my base page, and I had this field, I had this, how on earth are you doing that dynamically? That's, you know, that's
Jake Lumetta 24:12
that's what a lot of blood sweat and tears. But into the data model behind butter is quite interesting and generic, like behind the scenes, but you know, we try and obfuscate all of that from you, and you don't need to really worry about it. You just got to go use the, the the UI, and this sort of works for you. But
Carlton Gibson 24:33
can you can you can you give us some sort of high level overview of that, you know, geeky,
Jake Lumetta 24:38
I'd say yeah, so we have kind of like three core solutions. So one is like a plug and play blog engine. And so with the blog engine, you know, that that solution really is focused on the blogging use case, as you might imagine. And so for that behind the scenes, you know, the Django model for that is probably what you would expect it was like one of the first things that I built, that was the first thing I built when launching when launching, but it was like a blog blog could have many blog posts or blog posts can have an author. And it can have many tags, it can have many categories. And I think that pretty much covers it like that. That's it and model for blog. So it's, it's, it's probably what you would expect, you know, it works, you know, 90 95% of the time for most kind of off the shelf blogging, use cases of what you need. And then this is, I guess, kind of going to evolution of butter. So we actually just launched with the blog engine, and then we expanded into the other two solutions we have, which are pages and collections. And so pages are really focused on like, we just kind of described before, like different allowing you to launch kind of different page types. So it's super customizable. So the blog engine, I guess, also, just to kind of put a point on that the data model for that is pretty straightforward. And it's not super flexible, like you can't really customize. If you want to use our plug and play plug ins, and you can't go in there and like customize things like the blog, the blog post is defined as a different fit custom fields. So when you want to do customization, then that's when we really and that's why we launched pages and collections. So collections you can think of as like tables of data, literally like a lot of concepts there, just from a data modeling perspective. So like a collection is the table. You know, the collection has what we call items. So there's like the rows and the table. We have internally, this is super, super in the weeds here. But like we have for the columns, we call those keys or like collection item keys kind of a thing for like, like, what are the columns in that table. And then each row has multiple cells. So those are like the collection item values, and then the cells can have history. So we have version history. So the values can have historical values as well. So and this is, you know, these are all things that kind of evolve over time, you know, and we can speak about that, too. But
Carlton Gibson 26:58
yeah, but so it sounds as if it's like a kind of each custom page, a custom page, or custom collection is like a kind of lookup table from you know, these are the keys it's got, and then you have to look up the values for the matching keys I imagined that's quite an elaborate. And the matching that gets quite quick, quite expensive to query quite quick. Yeah. I mean, are you doing that with Django? Are you? Have you built that in the Django? Yeah,
Jake Lumetta 27:23
it's all built with Django. Rest framework. So we've Yeah, over time, we've done a lot of performance optimizations, just by necessity, you know, and it's just these things that you run into, like, some new customer comes on board, and they do some something you had never seen before, didn't really expect and, you know, started throwing out some some red flags and signals and alerts and that kind of thing. And you go dig into the, you go dig into the queries of like, What the heck is the ORM? You know, what's the actual query being run here? And yeah, so we've had a lot of a lot of those kinds of battles of trying to track down slow queries, adding missing indexes. But Caching, caching caching caching caching was, you know, is like, critical. I mean, we have caching kind of many different different layers. But yeah, it can get pretty Yeah, it can get pretty, pretty complicated.
Carlton Gibson 28:18
So I'm imagining for any given project, they've got the particular definitions or particular content definitions in play, and then you'd have to cache the results of those fetches in order to make them. Yeah,
Jake Lumetta 28:32
that's right. Yeah. So I mean, the biggest performance area for us is that our API first and foremost, because you know, a lot of our customers are just calling the API in real time. So that means like one or 2% of pageviews, like every page view, just makes a call to the butter API. And so if you multiply that, like across all of our customers, it's a lot of API traffic. So yeah, so you know, like, one thing we do at the API level. First and foremost, is we implemented a service called fastly? It's like a global CDN. It basically sits in front of Yeah, so if you've ever used fast layer, who
Carlton Gibson 29:08
said, well, since fastly has come up, you use fastly every single time you have access to the Django Doc's. Okay? Because they are an input. They are an encounter, sponsor of the Django project, and they give us who knows how much works of free bandwidth each month. Thank you. Thanks very much.
Jake Lumetta 29:25
Yeah, I love I love fastly. They have some, if you're looking for, yeah, so fastly is kind of a think of reverse varnish cache. They have a global CDN network of nodes that kind of run and from the butter CMS perspective, they sit in front of our application servers. So what that means is when you quote unquote, make an API call to butter 99.9% of the time, you're actually just going to give a cache JSON payload back from like your nearest node. And so majority of traffic doesn't even hit the application server. And these response times are like really fast, you know, 15 milliseconds or less. So Yeah, so fastly is huge in that regard. And then when when fastly, you know, when the cache is cool, there's not something in fastly, then, you know, then it does actually hit the application server. And then what now we're in Django territory where we actually go have to go and kind of serialize the pages that you're that you're requesting, right? So you could say, hey, butter, give me give me, you know, our 10 most recent blog posts or give us, you know, give me you know, the 20, kind of top knowledgebase articles, right. And then the butter has to go and kind of serialize those pages based on that page type or that custom, that custom data model they you defined. And then yeah, it returns it just in a clean JSON format. Ultimately, it has key value, key value pairs, we have some more complex field types, that you know, so it's not just like a flat kind of JSON object that comes back, you can start doing some pretty complicated kind of content modeling as far as like concepts and stuff of having one page reference another page. So you have like, you know, page a references page B. And what that means is when you serialize and request page A from the butter API, you're actually getting page a serialized along with be serialized in the same in the same API response. So for example, that could be like showing a knowledgebase article. And then at the bottom of the knowledgebase article, you show like related articles, or other articles that they might want to check out that kind of thing. So yeah, so like, so references is like one of those field types that changes the game in terms of complexity is like, holy cow. There's like so many more challenges just by introducing this, like one additional kind of building block field type into butter.
Will Vincent 31:38
But yeah, okay, that sounds nice. Yeah, no, I mean, the this piece, the performance and the caching at scale, which you are is really interesting, because you don't think about it, when you're starting out with Django, but in a real project, this is where you spend all your time on. But can you talk about purging the cache, right? Because you warm up the cache bit? Like, are there some rules of thumb because you don't just keep it forever? For listeners who haven't done a lot with caches?
Jake Lumetta 32:03
Yeah, great question. So I mean, caching holy cow. You know, I don't know, I was just thinking to myself, like, it'd be great to have like a book or a rule guide or something. I mean, there's a lot of articles around caching, but it's never like, you're sort of just like, my systems on fire, like, how do I solve this? Like, what is the best way to do the caching? You know what I mean? And it's sort of like, well, it depends, you know, and it's like, okay, you gotta really trying to figure this out for yourself. But the caching strategies have evolved over time. Let's see, what can I share here? Oh, so yes, about cache purging? Yeah, so like, you know, one thing with cache purging is, at least the strategy that we have is we aggressively cache as far as TTL. And so we aggressively cache on TTL length. So we kind of try and cache forever. And then when you let's say, go publish, you know, publish a page, like you update your homepage in butter. Then we try and do like precise kind of cache purging so that it doesn't leak overly, like, clear the cache out. Like it shouldn't clear the cache for content that wasn't really impacted.
Will Vincent 33:06
Right? Like it cuz like, if using CloudFlare, you can do per dollar, you can custom and do
Jake Lumetta 33:11
custom. Yeah, exactly. So with fastly, actually, that was one of the reasons why we went fastly in earlier, they have this concept of surrogate keys, I'm not sure if call for does or not, I'm sure they have something something similar, but the concept of surrogate keys where it's like, just a little string identifier, you can have multiple kinds of string identifiers, and you pass in the header that you returned from the application server, and then fastly kind of just strips that header out and stores that and associates that array of keys to that cache, a data, whatever it whatever it is JSON. So if you go update your homepage in butter, you click the Publish button, we will. For us, there's that we have both memcache and application level. So we have memcache things that we need to go clear out. But then we also go and clear out fastly at the kind of the CDN level as well. So we can have multiple pieces of the cache to clear out. Yeah, and so yeah, so that's, you know, that's interesting, interesting, kind of fun, fun challenge. But then there's, there's the, like, when you clear the cache, like, when you update your homepage, you go clear the cache out of butter. At one point, we would just say, okay, clear the cache, and our job is done. And then the next time you request your homepage, it will just go right raw to the application server, you know, and the application server will actually we'll serialize your homepage, you know, JSON data in real time. And, you know, maybe it takes five seconds. And like that's it is what it is, but then like after that it's kind of it's, it's cached, right? And so for a while, that worked out, okay. But then we're like, Well, how do we how can we even get rid of that? How can we get rid of that delay? And so now we do pre warming of the cache. So we'll actually when you update your homepage, will will in the background, pre pre serialize your homepage and then once that proves it shows pretty serialization is done. We'll stuff that into the cache. And then we'll go clear fastly. So then the next time you have an API call, like the cache is never called, basically, is what we try to try to achieve. And that's
Carlton Gibson 35:11
brilliant. Because by the time you switch browser tabs from editing it and you go right, or go back and reload it to see if it's exactly, and it's like, Oh, wow.
Jake Lumetta 35:18
Yeah, that's like,
Will Vincent 35:20
I think Instagrams hack, one of its Django based hacks back in the day is when you opened when you like, loaded a picture, as you like, immediately started uploading it, even as you're typing out the information around it. So it felt faster than all the other clones at the time. But just because they were just slamming your, your cell data, which you had to pay for it. You couldn't really see it, but that was one of their tricks. Oh, nice. Okay. It's not really strictly a caching thing. But it's kind of like things happening. It feels faster, fast, right? Even if it's not necessarily.
Jake Lumetta 35:53
That's a great example. Yeah, that's cool.
Will Vincent 35:55
Yeah, we should actually we should get, we should get Frank Wiles from repsonse. If he can, he's anecdotally told me a whole bunch of Instagram Stories of scaling stuff. They had two of them. And they're just like, they, I think they they blew up the I can say this, there's, like the number of users you can have. And in Postgres, they like, had so many that they were like hitting all these weird edge cases. Because they were just Django and Postgres starting out. Okay, we use post. I wanted to ask, yeah, so it's Postgres. And are you? I believe he says on the site, you're on Heroku. AWS? Is that what's the hosting piece? Yeah,
Jake Lumetta 36:35
we use Heroku. To run application servers, we use Heroku, Postgres for that for the database.
Will Vincent 36:40
Yeah. Managed manage DBS.
Jake Lumetta 36:43
We use Redis Memcache.
Will Vincent 36:47
How are you feeling about Heroku? Can I ask that publicly? Yeah, there's some I mean, you know, it like because I've been spending all this time just with my books. But like, I think everyone at scale is kind of like, okay, like, Yeah, I've been paying I'll pay it's works really well. But if Salesforce is going to come in, and yeah, new could that be nice to have a heads up more than the two months? They gave? Like free projects?
Jake Lumetta 37:09
Yeah. Yeah, it's definitely it's, it's been a tough period to be a Heroku customer, actually had the fortunate opportunity to talk to the guy who's running Heroku. Now, that is name is Bob, Bob why's and I was asking about this, this was after like, the security, the security breach, because that was like really painful way to go rotate our keys and stuff like that. Thankfully, we weren't impacted. But you know, it was just a lot of noise and headache. And not not fun this. And he had a lot of good things to say, he has a lot of experience. He came from AWS, he was running there. I think it was Kubernetes. Division, which I think he said it was like, larger than roaccutane or something like that, you know,
Will Vincent 37:53
internet scale, it's actually NASA.
Jake Lumetta 37:56
So, so I think they they have a good lead. And he's pretty, pretty, pretty new there. At least to Heroku. So so they've got a great guy, I think in place there, said, You know, he's gonna be focused on security, reliability, and that kind of platform stuff. So I think as far as the Heroku roadmap, if you're, and I'm just this is totally my opinion, I don't I don't actually have any insight or anything like that. But my sense is that they're going to be focused on just like uptime and security, which, you know, that's pretty darn important if you're using Heroku. And so I'm glad I'm glad to hear that. But if you're expecting like a bunch of kind of fancy new whiz bang features, I would not be kind of expecting that. Now, here's the thing. I have looked at some of the alternatives. I haven't tried them. But you know, I definitely have kind of started poking around. And you know, I just saw a lot of kind of coming soon, kind of things that Heroku already has baked in. Well, the
Will Vincent 38:50
Manage Database, like not to name names, but a bunch of the interesting ones don't have that yet. Like saying that. It's like, well, it's a little hard. I think it's harder than maybe it seems at first, because it's a big thing to be like, it's not managed for you. Yeah, I mean, yeah, you can you can go to crunchy was crunchy data. We're gonna have Conchita there and upgrade on in a couple of weeks. But yeah, that's funny. They have posts. Yeah, I mean, he's great. Like, but you know, these places have, they have Postgres was not managed for you. So it's a little like, how much can you trust it? To your point about it just being coming soon. And a whole host of other services that Heroku already has exactly baked in?
Jake Lumetta 39:30
It's been really insightful, actually. I mean, it's it really blew my mind like, wow, Heroku is just they were just so far ahead of like the curve and I mean, they still kind of are even though a lot of this stuff has existed for I don't know. It's a great Kragle though, but you know, many many years. Yeah. Which is just like I think it really testament to like that Heroku team, like they really cranked out a lot of stuff. I mean, working with databases in Heroku I will say like Heroku Postgres is pretty darn magical. Like I'm not a DBA by any means, and just my experience of, you know, they automatically maintain your database. You know, it's easy to like upgrade to a larger tier, you know, I was actually chatting with Craig, when we were writing this some database performance issues and stuff. And he's like, just you should just get a bigger, bigger database. So the Okay, and then, you know, it's like, well, what does that like, you know, how do we do that without any downtime? Because that's the thing with butter. I mean, there's a lot of pros to sass but like running a SAS is, is, it's tough because you can like not have any downtime, like zero downtime. Because if API goes offline, then our customer sites go offline. So it's, it's like zero, like literally zero downtime is what we is what we aim for. So yeah, so we had to do like kind of a live production database upgrade and and the Heroku made that a much less painful process as far as kind of just setting up the follower in the background and getting all the data set to sync and then just promoting it and just kind of having it all heavier work. So Anyways, long story to your question, but I'm still I'm still pretty happy yeah. With with Roca, they they do a lot of things really well,
Will Vincent 41:04
no, I'm happy to hear that. I mean, Carlton has a button that's coming out. And you know, there are new things, but I don't think anyone wants Heroku to go away. And seems like they've got this two people at scale, too. So
Carlton Gibson 41:17
but I think they just like buttons, not not looking to be a Platform as a Service. So it's not really looking to compete with Heroku. It's the but the I think the thing with Heroku, is they just Salesforce have said, Look, we just don't want this free traffic anymore, this free traffic source zero to us, we don't want it and we're gonna get rid of it. And from a business, as sad as that is from the sort of, you know, the community built lots of sites around Heroku for many years. From a business perspective, it kind of makes sense. It's like frees them from a massive load of costly traffic, to then focus on their core business, it might actually do Heroku, a world of good to be free of this free plan, which is sort of that's a goodbye. Yeah. They built upon for so long. It's
Jake Lumetta 42:02
really good point. I mean, if you're a fan or want to see Heroku succeed, it's a great point that you raise. Yeah, totally. Because I think those free plans where a lot of noise, I think is where the majority of the fraud and you know, kind of not great behavior took place without we're on those free plans. And so they can just kind of get rid of all of that, then yeah, it's a great point that you raise,
Carlton Gibson 42:25
can I ask you about high availability, because you just said you can't have you can't have zero downtime, like literally zero downtime? And a lot of people they try it, they do, they may, you know, if they have a couple of minutes of downtime, while they update, it doesn't really matter. They could be down for all night, and it doesn't matter. You know, there's no, there's no real cost. But in your case, no, it really does matter. So kind of, can you just give a very high level sort of what do you do for high availability with multi region multi this multi that multi?
Jake Lumetta 42:51
Yeah, so multi region caching. Like I said, the fastly does help as well. So, you know, in theory, and we really aggressively cash too. So I mentioned before, you know, we don't have like short TTL. So we try it aggressively cache. And we try to precisely purge the cache. And that has some pros and cons, I guess, just to kind of dive into caching strategy, maybe a bit as well, like, The con of aggressive caching. When I say aggressive caching, I mean, like, Max TTL. Like, it should never expire. The the pro of that is that it never expires. So it's like, great for performance. And such. The con of that is that if you don't get your caching right, then then the customer does not get updated data. And so, you know,
Carlton Gibson 43:42
if you accidentally cache on recap,
Jake Lumetta 43:47
banking on that, like, update Save button and butter, and it's just like,
Carlton Gibson 43:51
still recursively
Jake Lumetta 43:54
Exactly. So that's yeah, so that's been, I wouldn't say a major challenge, but like, that's been, you know, has been thing that we've kind of had to fight with just based on that design design decision. The Pro though is that, in theory, you know, if Heroku completely went down, you know, for 30 minutes or an hour or something like that, it's possible that you would not even notice it. If you're fetching content notice, because it's all cached in a fast layer. So that's a big benefit.
Carlton Gibson 44:24
I guess a lot of content sites, they're kind of very much read hit more read heavy than they are right. Like this many more retail, right?
Jake Lumetta 44:32
Yeah. Wait, wait. Yeah. So yeah,
Carlton Gibson 44:36
so. Okay, and then I guess the one I'd like to sneak in there is about upgrades and database migrations, like so, you know, you got to upgrade your your Django application, you know, 4.2 comes out, you want to upgrade to 4.2 that, you know, you have a rolling process.
Jake Lumetta 44:54
We, I mean, we try and stay I mean, certainly within within LTS you know, within the LTS ban. We actually just went I think, I don't remember if I think we're on three two now. But yeah, we would. That's definitely top of mind. We try and stay up to date for sure with it within the LTSP. And we don't you know, we don't try not to push it too close to the edge. Where it's like, you know, we're switching over like the day before it falls out. Yeah.
Carlton Gibson 45:24
Security got nice. You've got a nice wedding.
Jake Lumetta 45:27
Yeah, exactly. No, but yeah, we definitely try and stay. We do stay on top of kind of maintaining and updating the latest Django versions and such. Yeah, for sure. Okay. Yeah.
Will Vincent 45:38
Do you have more, Karl than I feel like you've got a lot of questions today.
Carlton Gibson 45:42
Well, no, I mean, I could talk for
Jake Lumetta 45:44
literally forever. Yes, my database migrations and talk about there.
Carlton Gibson 45:48
Yeah, well, okay. Yeah, well, so like, because this is the big challenge is, you know, if I'm going to make a schema change, and my little site, it doesn't really matter. If I run the migration, the site might be down for a minute or two, no one's really gonna notice. But if you can't really have downtime, then you've got to think you've got to structure your migrations a lot more carefully have this kind of, you know, the field migrate the data, remove the old field, the multiple steps that can exactly
Jake Lumetta 46:13
yeah, I mean, you know, that's pretty much it. Yeah, exactly. So we those kinds of conversations. Heroku has a nice feature, I'm forgetting what it's called. It's like zero downtime, zero downtime deploys, or something like that. It's got maybe a bit a bit more than that. But so that's something we're taking advantage of. Now. It's pre boot pre boot. Thank you. Yeah. Yeah. So it's pre boot, where it's zero downtime. I guess I mentioned that, because for most of our deploys, you know, they don't have a database, right? Migration involve? If they do have one that is backwards compatible, then it's fine to use it as well. It's when you get into one that's not backwards compatible, that you have to like, kind of disable that and sort of work around that. But yeah, in general. Yeah. You know, like some of the some of the decisions and kind of sort of logistics, I guess, of doing some of the database. Database migrations are things that we yeah, we work through.
Will Vincent 47:12
So you have SDKs for all the different like languages and frameworks. How many are you up to now? Did I hear 30? Something? Oh, geez.
Jake Lumetta 47:20
Let's see. Yeah, it's a lot better. cms.com/docs? Yeah, it was hard to count the bubbles. Three 412 2428. Ish. 2728. Sounds like a lot call 30? Yeah, it's a lot. Yeah. The first one, by the way, just the first bubble. And that was Django. The very first one. The second one was was rails. So this goes way back, but Django was the first bubble, followed by rails. Yeah.
Will Vincent 47:50
Okay, it's two questions. One is, so if if I'm this a Django chat podcast, if I'm on a Django site, I would think most people look at butter, and you look at Django, CMS and wagtail. The other ones like, you can't use those as easily. What's the quick pitch for like, what those don't offer the butter does for someone listening? Who's a dev or a marketing person, like with this need?
Jake Lumetta 48:11
Sure. Well, you know, I don't know, I mean, I'm sure there's some differences in features and such, I won't, I won't kind of wax on about about that, I think in terms of a fundamental difference is that butter is SAS versus, you know, versus, you know, like an open source kind of software that you install into your into your project. And so, again, for some people, if you want to, like you cannot self host butter. So like if that, that that's a mandate, where you have to, essentially run the whole CMS platform, and you need the CMS data to be in your servers and like that kind of thing, then like butter is not gonna be a good fit. So I would say, you know, go with other systems. But if you are, if you're like our customers, or our users who like, don't want to run a CMS, or don't want to adopt any additional source code, or software, or if you don't want to run any part of the CMS, if you want, if you don't want to worry about scaling it, if you don't want to, won't have to worry about backing up the data. You know, I kind of will go on and on about the list of SAS things, putting my sales head on there. But like, that is like the reason why in when I found out about it, I made it to be SAS, it's like, it's going to be for those folks who like kind of value. Who value that stuff, basically. But yeah,
Carlton Gibson 49:30
yeah, that makes sense. Yeah. And it's very sensible to give yourself a clear demarcation like that. Yeah. Because if you make it if you did, if you were to think, oh, we'll make it install where you can store your own, then you kind of, you know, going head to head then it's Yeah, that's a whole dang CMS. It's like,
Jake Lumetta 49:46
you know, and I'd be lying if I said we had considered it I wouldn't I would say we haven't strongly considered it just because I've asked around and it's like, it's, it's just a totally different it's a totally different from a business perspective and its operations and Customer Support and that kind of thing. It's a totally different game. So, yeah, I mean with with the SAS model, it's nice. Just because I mean, from our perspective, being able to provide great service, you know, that's part of it, too, we haven't really talked about that, like, we talked about what the tech stuff but like, if you use butter than, you know, anytime you're logged into butter, or even like trying to install butter get set up, like we have a little chat bubble on the site. And you know, it's real people there who will chat with you and kind of help you and provide you support throughout the entire thought the entire process, whether it's like during the initial kind of DEV setup phase, or once you've handed it over to your client or your marketers, and they're having trouble, you know, getting an h2 tag to work or whatever it is, you know, so we're there to give support kind of throughout the entire process. And that's just baked into the service.
Will Vincent 50:46
So I have one more I wanted to ask, so you were Django con and butter had the nice notebooks I've got. I've got mine right near here. Awesome. What? Like how was that experience for you? And what do you think like Django can do better on corporate sponsors? This is something Carleton I have things we're working on. But you know, both as an attendee and then as a as a sponsor? Like, what could Django do better?
Jake Lumetta 51:08
Geez. So attending Django con was awesome, like, way overdue for me on a personal note, like I've been working in Django forever. And I don't know, I haven't kind of taken kind of sooner. So. So those both the first time I attended Django con and you know, also happened to be as a sponsor, so Yeah, we'll definitely go back next year. Looking forward to that. Yeah, so it was a great experience. A lot of the name just putting names to fit. Yeah, faces to names a lot of folks have just been in conversations with already. And so it's great to, you know, come across you guys on the on the interwebs. and such, and now it was great to get to meet you in person. And here. Here we are. Right. Due to that. So it is really awesome. Really awesome time. How what can Django con
Will Vincent 51:53
like, are there other? I mean, I don't know rails? Like is there a framework that mean? It often feels like some of these like view are more corporate friendly because of their structure? So I just yeah, just, yeah, curious if there's any blatantly obvious thing, Carlton, I have our own list. But as a sponsor you like oh, yes, I would bump up a tear. Give more if, if Django gave me XYZ,
Jake Lumetta 52:20
gotcha. I don't have a, I don't have a great list there. I think as far as I mean, I don't know if this is contentious or not. But you know, like as far as sponsoring and getting corporate sponsors for just leading up to the Django site here. So like, you know, Django project.com. You know, if we're, if we're open to the idea of maybe being a bit more aggressive with showing sponsor logos or something like that, somewhere on the site, or throughout the docks, I've seen other kind of more newer frameworks do that. Again, I don't know where that falls on the okayness spectrum. But if we're talking like trying to, if the end goal here is just to like increase dollars, then I think that that could be that could be something there too, of just like, hey, put your logo here. And it's just like, no matter what page you're on, and the Django Doc's, you just, it doesn't have to be like obnoxious or anything like that. There are some frameworks that I think do it pretty pretty well, that can help drive some drive some dollars, I
Will Vincent 53:19
think, Carlton, what are you gonna add on that? I think we've worked. We've talked a lot about
Carlton Gibson 53:23
Yeah, well, I mean, one thing we've, we've said to each other loads, and loads and loads of times, and we've probably said the podcast a billion times, but we'll say it again, is, you know, if you're a corporate sponsor, you kind of have to dig around to find where you're, where you're, you're, you know, you do get your logo on the fundraising page, but you kind of have to dig around to find that logo. And it's like, you know, you can see why companies are bit like, wow, you know, I think I kind of think we should be a bit more forthcoming with, you know, front and center, hey, these companies are really going out of their way to support the framework, and we say, thank you.
Will Vincent 54:00
But there are things that float, Carlton, I don't think we can announce anything publicly yet. But there's actually things happening around, there's lots of talk. So some things will happen. I mean, you know, at a minimum making the fundraising page, look better, the sidebar, why not have corporate sponsors there, you know, and then the homepage is maybe a separate discussion, but there's a lot we could do. Could do and we'll do especially if we need to, but anyways, we've got we talked about that enough on the podcast, I think.
Carlton Gibson 54:32
I mean, Jake, well, you at Django con hype, because you're hiring or just to raise awareness, I guess
Jake Lumetta 54:37
a bit of Yeah. Maybe a triple triple thing. Yeah. One is a raise awareness of butter. I mean, really, one is is I've been a Django dev for forever. So just getting in the community meeting folks. And then two was yeah, now that running up Django company, I guess of sorts then. Yeah, getting awareness of butter from a customer perspective, but then also also recruiting so I mean, I guess on that front we are hiring. So I'll just put put that out there. But yeah, so we're, you heard our stack I guess we're Django Django company, we do use Vue. JS on the front end, I don't think we've covered that. But we use Vue. JS, in our dashboard experience to kind of just make it more interactive, and mildly so but that's, that's, those are the kind of the two things. The two core technologies we use intersect.
Will Vincent 55:24
And you're going to keep that you're going to switch all to HDX because that's what all
Jake Lumetta 55:27
right, actually, we were sponsoring HTMX. Yeah, we actually just became a sponsor of HTMX. actually hearing about it at Django con. seemed to have a lot of love Django con. I had not I'm a little bit behind the HTMX train, but I'm trying to catch up quickly here.
Will Vincent 55:45
But we had him on this podcast. So he gave his full spiel, but Oh, very nice.
Jake Lumetta 55:50
Okay, I'll check that out. Let's see. Yeah, it
Will Vincent 55:51
was I think two years ago.
Jake Lumetta 55:54
Two years ago, okay. Yeah, what not afraid,
Will Vincent 55:56
something like that. But I agree that I think it's, it's nice. You have templates, HTML, and then you can go to View and these others and there's a nice on ramp, and you can mix and match. So it's right. I think when you're learning full stack, you just feel like I'll never get the who's full stack. But you don't really have to be truly full stack. Maybe as much things to HT Max as you would before.
Jake Lumetta 56:20
Right. Totally. Yeah. It's beautiful. Oh, Carlton,
Will Vincent 56:23
we're sort of at time there any, we'll put a link to your hiring page. Are there any last questions or things you wanted to mention? Jake?
Jake Lumetta 56:30
I don't think so. This really thank you guys for having me on. It was this was a great chat. A lot of great content. Yeah, a lot of great questions. A lot of fun.
Carlton Gibson 56:37
Thanks for digging down. I know you, it seems like, Oh, do we need to get into those teasers? Now? Those details are exactly what we're
Will Vincent 56:45
unapologetic genetically technical here, because we can be?
Jake Lumetta 56:48
Yeah, for sure. Well, hopefully, hopefully, I was able to give some color. I guess the one thing is like, yeah, give some color behind the scenes of like, scaling a CMS, I guess, you know, it conceptually is very simple to say like, yeah, I can just go build the Django app that like is a blog or whatever. And totally, you know, selfishly, I'll say like, please don't do that. Like, just don't, don't do that. You know, like, that's why butter exists. Like, we're trying to save you from that. Because then
Carlton Gibson 57:18
this is this is, this is a joke, like, cuz when you were talking about your WordPress experience, I'm like, But surely you just did what every Django developer does their own blog.
Jake Lumetta 57:27
It's not that complicated. But it's, it's just, it's just, you know, it just is the beginning of a very long path of you being on the hook for building a great like blogging experience that you're hopefully, you know, the clients and marketers will like, constantly have requests for feature requests and all this kind of stuff, which is, which is what we spend full time doing now. So anyways, but yeah, hopefully some of the cash and your Bootstrap, right, we didn't get a chance to ask your Bootstrap, right? Yep. Yeah. Yeah. Even more impressive. Yeah. So yeah, we're completely bootstrapped. We haven't raised any outside funding. So yeah, so it's been really great journey. Okay, well, thanks
Carlton Gibson 58:04
for coming on. For my perspective, it's really great to, you know, there's several, there's lots of companies out there that using Django at high scale, but it's, it's nice to talk to them, because in the sort of scope of all projects, it's a very small percentage of all Django projects that need to scale that up to that big label. So it's really nice to get that inside story. Yeah,
Jake Lumetta 58:22
for sure. Yeah. It's been it's been a lot of learning. Fun. And yeah. Yeah, it's been it's been a great journey. So hopefully, I've shared some tips and insights to folks that are that are helpful. I really hope it's helpful to other folks out there.
Will Vincent 58:37
Thank you again, Jake. We are a Django chat.com. We are for now chat Django and Twitter. Who knows how long that'll be around but you have to set up a foster done. What instance server what do you call it? Babies account. Thank you again. We'll see everyone next time. Bye bye.