Transcript: pretix - Raphael Michel

I'm Carlton Gibson joined us ever by Will Vincent.

Hello, Will.

Joining us today, we've got Raphael Michael.

Hello, Raphael.

Thank you for coming on the show.

So I know you first from um DjangoCorn Europe back in Heidelberg.

Um, really, but before we get into that, tell us a little bit about who yourself, about yourself and how you got how did you find Django?

How did I find Django?

Um, I I haven't thought about it in a long time.

Um, I think I was a student at high school, and um I was doing a lot of web development on the side as a hobby, um, later as a small mini job.

And there was this German website that um sold t-shirts with IT motives, and they had on their Twitter account uh back when Twitter was a thing, right?

Um they had I think it was a raffle for a free t-shirt.

Um I I I don't remember what you needed to do for it, but I I entered into the raffle and um I don't even remember if I've if I won, but somehow the CEO of that company looked at my website and was impressed by this 15-year-old doing web development and offered me an internship.

Um, that I didn't take because it was in a city at the other end uh on the other end of the country.

Um, but I think that internship description was the first time I saw that Django is a thing, and it kind of made me look into what that is.

So that's quite good because that's almost like the the universe aligning the planets there for you, right?

Yeah, absolutely.

I'm not sure if I've uh officially won it or um but it made me look into into Python first and then later into Django.

Um then I think starting 2013, um every new project I touched uh became a Django project instead of a PHP project.

Yeah.

We should get a support group for such

PHP also has changed a lot or how people use it has has changed a lot since then.

I think they maybe they used to be quite similar back then, and maybe they are more similar today than they were in the time between.

Um but I'm not using it uh anymore.

This is I had one remaining PHP project until like two or three years ago, but now uh it's all gone.

So I mean there's two things that linger, right?

One is in the request object you've got the capital get and the capital post from which was explicitly PHP.

And then the other is the uh the the the template tag for formatting a date.

It uses miraculous, it uses the PHP, and so you always have to look it up because it's not like anything else you use at any other time.

I mean, Laravel really seems to have given PHP a second second wave, if you will.

I know PHP, the language itself, adopted some Pythonic features, and then Laravel is especially for consultancies, has a lot of a lot of features, and in some ways is a little bit easier than Django in terms of you know cookie cutter uh kind of stuff.

It has built-in temp uh host hosting solution, it's got a starter project, and it has uh you know one person in charge essentially, which means they can go a lot faster than we can in Django world.

That's still the old put your files there and it works.

I mean that's the that's the original appeal of PHP.

And then I think the fact that there's a hosted official solution means if you're an agency for sure, just and yeah, uh Taylor, I think the the creator has has talked openly.

I think it's just a couple big boxes he's got running millions of dollars a year of uh hosted stuff.

So just think if just think if Django had something like that.

Anyways.

And this this question comes up quite often.

Should we cop should we copy things from Laravel?

Should we copy things from Rails?

Should we do you know, should we do that?

Is there things that stand out for you that we should be doing as an ecosystem that we're not?

Um probably something I would need to think about more, but also I'm not monitoring the other ecosystems.

Um but well, uh for me, Django very much fits how my brain works.

Um it's similar to like in the JavaScript word, view fits my brain model a lot better than React, for example.

I don't know why.

I I've worked with both and one feels natural to me and the other one doesn't.

And um there is after a decade, I have I've settled in the Django ecosystem so much that like it doesn't bother me anymore if anybody's anything is missing because they have my my strategy, how to deal with it for a while.

Yeah, right.

I think uh those are no secrets, but um I'm also not aware of other ecosystems where I would say, okay, this is per I've seen this this is perfect, we should copy that.

Right, okay, good.

How how do you like to handle authentication?

And we'll get to you have various projects at you know scale and not.

Um that seems to me to be one of the ones where there isn't there isn't one solution for the community.

Uh so how do you like to handle user auth?

I work with long-standing projects that are quite complex and develop over long time frames.

Um so I find that all the the packages that try to do authentication for you are too opinionated or too um specific and don't fit into my products as much as I wanted to.

