Transcript: Butter CMS - Jake Lumetta

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Hello, Will.

Welcome, Jake.

Pleasure to be on.

Super excited.

Thank you for coming on.

You and I were both having breakfast there, I think.

And as one does, just said hi, who are you?

What do you do?

You said you worked at ButterCMS, 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.

But 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.

So Butter 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 I like the technically accurate term, which is kind of an API-first CMS.

But the really the important thing there is uh we're also kind of SaaS-based as well.

So it's I like to say we're just a kind of a modern approach to CMS, so we can get into what that what that means exactly.

But yeah, we're we're we're headless CMS.

That also rings a bell for you.

No, I mean I I like it, I like the um the phrasing as um API first.

I think that's captures it much better because it were headless.

What's that?

You've got me all excited, or should we go on the use of for it?

Okay, well, fine.

So it was like um when the mobile first design um uh wave came through when you know mobile phones and then we're gonna hang 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 gonna need to stick them on 48-inch tellies or 70-inch tellies, and then we're gonna need to so I mean you know, can you perhaps riff off that?

It's the that's the that was how I got into cooling.

Oh, totally.

And so um that is to say, like to your point, I didn't I didn't necessarily found Butter with kind of the 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 the approach uh of butter, like an API first CMS.

Um so the the butter came about when I um, as I mentioned before, I was working at a at a previous company.

Uh we were like an energy marketplace.

Um so you can comparison shop for for different energy providers, but here in the US, I know it's quite popular uh overseas here, but um in the US, about half the states are deregulated.

So um we were building like an energy marketplace, and uh 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 Django, uh, which I'm super uh happy to say.

Yeah, so been working in Django for a really long time.

Yeah, um, so we're building this marketplace in Django, the whole business was the marketplace.

Um, but we needed to kind of add on CMS capability into that.

Um, 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 um well there's there's a few catches, but we didn't want to just like throw the blog in a subdomain because it's not really optimal for SEO.

So we wanted, you know, rsite.com slash blog.

We didn't want just blog.rsite.com, although the latter is technically easier, you just throw it out of the subdomain and let it be.

So we wanted a deeper integration where parts of the URL routing, you know, the subdirectory of blog was handled by WordPress, but then everything else was handled by the Django app.

And um 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 and 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 pick a theme, we wanted it to look nice and like branded and kind of match the rest of the company's 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 uh WordPress to match our site.

People do do that though.

I'm not I'm not I'm not biting on that.

This is how do you match a WordPress theme to a jet to the rest of the site that's built with presumably Django templates or Jingo Ginger templates or yeah.

Yeah, you just make it look the same as that.

Yeah, I was like, I think you know, we're focused

Like, you know, I I don't know WordPress, nothing against it.

I just literally just did not know WordPress.

I never worked with it before, so I hired somebody that that did um and kind of had them handle all the the headaches.

But your question is right on the nose of how like what does it actually take to go in?

Uh, 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 too, you know, once we had a really great looking company branded blog on WordPress, you know, we had the header that matched and the footer that matched, and 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 changed something in the main site, you know.

And I was like, oh, this is not gonna be easy to keep these in sync, right?

And so what are your options there?

One, you could just let them drift.

Hang on,

hang on, hang on.

So did you were you proxying from Django to WordPress or did you have some sort of Nginx in front?

Um routing by path, or do you recall it?

Yeah, I feel like we did some Nginx magic, yeah.

I feel like we did some Nginx magic, yeah.

Um you know it's a dark place.

It's a dark place, and I just kind of pushed that down,

you know.

You can work out with the therapist at like

And these were learnings, you know, I've never gone through it before.

It's all about you look, let's get we want this change, we want to get it out quickly, and then all of a sudden you you're running these two parallel implementations, and you like the kind of ability to update is you just your velocity just sort of falls through the floor because you've got to do twice as much work for each change.

That's exactly right.

Um, I mean you you you it doesn't seem obvious until you've really done it.

Um, and so if you've done it, you you can relate to this, but like just adopting, you know, adopting WordPress in our case, it like 2x is just the overhead, uh 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, um, depending on how you host and run WordPress.

Um, 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 just 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.

