Transcript: E-Commerce - Jacob Rief

I'm Carlton Gibson, joined as ever by Will Vincent.

How are you doing, Will?

Hi, Carlton.

And this week we've got Jakob Reef with us who's going to talk to us about all things Django CMS and Django Shop.

Hello, Jakob.

How are you doing?

It's great.

Perhaps we can start

Oh, you're

Perhaps we can start by um talking about how you got into programming, how you got into say Python, how you got into Django.

That might be you know always interesting.

And then I used uh BASIC and uh Pascal and C and C and Assembler.

And um later on um we I I required a scripting language to access uh uh C code that was in 1997, so it was uh my first uh Python experience.

And it was uh really uh it was very unknown at that time.

Um I I tried with uh Tickle at that time to do uh to have a scripting language to access uh um code written in C.

But um a colleague of mine um convinced me to switch to Python, and we never regretted uh that uh decision at that time.

Um later on then I um I went to uh web programming and uh web applications and I uh retried Python to use Dere, and that was not so successful because um it was at the time when modPython was um available and that didn't work out very well at that time, and so I um landed in the PHP world.

Um, of course I wrote a lot of code in PHP and it really got me into web programming, but I never really liked the language.

And uh then in 2010 I retried Python um and I retried it together with Django, and then I immediately fell in love and I just remained there and now since nine years I'm only using Python exclusively.

I used other languages, I even returned back to C and C and uh and even Perl at that time.

Um but um my main focus nowadays is Python.

And um I'm currently doing a lot of stuff around uh Django CMS, and therefore, of course, um uh everything I do is this is uh done in Python.

Right.

Because it's one of the big packages in the ecosystem, but perhaps some of our listeners don't know what Django CMS is or

Um I had to um I was asked to build a shop system um in 20 uh 10 and uh I had to do an addition to a PHP project and I really didn't like it the way it was done.

And um then we I we required something where we needed a lot of kind of variations on the products.

And so since I was looking for uh since I was working for the Django uh in Django, I was looking for a shop system shop framework uh in Django, I think that was in 2011 or 2012, something like that.

And at that time uh I found out uh Sachmo, which at that time was a shop framework built on Django and uh Django Shop.

And Django Shop really seemed to be very really simple um but straightforward how it was implemented.

And so I I started to use Django Shop, and then I saw that the company behind Django Shop was uh DVO, and they had a CMS which was even much more mature than Django Shop at that time.

So I I integrated uh Django CMS with Django Shop for that uh first project I I've done with Django Shop.

You can define an article page or a front or a a news page or whatever type page type, and then Django Shop gives you the kind of product models.

Is that would that be a fair way of describing it?

view over all the orders you you have done in in a sh in the shop system uh you use there.

I'm curious what sort of learnings you've had working, you know, aside from the code, which also becomes complex.

There's a lot of different ways to do a shopping cart.

Um, and I often find anecdotally uh developers who built out an e-commerce site, they always say that figuring out the shopping cart piece more than any other step in the process is is where they spend their time and what they find a challenge.

I wonder if that resonates to with you just on this on Django Shop.

And uh I at that time uh have already done two shop systems with with Django Shop and uh I was there to do the third one and uh then I reused the code base, which at that time was not maintained very well, and I added all my own stuff and then Divio in 2014 they uh turned over the project to me.

So the project which initially started at Divio, now um I'm the core maintainer of Django Shop, and therefore I was able to um convert uh that shop system into a shop system how I like how I liked it.

I um so um that that was the that was the history and since 2014 um I I'm the core maintainer.

I have uh um I have other guides which helped me to to maintain the code and to add some additions, but principally um I'm I'm saying where we where we proceed to.

Um how do you find that getting contributors?

No, not at all.

It's um there is one guy from Paris, his his name is Nicolas, and uh he helps a lot.

And others are just smaller contributors, uh which just do small fixes or or so, but uh no big no big issues.

Are you still actively building shopping carts professionally?

Is it just it's an interesting space?

I mean that's always a c

Um one of the biggest um components of Django Shop is a Django CMS Cascade, which is a plugin system for Django CMS.