So for the large projects I'm working on, going with plain Django and building everything on top of myself or ourselves.

Um, yes, I have implemented OpenID Connect from scratch before.

Um, it's not something I would recommend, but um

Like we have an internal, we have a few internal tools built with Django, for example.

We run also our company invoicing on Django, um, basically on the Django admin.

And uh we have a tool that manages the um like something like a package repository for for the software that we developer uh deliver to our clients.

It's also a small Django project.

And for those smaller projects, what I'm missing is um, for example, good two-factor support.

So I'm I'm using one of these packages, one of the many packages for two-factor that I can just like put into my installed apps and it works.

Um and but it doesn't work very well and it's not very nicely integrated, then the templates look different, and it's it's not really not really um the best thing, um, the or the best solution to the problem.

Um I think what I would rather want to see there would be better low-level batteries for that included in Django, like a base view to do TOTP and web author authentication, um, and then have me bring my own templates, like I bring my own login template, because it should look like the rest of my application.

Yeah, right.

Yeah.

And and those kind of low-level views, they're the hard things that you have to get right.

And then, and then but then the the templates, you know, there's no reason for us to have an opinion on that.

No, that's super.

I wanted to we want to go on to your your work and the all the there, but I wanted to talk about you organizing DjangoCon Europe and how you how you know how how you did that and how you found that, and you know, um how you see DjangoCon Europe going forward.

Yeah, yeah, yeah.

No, we it

And we uh yeah, we we put our hands up and submitted a proposal to do it in my hometown of Heidelberg, um here in Germany, which we

Such a lovely town, such a lovely venue.

If you ever got the energy to organise it there again, I'd definitely come back.

I love the Philosopher's Walk, the other side of the river.

Um, and I think Europe has so many cities that fit the criteria that we don't need to repeat them yet.

But I don't I don't think we need to repeat cities for Jenger Khan Europe yet.

Um, but I think the the perfect location for Jenger is uh like um it needs to be big enough to host 400, 500 people, have the hotel rooms and infrastructure and uh travel connections, everything, but it needs to be small enough to be walkable, to meet people again in the city after the conference.

Um I like the feeling of of going through a small uh town, um going out to dinner with some folks uh to a restaurant, then leaving the restaurant again, going to another place and again meeting Django people.

That doesn't work like if we were doing it in in London or something like that.

It's just at some point the city is too big, it doesn't work.

Um it doesn't work in the way, but but I think finger cut in Europe works best.

Um yeah, I'm

How was the experience of organizing the conference?

It was it was hard um because in the beginning you start trying to build a group of volunteers um that work on it, but few people can properly estimate the amount of work this takes beforehand.

Um you get a lot of people signing up for it and then not following through.

And in the end, one of the sad parts of DjangoCon Europe is that in the end, in most years, um it came down to one, two, three people carrying the the bulk of the load, and that's it's not a full-time job, it but it comes close in the in in some of the months uh ahead of it.

And um, yeah, that's a lot to take on.

And so six years later, like you've obviously thought about this, and like do you have ideas for the sustainability of Django?

We've been you know, we've been lucky that we've carried on and the the Porto team were great who kept it going over the um pandemic period.

And but it seems like every year there's the same, you know, you said in 2017 there the problem was no one had stood for.

Well, it sort of feels like that's a familiar story.

Is how how do we how do we make it sustainable?

Don't think it's something I can uh go into too much detail about um at the moment.

Um, but it it continues to be a problem, and it's a very hard problem to solve because we want the conference to travel around Europe and we want new people to come in and do something creative with that, change, change it a little bit, and make it better, hopefully.

Um and for example, a large part of doing it for the first time that makes it hard is setting up the legal structure to host it.

You need an association or a company, somebody needs to be responsible.

And I don't know if the if it ever goes wrong, someone needs to go bankrupt, probably.

So usually that shouldn't be a person, it has been a person before, but it should be a company or an association that you can have dedicated for this.

And depending on the country, this is quite a lot of effort to set up, especially if you haven't done it before.