Um so it didn't it it didn't really seem kind of worth all of that uh work, time, effort, overhead just to kind of achieve uh blogging.

When again our core business was like building in this Django application with you know for for our marketplace.

So um yeah, really, really insightful uh kind of process that yeah that I went through there.

And I think you mentioned that you won the same Django plus WordPress at more than one place, or do I have that wrong?

I mean it's it's a little unbelievable, but it actually is true.

Like, so so so the first startup I was at, um, that got acquired.

Uh 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 place, you know, just a bigger fish doing the exact same thing.

They were also built use built using Django, which was just a total coincidence.

But it was like, you know, from one Django to the to the next, doing the exact same business model, same industry, everything.

Um and so so that time around, yeah, so so uh so that company got acquired.

So I'm now part of the new company, um, also kind of a venture back, venture back company, larger team, doing things at a bit bigger scale.

Same problem came about though eventually.

And we said, okay, you know, the the marketing team came to the engineering team and said, Hey, we need a CMS.

And I said, and we want to use WordPress.

And I said, no, I've, you know, let's not.

Here's what I've learned.

Here's what I've learned.

Let's not let that route.

And uh I was like, well, that's a good question.

Um, and so we looked around and we've looked for um uh just open source kind of Django uh CMSs that we can kind of kind of plug in.

Um now I personally didn't lead the project.

Um someone else on the team did, but and I forget the name of the one that we we stumbled upon.

Um it was it was not Django CMS or or Wagtail or any kind of the well-known ones.

It was, I think, something uh uh uh smaller.

But you know, from the dev team side, it plugged in beautifully.

It was super easy to set up.

You know, we just you know installed the the CMS and and like from an implementation standpoint it worked 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 and you know, and they're and you know, you two this is going.

And they're like, uh-uh, like this is not, we cannot use this thing.

Like I tried to upload an image, I lost all my work.

Like, how do we resize images?

You know, like we can't do just the UX was not quite there.

Um, and I was like, oh man, you know, so I thought I'd won, you know, I won the initial battle, but lost the war ultimately.

So, you know, um I said, let's not go with WordPress.

We went the open source route because it was more dev friendly, and it was, it was great, but the marketers didn't like it.

Um, so so then they ultimately came in, you know, with kind of the veto and said, We're we need to we want to use WordPress, we're gonna use WordPress.

Like you guys, you guys had your chance, like we're gonna go with WordPress.

Um, and that was that was even worse.

That would that that time around, the the scope was just much bigger.

Um, but yeah.

That's like I I'm just feeling that in my heart.

I really am.

Like because I I loathe, like um not loathed, but like I still historically have loathed um these these kind of um constrained UIs that CMSs give you, and the the the the the the kind of the way they've got the form and that you put your text in there and you like, but I just want to add a bit here, 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 hand code HTML.

Exactly.

On the other side of that, there's there's real people out there who want to create content, and what they want is a nice UI that you know gives them the flexible exactly the flexibility they want, but also the guardrails so they don't go off and you know it it's gonna work for them, it's safe.

Yep.

Like 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.

It's more of like a low-level dev kind of gets gets that in my experience.

Yeah.

So it's I don't know, 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 in the totem pole, spin up a WordPress in a startup environment.

It's not the most seen as the most important thing.

Just make somebody go go figure it out.

Yeah.

No, no,

Just roll the dice, right?

Yeah, there's roll roll the dice.

Yeah, exactly.

But it wasn't like a CTO level concern.

Um Yeah,

So at the at the first startup, uh, we were we were quite small.

I think we were like 10 people.

Um, so I don't I maybe had like my myself and a couple other devs on the team.

So it was a very small team.

So um, yeah, so so at that point, yeah, it was just like a uh 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.

Um 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.

Um, 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 a WordPress agency, um, pay them quite a bit of money per per year.

Um, you know, great guys, and they knew WordPress, um, 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 BPM 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 good, if you're if you're good at negotiating, you can make it so that it's the agency that's that's called, but like ultimately you're on the hook, right?

It's like, well, why would you hire that agency?

Like, what's the deal?

So you can't totally sort of wave your hands uh uh wash your hands of responsibility for for the marketing site, uh, ultimately.