And um by maintaining that um that's deployed in many different companies, and uh by maintaining that a lot of um code which is used for Django Shop is is in there actually.

It's uh uh Django Shop itself without without Cascade is not that uh is not that big.

Um I never do it because uh um I'm just used to it and I don't want to um uh I don't want to miss the functionality of Django CMS.

And what so while we're on that topic, I'd wonder because like uh a lot of the mind share now at the moment is with um Django Wagtail, which is the other uh the perhaps a newer entrance into the CMS um space in in Django.

And I guess I'd ask, so if if I'm a a newcomer and I'm looking at the CMS options and I've seen Wagtail and I've seen the buzz around there, what is it about Django CMS that I should look at?

What's good about it?

What are its strong points that would you say?

Uh I actually I'm not aware how Wagtail works.

I uh I never used it, so I don't know if you can if if you can also do that in Wagtail.

Um that's from my point of view, it's uh one of the really nice features of uh of Django CMS.

And another one is that it's it's just a really good citizen in uh the Django world.

It just uses the Django admin for everything to administer uh the pages.

It it uses the same template template language, it uh uses uh all the components in Django which are available.

It has um it uses many libraries which we have to use anyway, for instance uh Django Filer or Easy Thumbnails or those libraries which you need to build to uh organize and to uh resize pictures.

Uh so um it's just all very well integrated.

And uh so Django Shop plays into that same uh ecosystem and it uses same base libraries as Django CMS.

I'm curious, was that there from the beginning?

How was that added?

Um so I'm how did that come about and uh what are your thoughts on I guess maybe a RESTful approach versus a you know static uh or relatively static HTML page?

And therefore, I introduced a Django Rest framework to Django shop and have built everything around Django Rest framework.

So um all uh all the data which is transferred between the server and the client is always or JSON or it's uh HTML rendered as uh template, which is then uh so you can or render it statically or uh just use the JSON.

And uh therefore, um for instance the cart can be just updated on the fly.

If you just change any, if you change uh the items in the cart, it just recomputes everything and it just regenerates uh the whole cart and you don't have to refresh the whole page.

Something which is uh seen very often in other shop frameworks.

I think I mean uh Shopify you know has this built in.

I probably most pe most customers would expect that functionality this day and age.

And actually that leads into you also maintain or run um Django Angular, third-party project, which is quite popular as well.

And um there I I just wanted to use the um form validation in Jang in Angular, which was there, and I searched a way to not have to rewrite the validation um on the client side as on the server side.

And so you can just use a Django model or a Django form and just render it so that the client side validation is um uh is integrated into uh the Django forms.

And so even if you have if

No, you I we should stop there and pause.

Just like ex let's let's make sure we're clear exactly what that means because this is in a way the holy grail.

This is why everyone's talking about you know WebAssembly and all the things, is that we don't want to have to write us, we don't want to have to maintain form validation on the server and then client validation set in separate files.

Now, okay, you're still here, you're still dealing with Python and JavaScript, but what it's giving you is the client side validation just from your form definition.

That's right, yeah.

So that um I can declare a form in Django, and with that form declaration I can just create the whole client-side validation, and even if the client, even if uh, for instance, passwords cannot be uh validated on the client for obvious reasons.

Uh so if you have a validation which has to be performed by the server, use the same channel to inject error messages.

So those errors then are uh then are added to the form so that you just view them uh without having to reload the whole uh page and just to show them in there.

So it's a kind of uh similar to a rest endpoint, but um I actually don't use the rest framework in there uh because it's the rest framework came later and I did not use that at that time when I when I introduced uh the uh introduced uh Django Angular with the with the forms.

Um something else which I did something else in Django Angular is the um if you have a button and you want to have some kind of feedback, you can write your click handler so that you can chain all the things which have to be done.

For instance, if you click a button, you want that you want a tick, and then you want to send your data to the server, and then you want to wait, and then you want to um do something else.

And so that's also part of Django Django Angular, so that that these things can be uh integrated into one line of code with uh with a chain of uh promises which then are concatenated.

Even if you the the thing that comes to mind is that whether or not people are using Angular, but if if you're not fussed about which framework you're using, then you know to be able to just embed that with your form definition.