It takes time, it takes effort, and it's one of the things that makes it hard to carry um a lot of these, like it's not an interesting part of hosting the conference, like assembling the program, doing social events.

That is the fun part.

But setting up a company or an association is not the fun part of organizing a conference, but it's it's one that we need to do every year because it's so complicated for say a Spanish company to host an event in Sweden, um, legally, that we we we basically need a new one every year because we want to switch countries.

So that's a problem that in the US with Jenga Ken US and DEFNA, it's the same legal association over and over again.

Um and it would be amazing to yeah make this easier and have more continuity, continuity with the people, with the money, with the processes.

But even though the European Union, uh even though it would be even harder without the European Union, it's still pretty hard.

Is there not does the EU not somehow, does the single market somehow not somehow make that cross-border thing work?

Um EuroPython is doing it, for example.

And they are currently putting on their event in the Czech Republic.

However, um that also means because they're they're physically holding the event in the Czech Republic, uh, the Czech Republic um has a right to the tax income.

And so the Swedish Europe Python society needs to register as a tax citizen in the Czech Republic, not so different from setting up a new company.

And Europe Python has, I think, about 10 times the budget of DjangoCon Europe.

At 10 times the budget, it becomes more feasible to just hire lawyers and accountants to deal with it, and it's still a lot of work for them.

Um, it's not just hiring anyone, they still struggle with it a lot.

So um and uh doing that at a much smaller budget makes the event more expensive for everyone to attend.

Right, okay.

Um it at least a thousand, I believe.

But uh yeah, they have uh uh in any case they have a larger budget for it.

And um yeah, it's too bad we haven't figured out a solution because it's so much work just to do the fun stuff, let alone all the the money side.

And I recall, yeah, a lot of conversations around the DSF trying to the US DSF trying to set up a European bank account and all these kind of things that maybe we just need to ask EuroPython more forcefully or something.

It's not a new conversation, and I'm hopeful we will find a solution someday, and I'm thinking about it uh um regularly, but I have not found

one of y'all.

There's the the um Django uh the Eurocon uh DjangoCon Europe working group and that you're involved with, right, to to give people more support.

Um, something that has been going on before as well, but now in a little bit more formalized way.

But if you say you want to do it for 2027, uh for example, um, you can ask the support group any questions you might have about it, or um if you can have access to past budgets or whatever, um, but we can share with you um to give you a little bit of a head start.

And uh we also try to, well, the support group is quite new and um the current organizers are quite experienced, so it's not happening that much, but the ideas also to check in with the current organizers now and then and see if they need actively check in and see if they need any help um or any further information.

If if people have got like a half-inkling, they think, well, maybe I could do a a DjangoCon during one year.

They should reach out, right?

They should reach out either via email to the support group or um add a Django Con or another event to someone who's done it before in person.

That's sometimes the more if the more effective way to to get the information that you won't find in writing, um, and to get a little bit of feeling about how it works and how to

And I just saw so we're recording on November 12th.

I know this episode will come out a little bit later, but just yesterday, all the details around um next year's DjangoCon in Dublin came out, including a date, which is April 23rd to 27th.

So I'm very excited about having a date.

And Dublin's a great place.

So when we signed up in 2017 for 2018, we had I think 10 months left to plan it, which is not a lot of time to find a venue and to get everything set up.

Um now the Django Software Foundation has already requested proposals for 2026.

This year, the deadline has already closed.

And um, so there is the attempt to make the planning period longer, and that will also make it less stressful, hopefully.

And I'm I'm very the the quality of the candidates was amazing, and there's a lot of energy out there, so I know that having new and energetic and uh international uh board members will help with all this, so that's that's definitely something to look forward to.

I also want to say, like we we talk about how much work it is to organize these things, but you you get so much back, like just like anything, when you put yourself out there, right?

I'm sure just for you organizing the event, you meet and you know work in a volunteer capacity with people you wouldn't know before, and you know, I feel like you get a lot back from any any like we like we do with this podcast, you know, we don't monetize it at all, but I feel like just for myself, my happiness with Django and get you know reaching out to people like yourself.