So there was always that tension of like, you know, there's that that tension there of like, okay, well, if something's slow or something went wrong, like whose fault is it?

And and all that kind of all that kind of stuff, and and who's really responsible for for what?

So um that gets beyond the technical challenges more of a people issue, I said I suppose, but right.

But outsourcing's not not just like the the job disappears, it's not like it dispanishes exactly.

Yeah, yeah.

And was that after you'd been at this place, or do you do it concurrently?

Like what's the origin story of Butter?

So, like I Right.

It was like you were happy to pay money, it just the money wasn't getting what you wanted.

Yeah, totally.

Um yeah, so I you just sort of look back at those, those, those experiences, and I was like, okay, well, well, WordPress is great.

Um, you know, it's got an 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, um, 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 well, how should that work?

Like, what would be a really great experience there?

And so I sort of just try to sit down from first principles of like, um, you know, what are some of the kind of the core pillars of what would make a great CMS in 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 um, I mean, it's really not rocket science.

Like, the first thing is that it should be an amazing developer experience.

So I started with that.

And so, what does that mean?

Um, you should be able to use any technology stack that you want.

You should be able to add, like, you should be able to, whatever this new CMS thing is gonna be, you should be able to use it with any technology stack.

So, like, it has to work with Django, it should work with Ruban Rails, uh.NET, C sharp, and now all these JavaScript frameworks, React, Angular View, et cetera.

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 gonna be.

And so I said, Okay, well, that means it should be, it needs to be API-based, you know, API first.

Like it can't be it, it can't be, it can't matter what the CMS is built in.

What the actual CMS is built in should not matter and in terms in determining whether or not you can adopt it, right?

And and with WordPress, like that's the case, like it's built in PHP.

So if you want to use WordPress, you're gonna be adopting PHP and you you're gonna need to care about like how that works and how to run that kind of a thing.

So that was like one big thing.

So a great developer experience, API first.

Second piece, again, this is for just from my from the learning scare.

Second piece, it has to have a great marketer experience.

It has to be like a really great dashboard.

Um and so uh, you know, so that's kind of a given.

Otherwise, you're just gonna go through my experience of like losing that 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 get things done.

Um, that's a lose lose, anyways.

Um, so now you're you know.

Um, and then the third piece, and again, this is a little bit unique about Butter, I I suppose, but I guess in hindsight it's not that unique anymore.

But you know, going the SaaS-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 host and maintain the content dashboard and we host and maintain and scale and secure and back up 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 um, 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 to host, I don't want to host anything new.

Like I just want to add CMS to my current like little stack.

Um and so with Butter, you don't have to like have a new code base, there's no additional database, there's no additional servers, you just literally connect to the API um and pull in content in real time into your application from Butter.

So like when someone logs a blog blog post on your site, instead of fetching that blog post content from your own database, you just make an API call over to Butter, and Butter returns that blog post content uh in like a structured JSON format.

Is like it is literally just how it works.

So um, yeah, so those are some of the kind of key design philosophies around like what I was aiming for with with Butter.

You know, um, so I you know freelance for forever.

And you know, you're always looking for each client, you're always like, well, okay, I could host something for them, but they're you know, then you've got if difficulties with um like uh 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 upgrade.

Whereas if you can just sell them a stat and it's like, yeah, no, well, you know, I'll implement it all for you, and but you know, it's gonna be their stat, and there's your 80 month, 80 bucks a month fee that you know, and then that conversation just goes away.

So I think from from a sort of um independent point of view, like you know, developing for clients, that's a great model as well.

It's not just like a a tech company wants to a CMS, but that's not their special, it's agencies, it's you know, any number of people would want that hosted solution.

And we do see that a lot.

Like certainly a large part of our customer base and folks using Butter um you know are freelancers and and agencies for sure, exactly to your to your point.

Um, so yeah.

Okay.

I mean, does does the headless CMS thing throw off a marketer?

Because it's kind of both, but like who's the decision maker usually?

Most of the time it's the developer.

Um that might be a that's probably probably a function that we do a lot of marketing to, you know, uh to developers.

