Transcript: Butter CMS - Jake Lumetta

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.

Hello, Will.

And we're very pleased to have Jake Lumetta from ButterCMS join us. Welcome, Jake.

Thanks, guys. Pleasure to be on. Super excited.

Thank you for coming.

Thank you for coming on. So this came about after DjangoCon US. You and I were both having

breakfast there, I think. And as one does just said, said, hi, 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. 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 sure um so butter cms is um i guess

the term for it is a headless cms um 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 um but really

the important thing there is uh we're also kind of sass 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 had the cms carlton you're familiar with headless cms that also rings a

bell for you no yeah no i mean i like i like the um the the phrasing as um api first i think that's

captures it much better except we're headless yeah it makes more sense what's that i don't

even know what that is we're talking about here and why is it so violent

i mean do we want to just dive straight into this now because you've got me all excited or should

go ahead okay well fine so okay um so um headless cms it's quite cool because um i mean

the idea i think originally was uh for this kind of model was that you'd be producing

applications for or you allow you to deploy your content to multiple um platforms at the same time

so it was like um when the mobile first design um wave came through when you know mobile phones

and then we're going to hang on we're going to 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 tellies or 70 inch tellies and then we're going to need to yeah

so i mean you know can you perhaps riff off that it's sure that's the that was how i got into

cool these kind of things um yeah if i'm if i'm totally honest that wasn't um

butter came about as kind of just i mean it is cliche but it really 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 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 wonderfully important kind of

benefit of the, the approach of butter and like an API for 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,

here in the U S I know it's quite popular, uh, overseas here, but, um, in the U S 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 happy to say yeah so been working django for a really long time hence this podcast exactly

yeah 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 on a subdomain because it's

not really optimal for seos we wanted you know our site.com slash blog we didn't want just blog

to iSat.com. Although the latter is technically easier. You just throw it out of subdomain and

let it be. So we wanted a deeper integration where 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, 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 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 uh wordpress to match our site isn't that what

the admins for interesting question right i'm only slightly kidding right people do do that though

no no i'm not i'm not biting on that this how do you match a wordpress theme to a jet to the rest

a site that's built with presumably django templates or ginger templates or yeah i mean um

i outsourced that so i didn't i didn't right oh yeah you just make it look the same as that yeah

i was like you know we're focused on building the business like you know i don't know wordpress

nothing against 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 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 the links and the menus kind of all matched 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 um right and then you've

got double maintenance because you're maintaining these two parallel sets of templates exactly 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 could just let them drift hang on yeah just before 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 on front um routing by path do you recall

don't remember offhand to be honest 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 i'm just kidding you can work out with the therapist i'm just i'm being overly

dramatic here but uh you know but these are these are kind of the my personal pains that i went

through and these were learnings you know i'd never gone through it before but also from a

business point of view like you you know it's all about velocity right it's all about yeah 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 yeah 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 can relate to this but like just adopting you know adopting

wordpress in our case it like two acts is just the overhead kind of across the board right and

all 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 plug-in 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 didn't really seem kind of worth all

of that work time effort overhead just to kind of achieve uh blogging when again our core business

was like building this django application would you know for for our marketplace so um yeah really

really insightful uh kind of process that yeah that i went through there did you have that at

a couple companies as for research for this show you've you had a couple startups and i think you

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

that wrong? Yeah, no, that's right. 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 plate, you know, just a bigger fish doing the exact same

thing. They were also built, 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-backed venture-backed

company, larger team doing things at 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. And 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, uh, it's

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

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, 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, it worked great. Then we handed it 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 see where this

is going and they're like uh-uh like this is not we cannot use this thing like i tried to upload

the 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 need to we

want to use wordpress we're going to use wordpress like you guys you guys had your chance like we're

going to go with wordpress um and that was that was even worse that that time around the scope

was just much bigger um but yeah that's so that's such a good story that's like i i'm just feeling

that in my heart i really am like because i sort of i loathed like um not loathed but like i sort

of historically have loathed um these these kind of um constrained uis that cms's give you and the

the kind of the way they've got the form and you put your text in there and you're like 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 the flex or the exactly the flexibility they want but also

the guardrails so they don't go off and you know it's going to work when they hit save exactly yep

so i know it's interesting you're just fascinating at your 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 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 yeah 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 sure yeah just pick somebody go figure it out

yeah i mean i remember doing this when i was before i was technical at a startup in san francisco and