Uh so same thing with organizing a conference, the best way to meet people and get involved is to get involved.

Yeah, absolutely.

You have this company, uh Rami.io, and a couple products.

Um what is the full suite of um yeah, well, sorry, I you know I I almost don't know where to start.

I mean, because you have a number of employees and products.

I was saying Raphael, tell us about your work because I I I I know you do some stuff and it's all in this area over here, but I'm it's quite there's a lot going on.

How how how many employees do you do you work with now?

Because I heard you mentioned 13, I think two years ago.

You're the main ringleader?

Yeah.

That's quite a lot to do.

And basically our our main product is Pre-Tix, which is a ticketing solution for any place where you pay to get in, which involves the entire event industry as well as uh parts of the leisure industry, such as museums or swimming pools, or yeah, whatever you wherever you pay to get in is our target group, and we try to provide a end-to-end solution with online sales and ticket access

control and uh cash registers and so on.

And the smaller product that we have that started in the pandemic is Venuless, which is a live event platform, um, kind of combines live streaming and video calling into one tool and a few other things, um, to hold conferences online, which yeah, is something that we that we come up with to um to help our clients mostly 2020 to 2022 do their conferences at all.

And now we still have um a number of clients that use it to do hybrid or still fully remote conferences.

Is that is that holding up?

So I I mean during the during the pandemic, obviously it was all online only, and then the first year back there was a you know very much a uh a two-stream type thing, online tickets as well.

But how how's the hybrid thing holding up?

Because it seemed like it was a it was a growth thing, it was a new feature that we should keep.

So um the larger part of the event industry has fully abandoned and went back to in-person only.

In person only.

Like streaming to YouTube is simple, but probably making a connecting experience out of a hybrid event is really, really hard.

It takes a lot more work and cost than doing either one.

We have a client who runs a lot of conferences every year, and they decided okay, we're gonna do half of it virtual and half of it in person, but we're not gonna touch hybrid, it's too hard, it's too too complex.

We we also they also want to be able to select different kinds of content for the different types of audiences and so on.

So we still have hybrid or we have hybrid conferences on the platform, but um compared to uh total amounts of conferences that we work with or that we know, um, it's a very small number.

Okay, interesting.

Maybe one of the you know, the high-level question is it this is open source software, and yet you support a team of 21.

How do you and I know you've given a talk that we're gonna link to at um FOSSBAC on building a business around open source applications, but what is the what is the short version of how you manage that, right?

Because that seems like the dream for a lot of people.

So um our main revenue stream is uh providing the solution in software as a service.

We also do all of the other kinds that you can uh monetize open source software.

We have proprietary add-ons that you can purchase from us that are not open source.

We um we sell support services, but really 90% of our revenue comes from uh software as a service um because people just don't want to deal with uh running the software themselves.

And it makes sense, it's um kind of mission critical for a lot of them.

Like if you um if you're an event business, selling tickets is your revenue stream, and on the day of the event, scanning the tickets and printing badges is um very important part of your of your user journey, and you don't want to deal with the silver outage yourself in that situation.

Yeah, right.

What I guess the question is when did you

Um otherwise we would have hosted our birthday party at a wrong date.

Um so what's the story of that, right?

I mean, because it's it was you, right?

Like you you had this inkling and you put a lot of work into this into this product, you know, not knowing that you'd be where you are now.

Um I started to get involved with a local um conference.

It's called MRM C D.

It's a low from the local, let's say, privacy and open source community.

And um somehow I raised my hand at the question of who who's gonna deal with ticketing and money, and um sorry I I fell into into that hole, and uh there is not a lot of open source software to deal with such things out there.

Um, and we tried one or two and it was all bad, and so I decided I'm gonna start my own.

And I consciously, because in that community, there's a lot of homegrown software that someone maintains for two or three years and then it's no longer around, and nobody cares about the software anymore.

So I it was a conscious decision to try to do it in a way that allows me to make it sustainable.

Um, it was never the plan to build a company with 20 employees out of, um, but it was the plan to somehow monetize it to keep it alive.