And uh at that time uh Angular GS was uh the one of the best options you had at that time.

Um then other frameworks emerged like Angular 2 or React or Vue or Aurelia and uh whatever, many many other frameworks.

And I I believe from uh from the Django world, we should not focus on uh frameworks, JavaScript frameworks uh that much because everybody has a different taste and everybody wants to use a different framework.

Therefore, um I'm currently trying to migrate uh this code to Web Components.

Um the reason is that uh Web Components it just can run everywhere and you don't impose any framework um for your user users.

So uh using web components will be, in my opinion, the um the solution which is a framework less or which is a framework agnostic.

You can just uh uh import that into your browser and you get everything, all your components as native web components.

I think you know for a lot of people out there building um you know any kind of web application, that kind of integration with the JavaScript layer is is just where all the difficulty lies.

Well not all the difficulty, but a big lot of it.

You can do uh almost everything you can do with uh with with jQuery nowadays with web components.

Uh the last one I wanted to make sure we talked about was the Django WebSocket Redis.

Um, because Carlton and I have talked a lot about async and WebSockets uh on the show.

And I guess so I'm curious how'd that come about and what are your thoughts on how that might bleed into the current um async capabilities coming into Django 3.0 plus.

Uh more or less it's um you have two entry points into Django.

You have one async entry point, which uh actually is using G Event, which is a kind of um pseudo uh threading model, but you have only one thread and uh and you have patched um all blocking calls are patched so that they uh behave like uh async calls.

And then you have Django, and so uh and in order to so that they can communicate, I use Redis.

So Redis is connecting the both the back parts of Django with uh with WebSocket Redis so that the Redis, the WebSocket part can communicate with the browser, and the Django part can communicate to the WebSocket part through Redis.

That's the whole idea.

And uh it was inspired by a talk from Roberto de Joris.

Um he gave on um EuroPython in 2013.

Um the talk is um about uh how to integrate WebSockets in uh U Whiskey.

Uhisky is one of the most popular uh application runners uh which is used by Django.

And uh then after I've seen that talk, I uh decided to um try to integrate that uh idea he gave on that talk into Django.

It was more or less it took me two weeks to fulfill, and then uh uh that was a project.

Later on, some um uh someone uh migrated that project to Python 3 and uh it's still used quite a lot, it seems, and uh some companies they rely on it.

And uh do

I'm like, I how do we go on the funding?

Are you I you you know are you a is it funded from um the the project work that you do so you you can maintain it part of the project work or are there companies that who that are depending on it that will directly sponsor it?

Some con I I got some money for consulting and for integrating it.

Um I once ported it to a Heroku installation uh for one French company, and I had some other pro some other requests for uh consulting, but uh uh nothing nothing really big.

This is the this is where it's like all the labor that goes in.

You mean you know, if you if all the things that we talked about in the last 20 odd minutes, you've done you've that that represents a massive amount of your of your labor and your life force put out there.

And then the difficulty that we talk about quite regularly on the show is how to make that work sustainable.

Um so I have a steady income from there, and I can um in the evening I can do work on my other project.

And uh other libraries, they just have been created through the need I required for Django Shop when I inst when I wrote uh uh shop installations um and so I separated them always into smaller projects so that they can could be reused by people which did not require any Django shop functionality.

For instance, uh the admin sortable tool uh was one of those side projects which is uh now really popular in the Django world.

Um I think it's one of my most popular ones uh from looking at the download because it just uh it just does one thing and that's uh it it does that well.

And so it's uh usable by many, many uh other projects.

So it has a lot of dependencies.

I wanted to um actually ask you on so back to Django Shop on payment providers, um, if you had any thoughts on as a developer which ones are easier to use.

I mean Stripe, Braintree, PayPal, there's a bunch of others.

I wonder if uh I mean I have some thoughts on this, um, but I'm curious since you have a lot more experience, you know, which ones do it right and where do you see the pain points when integrating with a payment provider?

So Stripe is really doing the best job I've ever seen.

Uh they have the best uh uh API by far and the best documentation.