we had you know every time you log in you have to update all the packages and there's 12 third

party add-ins and it's like seems risky and stuff's breaking just roll the dice right yeah

yeah exactly yeah but it wasn't like a cto level concern um yeah i think um yeah it's it's a good

point so at the first startup uh we were we were quite small i think we were like 10 people um

so i maybe had like myself and a couple other devs on the team so it was a very small team so

So, yeah, so at that point, yeah, it was just like one of my concerns.

At the follow-up company, when we went the WordPress route, 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 a WordPress agency, paid them quite a bit of money per year, you know, great guys.

they knew 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. Cause 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 at

negotiating, you can make it so that it's the agency that's called. But like ultimately,

you're on the hook right it's like well why did you hire that agency like what's the deal like you

are you know the buck stops with you ultimately as an engineering leader so you can't totally

sort of wave your hands and wash your hands of responsibility for for the marketing site

ultimately so there was always that tension of like you know there's that tension there 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 who's really responsible for what so um that gets beyond the

technical challenges it's more of a people issue i suppose but but outsourcing's not not just like

the job disappears it's not like it just vanishes yeah you know it's still over exactly yeah yeah

so was it 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 after going through these

pains um just like it was literally 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 right 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 wanted totally

yeah totally um yeah so you just sort of look back at those those those experiences and i was like

okay, 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 tried 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 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 it 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 be

able to add, like you should be able to, 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 it should work with

urban rails uh dot net 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 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 what the actual cms is built in should not matter and in determining

whether or not you can adopt it right and and with 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 you're

going to 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 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 going to 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 need to keep like looping you in to to get

things done um that's a lose-lose anyways um so now you know um and then the third piece and again

this is a little bit unique about butter 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 host and maintain

the content dashboard and we host and maintain and scale and secure and back up the 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 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 pulling content in real time into your

application from butter so like when someone logs a 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 literally does 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 i think the sass thing works really well as well 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 going to work out and it's

always a an awkward conversation they never want to pay upkeep whereas if you can just sell them

a sass and it's like yeah no well you know i'll implement it all for you and but you know it's

going to be the sass and there's your 80 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 tech company wants to a cms but

that's not their speciality it's agencies it's you know any number of people would want that

sass hosted solution yeah for sure and we do see that a lot like certainly a large part of our

customer base and folks using butter um you know our freelancers and agencies for sure exactly to

your to your point um so yeah okay is it developers who come to you or do you ever get marketers

come to you i mean does the headless cms thing throw off a marketer it's kind of both but like

who's the decision maker usually? Um, it, it does vary, uh, you know, company to company

and kind of project by project, team by team. 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 saying 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's pretty rare that like um it's it i 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 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 okay working with this kind of thing yeah

there's always a a process of getting that agreement yeah it's not quite oh i've decided

you're using this yeah that doesn't that never goes well exactly yeah there you are so it's

obviously building with Django and you you talked about the um 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 they see all that they've got the editing yeah 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 yeah that that's

right 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 sass model is just um

we're able to 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

have the same house 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 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 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 wheezy wig 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 in butter uh and it's built 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 that's kind of like um defining a django model right so you go you

know my new page type my knowledge base page and i had this field i had this how on earth are you

doing that dynamically that's you know that's the that's what a lot of plus one tiers have been

put into 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're just going to go use the the the ui and then and and it just sort of works for you

um but can you can you can you give us some sort of high level overview of that just you know

so geeky let's see 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 jingle 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 uh when launching when launching

about it was like you have you have a blog blog can have many blog posts a blog post can have an

author uh and it can have many tags it can have many categories and i think that pretty much

covers it like that i think that's the data model for for blogs so it's um it's it's probably what

you would expect you know it works you know 90 95 of the time for for most kind of off-the-shelf

blogging use cases 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 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 it is different custom field

so when you want to do customization then that's when we really and that's why we launched pages

and 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

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 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 well but it sounds

as if it's like a kind of um each custom page say um 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 imagine that's quite a an elaborate i'm imagining that gets quite quick

quite expensive to query quite quick yeah i mean are you doing that with django are you built have

you built that in the Django right yeah it's all built with Django Django so that's kind of cool

framework 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 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 many different different layers but um yeah

Yeah, it can get pretty, yeah, it can get pretty, pretty complicated.

So I'm imagining for any given project, they've got their particular definitions, their particular

content definitions in play, and then you'd have to cache the results of those fetches