Like you think, oh, you know, I could get this build up quite quickly, but then you realize, oh, but it sends emails and it's got this and it's got that.

And how how long did it take before you it started to mature?

So you start to think, oh, actually, it's it, you know, obviously there's always more you can build noise things you can make better.

We're not done yet, right?

Um, but but how long so uh first commit, I think end of 2014.

Um I was running my own conference, so the one that triggered the creation on it June 2015.

So eight months later, and I think the first event that was not run by me with a lot of patching on the job was a year later, early 2016, when we launched the

or I

And not only are they expensive, but they're also they don't work all the time.

Because so I know that you know when you have challenges of these big spikes of traffic, right?

Where nothing, nothing, nothing.

Um how how did you originally tackle that?

And I'm sure that's a huge issue now, right?

When you have very irregular streams of of usage.

So that's one of the hard engineering challenges in in ticketing, and it's not one we solved either.

Um, I believe it would be quite feasible to build the ticketing system that scales almost infinitely if you would constrain yourself to a very small feature set and a very specific use case.

But that's not what we do.

We have a very extensive product with a lot of complexity.

Um think about, and and a lot of the problem is that you don't only have these large load spikes, but you also have to deal with scarcity all the time.

So, for example, if you have a theater ticketing where you can choose your seat, there is only one seed five in the first row.

I can't go infinitely concurrent and run the system on millions of servers that are independent on each other because I can only sell this seed once.

Um, so I need to actively prevent concurrency in a way.

So um yeah.

So do you so okay, so do you take a kind of command query type approach where you like you you you request the request made to the Django request isn't a buy ticket, it's a request to buy a ticket and wait for a response.

So all ticket buying um requests go through a salary queue uh in pretext.

So it's just it's it's a task that can be retried and uh can wait on a queue.

And we use um uh we use PostgreSQL's advisory locks now um to have a very lightweight way of saying okay, place a lock on this seat, on that quota, on this voucher, um, on all the kinds of things we want.

So um we can but still this locking limits us in how many tickets we can we can sell um at a time.

Um because in principle we can only sell one at a time um of the same type if we need to take care of of such conditions.

So we're limited at around three thousand sales per minute or something like that for a given event, because that's just how fast we can we can get it right now.

Um and uh the industry startup solution that's not very different to what Ticketmaster and others are doing is like if you if you go beyond that, you have kind of virtual waiting room where you say, Okay, this website is not too much load, please stand in line and we'll let you in soon.

So I mean I've seen you give a couple of good talks at DjangoCon's.

I mean, not because good talks, great talks.

Uh um one on scaling channels in Edinburgh, which I just thought was the best channels talk I've ever seen.

So I do recommend that.

But uh the the the other one this year was about deep debugging um slow um slow database requests in production because that's the key, right?

It all all working fine locally, but then but then not when you get it out there live.

Yeah, absolutely.

I think we we found a PostgreSQL back up, but I'm not not too sure yet.

Are you using Docker or how do you you know all work on the same thing?

So for pretext it's really um really quite simple.

Um for venue less, because it's a few more components, we have a Docker composed setup.

Um but uh yeah, my my local pretext development is just a virtual end with a package installed.

Do you find do you find there's these cases where running locally doesn't

So having a little bit of chaos in the development around as well might even be helpful in ironing out those edge cases.

We actually like uh I I develop most of the time I develop um on SQLite and we run on PostgreSQL and production.

I love that.

Wow.

Is that is that how you're doing it?

How are you working on the same stuff in the team?

Um.

How do you do it?

Um but a lot of it is just run it locally and and click through the different cases.

No, you said API.

Are you using and you mentioned view earlier?

Are you using uh a view front end and API backend?

Is it all service rendered?

Uh we use view, so we we have an extensive API um that we use both internally and externally, um, but we uh and we have a few parts of the user interface that are a view based.

For example, um the the seating choice element or some other stuff.

We have some some more complex user interface parts where we where we um use Vue and um to to build a more interactive um component, but uh the major part is plain how Django was invented.