Um but you know, from time to time we do have, I say like 10 to 20% of the time, it's a 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 slinging, like, hey guys, check this out.

Like what do you what do you think about butter?

And the devs will like come kick the tires.

Um, but at the end of the day, it usually is both um for especially for like larger projects, it is it's pretty rare that like um it's it I should say rather it 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 um kind of have to approve and kind of check check off on butter and saying, like, yeah, this is a this is a nice experience.

We're we're we're okay working with this kind of thing.

So quite oh I've decided you're using this.

Yeah, that doesn't that never goes well.

Exactly.

Yeah.

There you are.

That and you you that's the bit you build, right?

So they can log in, 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.

So that's from the marketer side, um, exactly as you described.

So the marketers go log in and they have our dashboard.

Um that and again, the thing I love about the SaaS model is just um 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.

Um and anytime we ship a new feature, you as a customer of Butter or user of Butter, like just automatically have it, like the next day you log into your account or whatever, which is I think a super super cool thing.

So um, 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 a Heavy CMS before, or if you haven't, um basically, you know, Butter is kind of built from the ground up to be completely kind of the the assumption is that you're sort of building up your own what we call like content model, or you know, we we have like you know content types or page types and that kind of thing.

So um, you know, like we have a UI in Butter where you go in and you say, like, okay, we want to set up um, 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 and you just kind of go and compose your your page type in Butter.

Uh, and it's built it, you know, 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 uh from the developer experience side of things.

So you go, but you know, my new page type, my message-based page, and I had this field, I had this.

How on earth are you doing that dynamically?

That's you

Yeah, the data model behind Butter is quite uh interesting and generic, like behind the scenes, but you know, we try and obfuscate all of that from you.

You don't need to really worry about it.

You just kind of go use the the the the UI and then and it just sort of works for you.

Um but

Sure, you know, because we're geeky.

Yeah, so uh we have kind of like three core solutions.

Um so one is like a plug and play blog engine.

Um, 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, um the Django model for that is probably what you would expect.

It was like one of the first things that I I built.

That was the first thing I built uh when launching when launching butter was like you have you have a blog, blog can have many blog posts, a blog post can have an author, uh, and uh it can have many tags, it can have many categories, and I think that pretty much covers it.

Like that, I think that's a data model for for blogs.

So it's um it's it's probably what you would expect.

You know, it it works you know 90, 95% of the time for for most kind of off-the-shelf blogging use cases of of what you need.

Um and then this is, I guess, kind of going evolution of butter.

So we actually just launched with the blog engine, and then we expanded into um the other two solutions we have, which are pages and collections.

And so pages um are really focused on um what we just kind of described before, like different allowing you to launch kind of different page types.

Uh, 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 blog engine, you can't go in there and like customize things.

Like the blog, the blog post is defined as

Um, 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.

Um, you know, the collection has what we call items.

So those are like the rows in the table.

Um we have internally, uh, this is super super in the weeds here, but like we have for the columns we call those keys or like uh collection item keys, kind of a thing for like like what are the columns in that table.

Um and then each row has multiple cells.

So those are like the collection item values, and then the the cells can have history.

So we have version history.

Um so the the values can have historical values as well.

So and this is you know, these are all things that kind of evolved over time, you know.

Um, and maybe we can speak about that too, but yeah.

I imagine that's quite an elaborate so I'm imagining that gets quite queer, quite expensive to query quite quickly.

Yeah.

I mean, are you doing that with Django?

Are you built have you built that in the Django ORA?

Um 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, start throwing off 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?

Um and yeah, so we've had a lot of uh a lot of those kind of battles of trying to track down slow queries, adding missing indexes, um, but caching, caching, caching, caching, caching was, you know, it is like critical.

I mean, we have caching, yeah, kind of at many different different layers, but um yeah, it can get pretty, yeah, it can get pretty um pretty complicated.

Yeah.

So um, I mean the biggest performance area for us is the our the API, first and foremost, just because you know, um a lot of our customers are just calling the API in real time.

So that means like 100% of page views, like every page view just makes a call to the butter API.

Um and so if you multiply that like across all of our customers, it's a lot of API traffic.