in order to make them.

Yeah, that's right.

Yeah.

So, I mean, the biggest performance area for us is that the API, first and foremost, just

because, you know, 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.

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

Yeah.

So if you've ever used Fastly or...

Well, since Fastly has come up,

you use Fastly every single time you access the Django docs.

Oh, okay, very nice.

Because they are an in-kind sponsor of the Django project

and they gave us who knows how much worth

of free bandwidth each month.

Well, thank you Fastly.

Thank you very much Fastly.

Yeah, I love Fastly.

They have some, if you're looking for

Yeah. So Fastly is kind of, I think, a 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 get a cache JSON payload back from 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 less. Um, so, um, yeah, so, so fastly is huge

in that regard. Um, and then when, when fastly, you know, when the cash is cold, there's, there's

not something in fastly then, um, you know, then it does actually hit the application server.

And 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 the butter 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 json 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 the same in the same api response so for example that could be like showing a

knowledge-based 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

um 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 uh into butter um

but yeah okay that sounds amazing 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 what you spend all your time on 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 yeah great question um so I mean caching holy cow um 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 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 got to really kind of figure

this out for yourself um but the caching strategies have evolved over time um 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 page like you update your home

page in butter um then we try and do like precise kind of cache purging so that it doesn't

overly like clear the cache out like it shouldn't clear the cache for content that wasn't really

impacted right like a custom like if using um cloud flare you can do purge at all or you can

custom and do custom yeah exactly so with fastly actually that was one of the reasons why uh we

went fastly in earlier uh they have this concept of circuit keys i'm not sure if claudia does or

not um i'm sure they have something something similar but the concept of circuit 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 it is, JSON. So if you go update your homepage in Butter, you click the publish

button. For us, we have both memcache and the 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 CDN level

as well. So we have multiple pieces of the cache to clear out. So that's an interesting kind of fun

challenge. But then 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 actually will serialize your home page 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 so for a while that worked

out okay but then we were 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 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 uh is what we try to try

to achieve and that's brilliant because by the time you switch browser tabs from editing it and

you go right i'll go back and i'll reload it to see if it's that's all happened and it's like

Oh, wow, it's Insta.

Yeah, exactly, yeah.

Well, that's like, I think Instagram's hack,

one of its Django-based hacks back in the day

is when you opened, when you like loaded a picture,

it like immediately started uploading it

even as you were typing out the information around it.

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

But it's just because they were just slamming 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.

I mean, it's not really strictly a caching thing,

but it's kind of like things happening and it feels faster fast right even if it's not necessarily

that's a great example yeah that's cool yeah we should actually we should get um we should get

frank wiles from revsys on to if he can he's anecdotally told me a whole bunch of instagram

stories of scaling stuff they had where it was like the two of them and they were just like they

i think they they blew up the um i can say this there's like the number of users you can have in

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 postgres but yeah

so 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 like what's the hosting piece yeah we use heroku to run the application

servers we use um and heroku postgres for the for the database yeah managed managed tvs um

we use redis memcache um how are you feeling about heroku can i ask that publicly sure yeah

there's something 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 you know nuke it that'd be nice to

have a heads up more than the two months they gave like free projects yeah yeah it's definitely um

it's it's been a tough period to be a heroku customer um i actually had the fortunate

opportunity to talk to the guy who's running heroku now um i think his name is bob bob wise

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 all our keys and stuff like that i think we we weren't

impacted um but you know it was just a lot of noise and headache and not not funness um 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 there. I think it was Kubernetes, uh,

division, which I think he said it was like larger than the whole Heroku team

or something like that. You know, it's actually massive. Um, so,

so I think they have, they have, they have a good lead and he's pretty,

pretty, pretty new there. Um, at least to Heroku. 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 the 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 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 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 have looked at some of the alternatives i haven't

tried them um but you know i definitely have kind of started poking around and um you know i just

saw a lot of kind of coming soon kind of things that heroku already has baked in well the managed

database like not to name names but a bunch of the interesting ones don't have that yet 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 was it crunchy data we're gonna have um crunchy data we're gonna have craig

on in a couple weeks but okay yeah they have a post yeah i mean he's great like but you know

these places have they have postgres but it's 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 it's been really insightful actually 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 i don't know

it's a craig will know but you know many many years yeah you will know yeah um which is just

like i think a real 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 Heroku Postgres is pretty darn magical.