Yes, yeah.

Um uh yeah, it's it's one of the the challenges now after 10 years, um some things are not that easy to change.

I was talking to Carlton earlier.

I'm finally updating my I have a book on uh Django for APIs with Django Rest framework, and Django Rest framework's in an odd place in that it's feature complete.

Um and yet, so it doesn't it's not the shiny object, and yet it's used everywhere.

And actually, Carlton, that's that's to you.

You helped with the 315 rollout, right?

Like what is are you still officially a maintainer of Django Rest Framework?

I don't, you know, if I'm pinged on an issue, I'll I'll um you know I'll comment or join in.

But it's the thing is it all works, right?

You go, okay, so let's look at go in the REST framework folder and we look in the generics.

Yep, they're all 100% battle tested and look in the views, but they're all battle tested, look in the serializers, they're all battle tested.

And the trick, the bit that people want changes for, they want tweaks for is in the serializers because there's a weird behavior.

If you've got a null field here combined with that, does it serialize exactly how you would want?

Maybe it doesn't, but at this stage in REST Framework life, that bug is almost bug.

If it's a bug, it's it's it's almost unfixable because people are relying on the current behavior.

And so you can't suddenly make it return true rather than null or none in that case, because that would break people's APIs in production.

And so those small, those really small kind of just character bugs, they can't they they almost can't be addressed now.

Um so what's the solution?

I don't know.

I don't know.

Um but REST Framework is as reliable as it's been for the last decade, it's just not going anywhere forwards.

Like that's the it's it there aren't going to be massive changes to it now, it's all.

Which is good for your book though, Will, right?

Because you know, you can update it more easily.

Like why would I want a new major version that breaks a lot of stuff if I don't have a lot of requirements that it doesn't fulfill?

And there aren't any.

I'm sure you've had discussions around this.

Where where do you you and your team sit on switching some of the view things over to HTMX?

Um we haven't really tested it in the project, and I don't have a strongly formed opinion uh on it yet.

I mean it does and and you're in a different situation with a very tested product team.

It does seem the advantage is if you're a one or two person team, you can get a lot of the reactive behavior without having to split things up and do front-end, back end.

Um it's interesting that there's now I there's there was a post, right?

There was a post about too much HTMX, I think, that uh that got a bunch of traffic, you know, because it's not obviously it's not perfect, right?

So people are f finding the the box in which it seems to work best, right?

Where solo developer, great, but then there are the of course these limitations, just like there is with any tool.

And and there is like um I I studied physics at university, and uh physics is a lot uh a lot about of laws, about uh conservation, conservation of energy, conservation of momentum, but there's also conservation of complexity.

And if you're trying to build a complex thing, you're gonna have the complexity on some layer, and you can like in different situations, it can be a little bit better of having more on a different layer, but it's not going anywhere.

But you said before about Django fitting your the your the the way you think and view fitting the way you think that that that's kind of the way I'd describe HTMX for me.

It's like the reason why I like it is because it fits the way I think and it fits the Django way I think.

And so it's you're exactly right, it's not about reducing complexity, it's just about going along with the way your mind works or not, you know.

If you do go along with the way your mind works, it's for some sense easier for a while.

So managing a team of 21 people and a very popular product, I guess was that something you expected when you were starting out as a programmer?

Were you thinking I want you wanted to be a business a business owner?

No.

No, no, no, no, no.

Because sometimes people don't want to do that.

Um so I approximately everything, six months I'm learning something entirely new that I've never done before, and I need to do it now, and I need to understand it.

And um that is very exciting to me.

Um so far, it's it's a lot of fun.

Of course, the the things that I do day by day have changed a lot.

Um, I still spend a lot of time coding, but I also spend a lot of time in meetings um internally with clients, with suppliers, with partners, and so

Do you have to like

insist on it?

It's not so hard to find time for fixing bugs and other smallish urgent things because they appear to be urgent and time uh appears.

Um, but it's it becomes quite hard to find time to work on larger features or larger projects.

Luckily, I now have uh other very capable team members who do that as well.