So um uh yeah, so you know, like one thing we do at the API level, first and foremost is we implemented a service called Fastly.

Um it's like a global CDN.

It basically sits in front of the yeah so if you've ever used Fastly or who

Oh thank you fastly thank you very much fastly

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 get 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, 50 milliseconds or or less um so um yeah so so fastly is huge in in that regard.

And then when when Fastly, you know when the cache is cold there's there's not something in Fastly then um you know then it does actually hit the application server.

Then we're now we're in 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 um uh kind of top knowledge base articles uh right and then but the butter uh has to go and kind of serialize those pages based on that page type or that custom that custom data model that you've defined um and then yeah it returns it just in a clean JSON format ultimately just 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 JS

ON object that comes back you can start doing some um 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 B serialized in in the same in the same API response.

So for example that could be like showing a knowledge base article and then at the bottom of the knowledge based article you show like related articles or other articles that they might want to check out that kind of a thing.

So uh yeah so 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.

But yeah.

Okay, that sounds amazing.

But can you talk about purging the cache, right?

Because you warm up the cache, but like are there some rules of thumbs?

Because you don't just keep it forever for listeners who haven't done a lot with caches.

I mean there's a lot of articles around caching but it's never like you're sort of just like my system's 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 kind of figure this out for yourself.

But the caching strategies have evolved over time.

Let's see what could I share here?

Oh so you asked about cache purging um yeah so like uh you know one thing with cache purging is um at least the strategy that we have is we aggressively cache as far as TTLs and so we aggressively cache on TTL length so we kind of try and cache forever um and then when you let's say go publish you know publish a a page like you update your homepage in butter um then we try and do like precise kind of cache purging so that it doesn't like overly like cle

ar the cache out like it shouldn't clear the cache for concept that wasn't really impacted.

I'm not sure if Cloudflare does or not um I'm sure they have something something similar but the concept of surrogate keys where it's like just a little string identifier you could have multiple kind of string identifiers that you pass uh in the header um that you return from your application server and then Fastly kind of just strips that header out and stores that and associates that array of keys to that cache data, whatever whatever it is JSON.

So if you go update your homepage in Butter you click the publish button we will um for us there's that we have both memcache and the application level so we have memcache uh things that we need to go clear out but then we also go and clear out fastly at the kind of the CDN level uh as well so we kind of have multiple uh pieces of of the cache to to clear out um yeah and so yeah so that's you know that's uh interesting interesting kind of fun fun challenge um but then there

's there's there's like when you clear the cache like when you update your homepage you go clear the cache out of butter um 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 will serialize your homepage uh 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 and so for a while that 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 home page we'll um we'll in the background pre pre-serialize your homepage and then once that pre-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 cold basically is what we try to try to achieve.

exactly yeah it's kind of

So it felt faster than all the other clones at the time.

But just because they were just slamming your um your cell data which you had to pay for but 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 and it feels faster.

Even if it's not necessarily

Because they were just Django and Postgres starting out.

Okay.

We we use Postgres as well.

how are you feeling about Heroku can I ask that publicly sure 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 it works really well but if Salesforce is going to come in and you know nuke it that'd be nice to have a heads up more than the two months they gave like free projects.

I think we we were we weren't impacted um but you know it was just a lot of no noise and and headache and not not funness.

And uh he he had a lot of good things to say um he has a lot of experience he came from AWS he was running their uh I think it was Kubernetes uh division which I think he said it was like larger than all the the whole Heroku team or something like that.

You know just internet

So so they've got a great guy, I think, you know, in place there.

Um, he said, you know, he's gonna be focused on security, reliability, and 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 my sense is that um uh they're gonna be focused on just like uptime and security, which you know uh that's pretty darn important if you're using Heroku.

So I'm glad I'm glad to hear that.

Um, but if you're expecting like a bunch of kind of fancy new whiz bang features, I would not be uh kind of expecting that.

Now here's the thing.

I haven't tried them.

Um, but you know, I I definitely have kind of started poking around.

And um, you know, I I just saw a lot of kind of coming soon kind of things that Heroku already has baked in.

Like they've been saying that, and 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, uh what's it crunchy data?