I'm not a DBA by any means, and just my experience of they automatically maintain your database.

It's easy to upgrade to a larger tier.

I was actually chatting with Craig when we were writing some database performance issues and stuff,

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

I was like, okay.

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

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 SaaS is, is, it's 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, 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 having our work so anyways long story to your question but i i'm still i'm still pretty

happy yeah with with roku i think they do a lot of things um really well no i'm happy to hear that

i mean carlton has button that's coming out and you know there are new things but i i don't think

anyone wants to roku to go away um and it seems like they've got this two people at scale too so

but i think they've just like buttons not not looking to be a platform as a service so it's

not really looking to compete with um heroku it's um but the i think the thing with heroku is they

um they've just salesforce have said look we just don't want this free traffic anymore this free

traffic is worth zero to us we don't want it we're going to 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 good point yeah they built upon for

so long it is a really good point um i mean yeah if you're a fan or want to see heroku succeed

it's a great point that you raise 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 without we're on those free plans and so they can just kind of yeah get rid of all of

that um then yeah it's a great point that you raise 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 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 multi-region multi

this multi that multi yeah so so multi-region um caching um like i said the fastly does help as

well um so you know in in theory and we really aggressively cash too so i mentioned before you

we don't have like short TTL. So we try to 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 aggressively caching,

when I say aggressively caching, I mean like max TTL. Like it should never expire.

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 if you accidentally cache a rick astley image that's

banging on the like update save button and butter and it's just like still still rick astley

exactly so that's yeah so that that's been um i won't say a major challenge but like that's been

you know it has been a thing that we've um uh kind of had a fight with just based on that design

design decision. The pro though is that in theory, if Heroku completely went down for 30 minutes or

like that it's possible that you would not even notice it um if you're fetching content notice

yeah because it's all cached in in the fastly layer so that's a big benefit i guess a lot of

content sites they're they're kind of very much read more read heavy than they are right heavy

like there's many more rights yeah way way yeah so um yeah so okay then i guess the the the one

i'd like to sneak in there is about upgrades and database migrations like so you know you

you've got to upgrade your um you know your django application you know 4.2 comes out you want to

upgrade to 4.2 that you know do you have a rolling process there we um i mean we we try and stay i

mean certainly within within lts um you know within the lts band uh we actually yeah just

went i think i don't remember i think we're on 3.2 now um but um yeah we yeah that's definitely

top of mind we try and stay uh up to date uh for sure with it within the lts ban um 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 um yeah you stand on top of security you've got a nice

you've got a nice window right yeah exactly um no but yeah 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 good yeah do you have more carl then i feel like you've got a lot of questions

today well no i mean i could talk for literally forever yes what database migrations anything

you wanted me to talk about there yeah well okay yeah well so so like because this is the big

challenge is um you know if i'm going to 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 going to 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 yeah i mean you nailed

that that's pretty much yeah exactly so we yeah we had 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 sleeping than that but um so that's

we're taking advantage of oh it's pre-boot pre-boot thank you yeah um yeah 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

they don't have a database migration involved um 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

um that you have to like kind of disable that and sort of work around that but

In general, some of the decisions and logistics, I guess, of doing some of the database migrations

are things that we work through.

So you have SDKs for all the different languages and frameworks.

How many are you up to now?

Did I hear 30-something?

Oh, geez.

Am I making that up?

Let's see.

That's a lot.

ButterCMS.com slash docs.

Yeah, I always have to count the bubbles.

3 4 12 24 28 ish 27 28 something like that okay close but a lot 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 rail so this goes way this goes way back but

django was the first bubble followed by rails yeah uh okay so two questions 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? Sure. Um, well, I, you know, I, 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. Um, I think in terms of a fundamental difference is that butter is SAS

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

butters not gonna be a good fit so i would say you know go with 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 want if you don't want to worry about scaling it if you don't 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 sass things

putting my sales hat on there but like that is like the reason why um you know when i founded

butter i made it to be sass it's like it's going to be for those folks who like kind of value

um who value that stuff basically but yeah yeah that makes sense yeah and it's it's very sensible

to give yourself a clear demarcation like that 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 thing it's like oh

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 it's it's just a

totally different it's a totally different um from a business perspective and there's operations and

customer support and that kind of thing it's it's a totally different uh game so yeah i mean with

with the sass 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 a lot of 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 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 h2 tagged worker or whatever it is you

know um so we're there to give support kind of throughout the the entire process and that's just