Um, but I still enjoy it and I'm also I believe I'm still useful when doing it.

On the running a business front, it must be well, is it deeply rewarding to think that you you know you're giving solid employment to 20 people, 21 people that like and you know that's that's quite a a nice thing to put out into the world now.

It's uh also a lot of work and also some challenges and uh um not without like yeah, but yeah, it's it's a nice result to get from from just starting an open source.

How do you cut how do you sort of try to manage that long-term tendency to, you know, because if you know if you don't manage it, it you grind to a halt eventually.

How do you manage to keep momentum?

However, that means like we're not gonna bother with Django releases that are not an LTS, it's just too much work and not worth it.

So we're we're upgrading 3.2 or 14.2, and we will next be upgrading 5.2.

Um, we have the additional challenge that um pretex has this plug-in architecture where you can install additional functionality as a plugin.

So when we do a major upgrade, like a Django upgrade, we need to do that in around 120 repositories at the same time.

Um which is trivial for some changes, like replacing you get text with gut text in the imports, and absolutely not trivial with a few other changes like delete form, a delete view suddenly working differently.

Um so

I thought, yeah, that's fine.

That's fine.

No one's gonna be able to do that.

We, for example, um our our HTML on CSS is based on Bootstrap 3.

And I'm not sure we will we will never, no, I'm pretty sure we will never upgrade from Bootstrap 3.

We will migrate to something custom built but tries to give a backwards compatible journey because the effort of migrating I don't know 5000 templates to bootstrap five just to do that again for bootstrap sake, it's it's not gonna work.

Um so with a few things, um yeah, we'll need to to find our own solutions for that.

So my last big question is I want to ask about Stripe and billing, because I think you've been using Stripe from the beginning, at least since at least since 2016, maybe earlier.

Um, and it's been the first that we that we've integrated, or together with PayPal, I believe.

So I guess the question is how how do you manage that, right?

Because dealing with money is important to a business and you don't want to get it wrong.

And yet it seems like so much to juggle.

Because what's really amazing is how Stripe deals with API versioning, I believe.

I think they have they have found the the sweet spot for how to version an API um when they do um breaking changes.

Um because yeah, like basically you can you can set uh an a request header that specifies the API version you are aware of, and it will emulate the behavior of the past API as long as it's absolutely possible.

So um Stripe is changing a lot, but actually we there have been a few larger changes over the 10 years, but most of the time the changes are don't require a lot of action on our end.

We also only use the payments part of Stripe, we don't use the billing or invoices products.

Um because these are all things that we have in our product as well.

We have our own invoicing module and so on.

Um I'm not quite sure anymore what the question was.

Um but um uh yeah, so most of the payment providers are not that hard to maintain because they don't change that much, but they need to work well, of course.

Um, because yeah, people are are interested in getting their payment.

I don't know why.

Um so to store money, integer fields, decimal fields, positive big integer field, how do you like to go?

Um decimal like SQLite doesn't have a decimal field, it only stores it, I believe, as a string, and then there's weird things with it when you try to do uh computation on it.

But in PostgreSQL, I believe decimal field is a good fit, except that we will not be able to properly invoice um in about seven of the currencies in the world because there we have money stored decimal field in with two decimal places, and there are I think seven currencies in the robot have three decimal places, um uh mostly in the Arabic countries.

And um, I'm not sure if we're ever going to be able to properly migrate those fields.

Um, we had the problem already, like we had a 10 digits of M2 decimal ticket statutes.

We already needed to migrate to larger decimal fields, um, because I don't remember which uh which currency it was, some currency where you have these very large amounts where you like would buy conference tickets for a few million.

Um but in the end, these differences are why I feel or why I'm quite happy with using decimal field, because if you're storing it in so floating point is wrong, we can get that out of the way.

If you're storing money and floating as floating point numbers is wrong, storing it as integers brings you to the same problem because American projects is usually integer of cents, but now you look at the Danish krona, which doesn't have a decimal part of the Japanese yen, or or you look at the Jordanian dinar, which is three decimal places, and now either you would need to globally multiply by a thousand, even though that gives you integer representations