And yet I think they could do a better job.

I mean they for what they have two, they have connect and checkout, and checkout at least, they're switching to a new API, which isn't um I guess it I guess the main thing I come up against is there's a difference between documentation and tutorials.

And even Stripe, as good as it is, doesn't have that many good tutorials.

Um I mean, in fact, I've they have a section of tutorials and a couple things I've written for different frameworks have been linked there.

Um so uh in general I find that yeah, uh all these companies, I mean, you know, hosting companies, Heroku 2, which does a good job.

There's a a need for tutorials, and I'm constantly uh I have some friends who work at Stripe and I really like Stripe, but I always tell them why don't you just have a demonstration and pick four major frameworks of checkout of Connect that you you know have one engineer spend a day a week to maintain.

I think that would be helpful.

I I just like the API and uh for me the reference menu is just enough.

So uh I I never looked at any tutorial, uh Stripe tutorial.

Well, uh yeah.

You probably wouldn't need to.

Um Yeah, anyways, I agree.

Uh Stripe, it's interesting just as a business, Stripe when they started out because a company I worked at back in 2020, I think, um, Quizlet, we were one of the first companies to use the Stripe, and they were um billing themselves as developer friendly, and now of course they're friendly for everyone.

But um certainly at the time, both on the developer side versus PayPal, and then even on the user side as a business user, um PayPal back then you had to submit a request, wait for an email hours later, and Stripe um you know just gave it to you right away.

Though since we were an early user with Stripe, I would email the team and be like, uh, hey, I I could use a monthly consolidation here for my accountant.

Um so it's been really interesting for me to see Stripe grow over the years.

And um I like the idea of if you focus on developers early on, that pays off down the line.

And then I tried out Stripe and uh in half a day everything uh was implemented, so it was really a really, really short time uh to to implement, and before I spent a few days for it to implement uh another service pro payment provider, which just didn't never went into into production.

Well, and I think part of this is the power within companies is shifting more and more to developers, where in the past, um, and I say this because I was on the business side of of that company Quizlet, you just wouldn't necessarily let the developers choose what they wanted to use.

Um, but more and more I think developers are having a say in business and technical decisions, which is

We're in a position where there was a dis a committee discussion going on about payment providers, and we'd get on the dev team, we'd got long gone on the Stripe docs, gone, well, we can implement that, and we'd put it together in about

Well, and I would say though, I'm still um you know, all these credit card companies.

I mean, PayPal is amazingly resilient in that many parts of the world still can use pipe PayPal and can't use others, so a lot of times you have to add in PayPal, um, even though it's still not as fun to do as Stripe, for example.

You have uh um you're in control of the form, and uh you just send the content of the form where you have the credit card information to Stripe, and then you get uh a token from Stripe, and that token then can be reused in your server-side implementation to uh finalize your uh payment.

So you your application never sees uh any part of the credit card, and so you don't have to be PCI uh DSS compliant, uh which you otherwise would be would have to be if uh if you would see the credit card numbers.

Um that's something I've not seen at any other payment service provider.

They always redirect you to their site, then um the customer has to type in his credit card uh uh uh information, and then uh it's re your reader the client is redirected back to the uh

You might lose the client uh and and you don't see you don't see any uh anything from what what's happening.

And that's in strip with Stripe you don't have those problems.

Well I remember uh Patrick Collison, the CEO who came to our office um mentioning that very thing, and that was the thing I was asking him about, you know, why don't we have to do this the what same thing we have to do with PayPal and other ones?

And I mean I think what basically Stripe takes on that risk at the cost of um usability for users, um, and then they have to rely on being much better at their own fraud detection because they're assuming that basically client risk, which is how they're able to not force companies to be piece uh go through those steps themselves, which is a brilliant idea, but also requires that you really are better at your um fraud prevention.

Which in a way I think the whole Oh, sorry, go ahead.

And so it's that tension where it uh in many things in business, you you know, you could say we're only gonna accept companies and individuals who will never have a false fraud or you know, have a false payment, but really you want to be a little more aggressive on that and find that tipping point where you're you're opening it up to more more individuals and more companies and figuring out that acceptable level of fraud.