We're gonna have um crunchy data.

We're gonna have Craig on in a couple weeks.

But okay, yeah.

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 baked in.

I mean, it's it really has blown my mind like wow, Heroku is just they were just so far ahead of like the curve.

And I mean, and they still kind of are, even though a lot of this stuff has existed for, yeah, I don't know, to Cra Craig will know, but you know, many, many years.

It's just

Yeah.

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 um just my experience of you know, they automatically maintain your database.

Um, you know, it's easy to like upgrade to a larger tier.

Um, you know, I was actually chatting with Craig when we were running into some database performance issues and stuff.

Um, and he's like, just you should just get a bigger, bigger database.

I'll be okay.

And then, you know, I was like, well, what is that like?

You know, how do how do we do that without any downtime?

Because that's the thing with Butter.

I mean, there's a lot of pros to SaaS, but like running a SAS is is is tough because you can like not have any downtime, like zero downtime.

Um, because if the 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 um, yeah, so we had to do like kind of a live um production database upgrade.

And the Heroku uh 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 having it all work.

So, anyways, long story to your question, but uh I I'm I'm still I'm still pretty happy, yeah, with with Heroku.

I think they do a lot of things um really well.

I mean, Carlton has Button that's coming out, and you know, there are new things, but I I don't think anyone wants Heroku to go away.

Um and it seems like they've got two people at scale too.

It's um but the the I think the thing with Heroku is they um uh they've just Salesforce have said, look, we just don't want this free traffic anymore.

This free traffic is worth zero to us, and 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

Yeah.

It is a really good point.

Yeah, totally, because um I think those free plans were a lot of noise.

I think it's where the majority of the fraud and and you know, kind of not great behavior took place were on those free plans.

And so if they can just kind of yeah, get rid of all of that, um, then yeah, it's a great point that you raise.

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, they do very they make, 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?

Well it's multi-region, multi-this, multi-that, multi-here.

Um, like I said, the the fastly does help as well.

Um, so you know, in in theory, and we and we really aggressively cache too.

So I mentioned before, you know, we don't have like short TTL.

So we we try to aggressively cache, um, and we try to precisely purge the cache.

And um that has some pros and cons, I guess just to kind of dig dive into caching strategy uh maybe a bit as well.

Like the con of aggressively caching, when I say aggressively caching, I mean like max TTL.

Um like it should never expire.

The the pro of that is that um it never expires, so it's like great for performance and such.

Um the con of that is that if you don't get your caching right, then the customer does not get updated data.

And so, you know.

If you accidentally cache a Rick Astley image, that's yeah, right?

Exactly.

it's just like not updating the site.

Still Rick Astley.

Exactly.

The pro though is that in theory, um, you know, if Heroku completely went down um you know for 30 minutes or an hour or something like that, it's possible that you would not even notice it um if you're fetching content API because it's all cached in in the Fastly layer.

So that's a big benefit.

Like there's many more reads than there are writes.

So um

Like so, you know, you you've got to upgrade your um your Django application.

Um, you know, 4.2 comes out, you want to upgrade to 4.2.

You know, do you have a rolling process there?

Um, but um, yeah, we yeah, we that's definitely top of mind.

We try and stay uh up to date uh for sure with it within the LTS band.

Um 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 it falls out.

Um yeah, or we stay on top of security.

Um no, but yeah, we we definitely try and stay uh we do stay on top of um uh kind of maintaining and updating the latest Django versions and such, yeah, for sure.

Okay, cool.

I feel like you've got a lot of questions today.

Well, so so like because this is the big challenge is um, you know, if I I'm gonna make a schema change and um my little site, it doesn't really matter if you know I run the migration, the site might be down for a you know 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, add the field, migrate the data, remove the old field, yeah, multiple steps.

That kind of exactly.

That that's pretty much it, yeah.

Exactly.

So we yeah, we have those kind of conversations.

Um Heroku has a nice feature, and I'm forgetting what it's called.

Um it's like zero downtime, zero downtime deploys or something like that.

It's got maybe a bit of a more sleepy name than that, but um, so that's something we're we're taking advantage of.

Yeah.

Um, yeah, so so it's pre-boot uh where uh it's zero downtime.