of things that don't exist in US dollar, or you would need to have different multiplicators for different currencies, which sounds even worse.

Um, so the the complexity there with the internationalization is the same whether you're starting it in decimal fields or integers.

Um there are a few advantages or disadvantages to either one.

Yes, yeah, and there are some currencies, like I think the Danish krona technically has a decimal point with two places behind it, but it hasn't been used in decades.

So, and they don't publish whether they consider if the currency with decimal places or not.

So depending on the payment provider, you might need to multiply it with a hundred or not.

So um, whatever you do, document very clearly how you want other currencies to be handled.

It sounds like, oh, money is money, but just like time is not time zones are not time zones, they're sound quite complex.

But technically that's wrong.

We should be storing local time on a place because if the time chart time zone legislation changes before the because we're dealing with events in the future, like um DjangoCon 2025 is gonna be in Dublin, Ireland could abolish daylight saving time before it happens, and then all the timestamps in our database would be wrong, and we would need to like manually fix them for all the events that are taking place in Ireland.

Um so far that hasn't happened, but yeah, there's so much hidden complexity here.

The other day as well, your um I-18N field came came up, which is a solution for storing multiple languages of um multiple text translations in a single field, right?

One of them is the how we store translatable strings.

So if you're hosting a multilingual event, you can also give the event a name in each language and set up email templates in every language.

We have a custom field type that allows doing so.

That is uh Django I18N field.

Um there's also Django scopes, which is our way of separating multiple tenants in the same um in the same Django project in the same database.

Um I given a talk about that at DjangoCon Europe 2019 in Copenhagen, I believe, or no, 2020 online.

Um I believe it's it's on YouTube.

And we also like we have our custom package, it's called Django Hierarchy, but it's our settings store.

What like we have over a thousand settings that you can use to configure your ticket store shop, and we don't want to do a model migration every uh every time we add one, and it's also like with the plugins and so on.

So we have this in database key value store that has a hierarchical hierarchical dependency because you can set things on the tenant level, on the event level, and even on the global level, and it kind of trickles down.

You can um it you can uh inherit the settings from an upper layer.

So there's a number of of small Django packages that we maintain because yeah, it's useful for us and maybe for for someone else as well.

And so, you know, you might um um the the in the uh IT and M field, you might not want to store the the repeated blobs in the same field, but well, actually that works for you, and it's simpler for fetching, it's simpler for various other.

Is there anything you know we haven't asked you or that you wanted to bring attention to?

But prepare for the question.

Um I mean normally we would ask something around what would you change in Django, but I think Carlton led off with that early on.

So you know the the magic wand, right?

What would you what would you change?

Is there anything else that comes to mind in core Django that you'd like to just make so?

Um in core Django, yeah, I think what we talked about before, um I think we need built-in batteries for two-factor authentication.

It shouldn't be something you you add extra.

Not so sure about single sign on open ID connect someone's own because that's very complex and that's very um that's also changing landscape, but uh I think we we really need um like if I if I install Django and set up a Django admin two-factor authentication should be the default, um should be fully fully integrated, yeah.

All right.

Well, I I feel like we could ask you questions for another couple hours, but that's a really it's a really impressive thing that you've built, I would say, you know, open source project, organizer, team of 21.

And maybe most impressive is finding the time to still code yourself.

I think maybe that's part of why you you seem to enjoy it, right?

Sometimes people have monetary success, but if they get moved away from the engineering or core work that they really enjoy, I've seen people who don't really enjoy the success of their company is when they're in meetings all day long.

And yeah,

yeah, yeah.

Yeah.

So far, it's for me.

Well, we'll have links to everything, especially your talks, which uh your talks are fantastic on all these topics we've mentioned.

And hopefully I'll get to see you in in uh DjangoCon Europe next year.

Are you are you planning to attend in Dublin?

Um the year after, definitely.

Okay.

Well it's well

fingers crossed for that.

So we are at DjangoChat.com and we'll see everyone next time.

Bye bye.