So it's an interesting balance, I guess I would say.

Um and I think in I know internally a lot of what Strite prides themselves on, in addition to the documentation and the API, is being better at calculating those things um than you know other companies.

That's sort of the secret sauce.

Because if they don't get that right, they're gonna lose money long term.

Um others told you.

Um in Django Shop, um I grabbed the idea which was already there and that was called the shock uh card modifiers, and it's actually a way to program to change prices on the way you proceed to the checkout.

So um in from my point of view, it's quite even quite easy because because it's uh everything you can uh if you have to add some, for instance, some uh additional costs for your credit card payment, let's say, because you have you have to you have to add a percentage there, uh, or you have to add a fixed amount for shipping costs, or you have to add a variable amount for shipping costs depend

ing on the weight you have in the cart, and so on.

Um by using those card modifiers in Django Shop, it uh really becomes easy and they're all integrated into the uh process every time you do a change, everything is recomputed and then it's sent back through the REST interface, and so you always get an updated card with updated uh information on the cards total.

Um, so in from my point of view, it's um it's not so difficult to implement uh the framework.

It might be difficult to implement the card modifiers because they can get quite complicated.

But that's a part which is uh which I leave out intentionally to sort to the third party providers.

And for instance, the payment service providers they can add their hooks so that the card modifiers can jump into those hooks and then add some additional costs.

For instance, also have not only uh payment service providers but also shipping service providers in Django Shop.

Oh wow.

So you can calculate the weight and just uh ask the shipping provider and and and tell the address, the destination address, and the shipping provider will tell you how much that cost will be.

So all this computation is done not in Django Shop but outside of Django Shop.

Right, with

That sounds super powerful.

So nipping back to Will's point about tutorials, if if I if I wanted to get started with Django Shop, where would I go?

There is a cookie cutter template, and uh probably you should use that one and just create a project for yourself.

It um it adds uh some product models, and uh you usually have to adopt them yourself.

One of the major uh or selling points of Django Shop is that you have your own products.

So you can design your own products according to their physical properties, and uh then you use um the Django admin to administer those products.

So what you can do is to um have uh a lot of variations built into the products, and uh you can uh and you don't have to rely on uh attribute value pair tables where you can define properties and and so on.

So um you use for each property you create your own um row in in the table or your own uh field in the in a Django model.

And so your models they stay slim and they stay readable.

And that's uh in my point of view a nice uh uh if you if you go to the Django admin, then you only get what you have to fill out.

You don't get any fields which are just always empty or never used.

I've seen other shop frameworks they have for instance three different uh price fields.

variations of the products or you can uh just if you have if you just want to sell one single type of product you don't need a polymorphic base class um and then you can just uh proceed from there and uh remove fields add fields uh however you want and uh the Django admin will just reflect uh the fields and you just reuse the Django admin to uh get your backend uh

in Django shop for two to to

additions on them uh you uh you implement into your own into the product you implement the this decision if this is a variation of itself or if it's a new product so uh because in the cart if you if you add a product twice in the cart you want to have it shown or as two different products or you want to have shown it as uh uh just

an increase in the uh quantity of the product and by putting that functionality from the uh shop uh framework into the product uh the qu this this question the product can decide if it's if it's equal or if it's uh a variation of itself

um give that to uh a uh send uh to a uh courier uh courier and uh all these uh steps are not again not implemented into Django the Django shop framework itself but uh you have a kind of order workflow we're together with um a with the finites Django FSM which is a Django uh finite state machine

uh you can just um program if uh your order reached that state then you then those other actions are available and so you can um reprogram the whole ordering process even with uh even with uh aborts and even if uh something comes back because somebody uh sends back a uh a goods they did they didn'

t want you can all integrate that into into that uh order uh framework and um so it's all uh part of the programmer which then uses the Django shop framework and it's not so the framework itself uh remains relatively uh small

ines using the Django RM for persistence it's super okay well I think we're kind of running out of time here now so Jacob thank you for coming on the show and thank you for all the work you do on all these super packages it's you know you're absolute store water of the community it's really been good chatting to you.

Okay thanks

Bye bye