I guess I mentioned that because um for most of our deploys, you know, uh they don't have a database migration involved.

Um if they do have one that is backwards compatible, then it's fine to use as well.

It's when you get into one that's not backwards compatible, um, that you have to like kind of disable that and sort of work around that.

But um, yeah, in general, um yeah, you know, like some of the some of the decisions and and kind of um sort of logistics, I guess, of of doing some of the database database migrations are the things that we yeah, we work through.

How many are you up to now?

Did I hear 30 something?

Oh geez.

Am I making that up?

Yeah, it's a lot of buttercms.com slash docs.

Uh yeah, I always have to count the bubbles.

Three, four, twelve, twenty-four, twenty eight-ish, twenty-seven, twenty-eight, something like that.

We'll call it 30.

Yeah, it's it's a lot, yeah.

The first one, by the way, just the first bubble on there was Django.

Uh, the very first one, the second one was was Rails.

So this goes way, this goes way back, but Django was the first bubble, followed by Rails.

Yeah.

One is so if if I'm this is 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 that Butter does for someone listening who's a dev or a marketing person like with this need?

Um well I you know I I I don't know.

I mean, I'm sure there's some differences in in features and such.

I won't I won't kind of wax on about about that.

Um, I think in terms of a fundamental difference is that Butter is SaaS versus um you know, versus, you know, like an open source kind of software that you install into your into your project.

And so um again, for some people, if you want to like you cannot self-host Butter.

So like if that if that's a mandate where you have to run the whole CMS platform and you need the CMS data to be in your servers and like that kind of thing, um then like Butter's not gonna be a good fit.

So I would say you know, go with uh the other systems.

But if you are um 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 um if you don't want to run any part of the CMS, if you don't want if you don't want to worry about scaling it, uh if you don't want to want to have to worry about backing up the data, um, you know, I kind of will go on and on about the list of of SaaS things, putting my my sales hat on there.

But like that that is like the reason why um, you know, when I found it better, I made it to be SaaS.

It's like it's gonna be for those folks who like kind of value um who value that stuff basically.

But yeah.

Yeah, that makes sense.

Yeah, you know, because if you make it, if you did, if you were to think, oh, we'll make it installable, you can install your own, then you're kind of you know going head to head.

Then it's yeah, that's a whole that's a whole Wagtail or Dang CMS.

It's like you know, and I'd I'd be lying if I said we we had considered it.

So yeah, I mean with with the SaaS model, it's nice.

Um, just because I mean from our perspective, being able to provide great service, you know, that that's part of it too.

We haven't really talked about that.

Like we talked about about the tech stuff, but like if you use Butter, then you know, anytime you're logged into Butter or even like trying to install Butter get set up, like you we have a little chat bubble on the site, and it you know, it's real people there who will chat with you and kind of help you and provide you support throughout the entire throughout 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 tagged worker or whatever, whatever it is, you know.

Um, so we're we're there to give support kind of throughout the the the entire process, and that's just baked into the service.

So I have one more.

Awesome.

Um what like how is that experience for you?

And what do you think like Django can do better on corporate sponsors?

This is something Carlton 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?

Uh so attending DjangoCon was awesome, like way overdue for me on a personal note.

Like I've been working in Django forever.

Um, and uh I don't know why I haven't gone to DjangoCon sooner.

So uh so that was both the first time I attended DjangoCon and it you know also happened to be as as a sponsor.

So um yeah, we'll definitely go back next year looking forward to that.

Um yeah, so it was a great experience.

A lot of the name just putting names to faces to names, a lot of the folks had just been in in conversations with already.

And so it's great to, you know, I've you know come across you guys on on the on the interwebs and and such.

And now it was you know good great to get to meet you in person.

And here we are, right?

Uh due to that.

So it was it was it was really awesome, a really awesome time.

Um uh how what could Django comment?

Um so I just yeah, just yeah, curious if there's any uh blatantly obvious thing.

Carlton I have our own list, but as a sponsor, you're like, oh yes, I would bump up a tier or give more if if Django gave me XYZ.

Gotcha.