baked into the service so i have one more i wanted to ask so you were at django con and butter had

the nice notebooks i've got i've got mine right near here awesome um what like how was that

experience for you and what do you think like django can do better on corporate sponsors this

something carlton and i have things we're working on but you know both as an attendee and then as a

as a sponsor like what could jango do better geez uh so attending jango con was awesome like way

overdue for me on a personal note like i've been working in jango forever um and uh i don't know

why i haven't gone to jango con sooner so uh so that was both the first time i attended jango con

and it you know also happened to be 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

fit faces to names a lot of folks have 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 such and now it was

you know great to get to meet you in person and here we are right uh due to that so it was it was

really awesome really awesome time um uh how what could django con yeah like are there other i mean

i don't know rails like is there a framework that i mean it often feels like some of these like view

are more um corporate friendly because of their structure um 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're like oh yes i

would bump up a tier or give more if if jango gave me xyz gotcha um i don't have a i don't have a

great list there. Um, I think as far as, uh, I mean, I don't know if this is contentious or not,

but you know, like as far as, um, sponsoring, getting corporate sponsors for, um, just looking

up the Django site here. So like, you know, Django project.com, uh, you know, if we were,

if we were 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 are some frameworks that i think do it pretty pretty well um that

could help drive some drive some dollars i think carlton what do you want to add on this i think

we've we've talked a lot about yeah i mean one thing we've we've said to each other uh loads and

loads and loads of times and we've probably said in the podcast a billion times but we'll say again

is you know if you're corporate response you kind of have to dig around to find where you're um 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 a 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 you know support the the framework

and we say thank you but there are things afoot carlton i don't think we can announce anything

publicly yet but there's actually things happening around there's lots of talk so lots of talk i

think 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 um and then the home page 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 out we talked about that enough on the podcast i think

i mean so jake were you at jango con hype because you're hiring or just to raise

awareness i guess a bit of both yeah uh maybe a triple triple thing yeah one is a raise awareness

of butter. I mean, really one is just I've been a Django

dev for forever, so just getting in the community and meeting folks. And then two is

now running a Django company, I guess, of sorts, then

getting awareness of butter from a customer perspective, but then also

recruiting. I mean, I guess on that front, we are hiring,

so I'll just put that out there. But yeah, so

you heard our stack, I guess. We're a 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 lively.

But those are kind of the two things,

the two core technologies we use in our stack.

And are you going to keep that,

or are you going to switch all to HTMX?

Because that's what all the talks are about.

I know, right?

Actually, we're sponsoring HTMX.

Yeah, we actually just became a sponsor of HTMX.

Oh, good.

Actually, hearing about it at DjangoCon.

seemed to have a lot of love of jenga con i had not i'm a little bit behind an hdmx train but i'm

trying to catch up quickly here uh but uh well we had him on this podcast so he he gave his full

spiel but oh very nice okay i'll have to check that out let's see yeah it was i think two years

ago carson okay two years ago okay something like that but i i agree that i think it's it's nice you

have templates hdmx 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 right totally yeah it's beautiful oh carlton 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 um i don't think so just really thank you guys for having

me on is this was a great chat a lot of great yeah a lot of great questions it was a lot of fun

thanks for digging down i know you know it seems like oh do we need to get into those

no those details are exactly what we're after this yeah we're unapologetically technical here

because we can be yeah for sure well hopefully hopefully i was able to give some color i guess

the one thing is like yeah i 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 a django app

that like is a blog or whatever and um totally you know um 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 um because then no but this is this is this is a joke like because when you

were talking about your wordpress experience i'm like but surely you just did what every django

like 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 your clients and your marketers will like constantly have requests for

feature requests and and uh you know all this kind of stuff which is which is what we spend

full time doing now so anyways um but yeah hopefully some of the cash and you're bootstrapped

right we didn't get a chance to ask about that but you're bootstrapped right yep yeah uh yeah

she's even more impressive yeah so yeah we're completely bootstrapped we haven't raised any

outside funding um so yeah it's just been a really great journey good um okay well thanks for coming

on from my perspective it's really um great to you know there's several there's lots of companies

out there that using django at a higher scale but so 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 for sure

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 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 thank you again uh jake we are jango

chat.com we are for now chat jango on twitter who knows how long that'll be around but we have to

set up a foster done what instance server what do you call it anyways i don't know account

thank you again we'll see everyone next time bye-bye