Um I think as far as uh I mean I don't know if this is contentious or or not, but you know, like as far as um sponsoring, getting corporate sponsors for um I'm just letting up the Django site here.

So like, you know, Django Project.com, uh, 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, uh somewhere on the site or throughout the docs, I've seen other kind of more newer frameworks do that.

Again, I don't know where that falls on the okayness spectrum.

Um, 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 in the Django docs, you just it doesn't have to be like obnoxious or anything like that.

There there are some frameworks that I think do it pretty, pretty well.

Um that can help drive some drive some dollars, I think.

I think we've what we've talked a lot about this.

And it's like you know, you can see why companies are a bit like, well, what you know, I think I I kind of think we should be a bit more forthcoming at with you know front and center, hey, these companies are really going out of their way to you know support the the framework and we say thank you.

I don't think we can announce anything publicly yet, but there's actually things happening around there's

So I think things will happen.

Um and then the homepage is maybe a separate discussion, but there's a lot we could do.

Could do and will do, especially if we need to.

But anyways, we've gone on, we we talked about it enough that enough on the podcast, I think.

Yeah, one is uh a raise awareness of butter.

Um I mean, real really one is just I've been a Django dev for forever, so just getting in the community and meeting folks.

And then two was yeah, now that running a Django company, I guess, of of sorts, then uh yeah, uh getting awareness of butter from a customer perspective, but then also also recruiting.

So um, I mean, I guess on that front, we you know we we are hiring, so um, I'll just put put that out there.

But um, yeah, so we're you heard our stack, I guess.

We're we're Django, uh Django company.

We do use Vue.js on the front end.

I don't think we've covered that.

Um, but we used Vue.js um in our dashboard experience to kind of just make it more interactive and lively.

So but that's that's those are the kind of the two things, um, the two core technologies we use in our stack.

Because that's what all the talks are about.

Uh actually we we're sponsoring HTMX.

Uh uh Yeah, we actually just became a sponsor of HTMX.

Oh, good.

Um seemed to have a lot of love of DjangoCon.

I had not I'm a little bit behind on HTMX train, but I'm trying to catch up quickly here.

Uh but

Okay.

I'll have to check that out.

Let's see.

Yeah, it

Two years ago, okay.

So we've been at it for a while.

But I I agree that I think it's it's nice you have templates, HTMX, 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.

Um I think when you're learning full stack, you just feel like I'll never get who's full stack, but you don't really have to be truly full stack, um, maybe as much thanks to HTMX as you would before.

Yeah, it's beautiful.

There any we'll put a link to your hiring page.

Are there any last questions or things you wanted to mention, Jake?

Um, I don't think so.

It was this was a great chat.

A lot of great comments yeah, a lot of great questions.

It was a lot of fun.

I know it you know it seems like it oh, do we need to get into those details?

No, those details are exactly what we're off to.

Yeah.

Well, hopefully I 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, um it conceptually is um very simple to say, like, yeah, I could just go build the Django app that like is a blog or or whatever, and um totally, you know, um selfishly I'll 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 we're trying to save you from that.

Um, because then

no, but this is this is this is a joke.

Right?

So, anyways, um but yeah, hopefully some of the cash.

We didn't get a chance to ask about that, but you're bootstrapped, right?

Uh yeah, it's even more impressive.

Yeah, so yeah, we're uh completely bootstrapped, we haven't raised any outside funding.

Um, so yeah, it's just been um a really great journey.

Good.

From my perspective, it's really um great to you know there's several there's lots of companies out there that are using Django at higher scale, but it's what 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 you know to that bigger level.

So it's really nice to get that inside story.

Yeah, it's been it's been um a lot of learning, um fun.

Uh and uh yeah, um yeah, it's it's been yeah, it's been a great journey.

So uh hopeful, hopefully I've shared some tips and and insights to folks that are that are helpful.

I really hope it's it's helpful to the folks

Thank you again, uh Jake.

We are at DjangoChat.com.

We are for now, Chat Django on Twitter.

Who knows how long that'll be around.

But we have to set up a Fosted on what instance server, what do you call it?

Um, anyways.

I can't

So thank you again.

We'll see everyone next time.

Bye bye.

Bye bye.