Transcript: E-Commerce - Jacob Rief

Hi, and welcome to another episode of Django Chat. I'm Carlton Gibson, joined as ever by

Will Vincent. How are you doing, Will?

I'm good. Hi, Carlton.

Hello. And this week we've got Jakob Rief with us, who's going to talk to us about all

things Django CMS and Django Shop. Hello, Jakob. How are you doing?

Oh, fine. It's great.

Thanks for coming on the show. Perhaps we can start...

Thanks for having me.

Oh, you're very welcome.

First, we can start by talking about how you got into programming,

how you got into, say, Python, how you got into Django.

That might be always interesting.

Well, when I was 14, my father, he did a lot of physics and programming in Fortran,

and so I somehow got into programming through him.

Then I used BASIC and Pascal and C and C++ and Assembler,

And later on, I required a scripting language to access C code.

That was in 1997.

So it was my first Python experience.

So what version of Python was that?

Later on, that was 1.5.

Okay, cool.

Nice.

And it was very unknown at that time.

I tried with Tickle at that time to have a scripting language to access code written in C++,

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

Later on, then, I went to web programming and web applications, and I retried Python to use DIR.

And that was not so successful because it was at the time when ModPython was available, and that didn't work out very well at that time.

And so I landed in the PHP world.

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 then in 2010, I retried Python, 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.

Right, and Django.

That's an amazing story to start with Python over 20 years ago

and then sort of wait for a framework to catch up with the needs in a way.

Yes, it was 20 years with interruptions.

In between, I used other languages.

I even returned back to C++ and C and even Perl at that time.

But my main focus nowadays is Python.

And I'm currently doing a lot of stuff around Django CMS.

And therefore, of course, everything I do is done in Python.

Right. So can you tell us a little bit about Django CMS there?

Because it's one of the big packages in the ecosystem.

But perhaps some of our listeners don't know what Django CMS is.

Yeah. Actually, I came to Django CMS through Django Shop.

I was asked to build a shop system.

in 2010 and i had to do an addition to a php project and i really didn't like it the way it

was done and 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 since I was working for Django in Django I was

was looking for a shop system shop framework in Django I think that was in 2011 or 2012

something like that and at that time I found out Satchmo which at that time was a shop framework

built on Django and Django shop and Django shop really seemed to be very really simple

but straightforward how it was implemented and so I started to use Django shop and then I saw

that the company behind Django shop was Divio and they had a CMS which was even much more mature

than django shop at that time so i i integrated django cms with django shop for that first project

i i've done with django shop okay and so and so django cms gives you the normal page models and

and things like this you can define an article page or 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 yeah django shop is um the first of all the product models a card where you can put your

models then some card modifiers so that you can change your prices at the at the checkout and

then of course the ordering process and some plugins to to adopt payment service providers

and at the end, a view over all the orders you have done in the shop system you use there.

I'm wondering, so the shopping cart itself, that's from just a UI perspective,

that's a very complicated thing that I think until you build one, you don't see how many variations there are.

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, and I often find anecdotally developers who've 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 where they spend their time and what they find a challenge.

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

Well, the shopping cart, I actually have to say, from the history point of view, I used Django Shop and then Django, the main developer at Divio, who was responsible for Django Shop, left the company.

And I, at that time, have already done two shop systems with Django Shop.

And I was there to do the third one.

And 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 turned over the project to me.

So the project which initially started at Divio, now I'm the core maintainer of Django Shop.

And therefore, I was able to convert that shop system into a shop system how I liked it.

So that was the history.

And since 2014, I'm the core maintainer.

I have other guides which help me to maintain the code and to add some additions.

But principally, I'm saying where we proceed to.

How do you find that, getting contributors?

Do you find it easy to get new people on board and to get code contributions?

No, not at all.

No, not at all.

There is one guy from Paris.

His name is Nicolas, and he helps a lot.

And others are just smaller contributors

which just do small fixes or so, but no big issues.

Because it's a difficult challenge, no,

to maintain a project and keep it alive

for such a long period of time.

Yeah, that's quite challenging, yeah.

For you personally, what would you say

is the the current motivation to keep it going are you still actively building shopping carts

professionally is it just it's an interesting space i mean that's always i'm building shopping

carts professionally and uh i um and i do consulting around django cms and um a lot of

the code I use for Django CMS is also part of

Django Shop. So there is a big synergy

between those two projects. One of the

biggest components of Django Shop is

a Django CMS Cascade, which is a plugin system

for Django CMS. And by

maintaining that, 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 django shop itself without without cascade is not that is not that

big and can you use django shop separately or is it does it have a hard dependency on

django cms there are people which use it separately um i never do it because um i'm just used to it

and I don't want to miss the functionality of Django CMS.

Fine.

So while we're on that topic, I'd wonder,

because a lot of the mindshare now at the moment is with Django Wagtail,

which is perhaps the newer entrant into the CMS space in Django.

And I guess I'd ask, so if I'm 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, would you say?

In my opinion, one of the strongest points is that you can attach your own applications onto pages, onto CMS pages.

Actually, I'm not aware how Wagtail works.

I never used it.

So I don't know if you can also do that in Wagtail.

From my point of view, it's one of the really nice features of Django CMS.

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

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

It uses the same template language.

It uses all the components in Django which are available.

It uses many libraries which we have to use anyway.

For instance, Django Filer or Easy Thumbnails or those libraries which you need to build to organize and to resize pictures.

So it's just all very well integrated.

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

Right, so it's kind of familiar, you would say.

Mm-hmm. Yes.

Another thing I was impressed by looking at Django Shop is the ability to do views either as HTML or as RESTful endpoints.

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

Because that's a really nice feature since most Django sites, you know, I'm thinking of some of the third-party projects I have where I don't have built-in API support and I should.

So how did that come about and what are your thoughts on, I guess, maybe a RESTful approach versus a, you know, static or relatively static HTML page?

Yeah, that was one of the features which have been required in one of the shop systems that we have some more interactive components in, for instance, in the cart and so on.

And therefore, I introduced Django REST framework to Django Shop and I've built everything around Django REST framework.

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

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

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

Something which is seen very often in other shop frameworks.

Right. I think, I mean, Shopify has this built in.

Probably most customers would expect that functionality this day and age.

And actually, that leads into you also maintain or run Django Angular,

a third-party project, which is quite popular as well.

Well, Django Angular was—I created Django Angular together with the shop.

And there, I just wanted to use the form validation in Angular, which was there.

And I searched a way to not have to rewrite the validation 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 integrated into the Django forms.

That's really nice.

yeah yeah yeah no you we should stop there and pause just like 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 web assembly 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

that's that's exactly what i was trying to achieve so that i can declare a form in django

and with that form declaration i can just create the whole client-side validation and even if

even if, for instance, passwords cannot be validated on the client

for obvious reasons.

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 added to the form

so that you just view them

without having to reload the whole page

and just to show them in there.

So it's kind of similar to a REST endpoint,

but I actually don't use REST framework in there

because the REST framework came later

and I did not use that at that time

when I introduced Django Angular with the forms.

Something else which I did,

something else in Django Angular is the,

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

promises which then are concatenated i mean that sounds perfect for you know so many use cases

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 to be able to just

embed that with your form definition well with jango with angular it's actually that um i started

to write that project in 2012, I think.

And at that time, AngularJS was one of the best options

you had at that time.

Then other frameworks emerged, like Angular 2 or React or Vue

or Aurelia and whatever, many other frameworks.

And I believe from the Django world, we should not focus on frameworks,

JavaScript frameworks that much because everybody has a different taste

and everybody wants to use a different framework.

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

The reason is that Web Components, it just can run everywhere

and you don't impose any framework for your users.

So using Web Components will be, in my opinion,

the solution which is framework-less or which is framework-agnostic.

Well, because Web Components are the standard,

so it applies across all the browsers and so on.

I actually am currently doing a small project

where I use Stencil.js.

And Stencil.js is a compiler

which converts TypeScript code

to native JavaScript

where you don't need any other library.

You can just import that into your browser

and you get all your components

as native web components.

On GitHub or something like that?

I can show you, yeah.

Because I think that sounds really interesting. I think, you know, for a lot of people out there building, you know, any kind of web application, that kind of integration with the JavaScript layer is just where all the difficulty lies. Well, not all the difficulty, but a big lot of it.

We have to somehow, we have to, also if you look at the Django admin, which is mainly written using jQuery, that would be a great job to get rid of jQuery and to use native components in there.

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

Yeah, it's a slow job of file-by-file removing that usage A query and bringing it up to the standards these days.

Well, so there's, you have so many open source projects. The last one I wanted to make sure we talked about was the Django WebSocket Redis, because Carlton and I have talked a lot about async and WebSockets on the show. And I guess I'm curious how that come about and what are your thoughts on how that might bleed into the current async capabilities coming into Django 3.0 plus?

Well, that preceded a little bit Andrew Godwin's channels project, and therefore it's somehow popular.

It became somehow popular because it's easier to set up the channels, but it's using a completely different approach.

More or less, you have two entry points into Django.

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

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

So Redis is connecting both the back parts of Django with

with WebSocket Redis so that 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 it was inspired by a talk from Roberto de Lloris.

He gave on Europython in 2013.

And the talk is about how to integrate WebSockets in uWhiskey.

uWhiskey is one of the most popular application runners, which is used by Django.

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

it was more or less it took me two weeks to fulfill and then that was a project later on some

someone migrated that project to python3 and it's still used quite a lot it seems and

some companies they rely on it and uh do those companies support the project i was going to

ask because several times you've mentioned companies how do we go on the funding because

I passed over. I had no time anymore to maintain that project and I passed over the right permissions on GitHub and on PyPI because I could not handle that together with Django Shop and the other projects I've done.

What about on those projects like Django Shop? Is it funded from the project work that you do so you can maintain it part of the project work or are there companies that are depending on it that will directly sponsor it?

The WebSocket project was sponsored later.

I got some money for consulting and for integrating it.

I once ported it to a Heroku installation for one French company.

And I had some other requests for consulting, but nothing really big.

Because this is the trouble, right?

this is this is where it's like all the labor that goes in you mean you know if you if all the

things that we've talked about in the last 20 odd minutes you've done you 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 well with um some

for instance currently i'm working for the university of innsbruck and they are converting

their own content management system to Django CMS.

So I have a steady income from there

and in the evening I can do work on my other projects.

And other libraries, they just have been created

through the need I required for Django Shop

when I wrote shop installations.

And so I separated them always into smaller projects

so that they could be reused by people

which did not require any Django shop functionality.

For instance, the admin sortable tool

was one of those side projects

which is now really, really popular in the Django world.

And I think it's one of my most popular ones from looking at the download

because it just does one thing, and it does that well.

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

So it has a lot of dependencies.

Yeah. I wanted to actually ask you on, so back to Django Shop on payment providers,

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, I mean, I have some thoughts on this, 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?

I've done a few integrations. And after seeing the API from Stripe, I have to say that that's done right. So Stripe is really doing the best job I've ever seen. They have the best API by far and the best documentation.

Well, that's the one I demonstrate in my book, and I agree.

And yet, I think they could do a better job.

I mean, for what they have to, they have Connect and Checkout, and Checkout, at least, they're switching to a new API, which isn't...

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.

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

So in general, I find that all these companies, I mean, you know, hosting companies, Heroku too, which does a good job.

There's a need for tutorials and I'm constantly, 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 can't comment on this.

I just like the API.

And for me, the reference menu is just enough.

So I never looked at any tutorial, Stripe tutorial.

Right, right.

Well, yeah, you probably wouldn't need to.

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

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

And Stripe just gave it to you right away.

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

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

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

Actually, I implemented for a client of mine, a payment service provider from Germany.

And they had a bug in their Python API.

And then I asked how to solve it because I could not find any reasons.

It was a server-side exception and there was no, I didn't get any feedback.

And then I tried out Stripe, and in half a day, everything was implemented.

So it was a really, really short time to implement.

And before, I spent a few days to implement another service payment provider, which just never went into production.

Right. Well, and I think part of this is the power within companies is shifting more and more to developers,

where in the past, and I say this

because I was on the business side of that company Quizlet,

you just wouldn't necessarily let the developers

choose what they wanted to use.

But more and more, I think developers are having a say

in business and technical decisions, which is nice.

My experience with Stripe was exactly this.

We're in a position where there was a committee discussion

going on about payment providers.

And on the dev team, we'd long gone on the Stripe docs,

gone well we can implement that and we put it together in about while they're discussing it

and it was like well you could and we've got it implemented and implemented beats you know

everything else because it was like well this is already working so we can have this or we can have

the other one that you're talking about well and i would say though i'm still um you know all these

credit card companies i mean paypal is amazingly resilient and that many parts of the world still

can use 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 well one of the nice things about stripe is that

you can just use the same form you have you're in control of the form and you just send the

content of the form where you have the credit card information to stripe and then you get

a token from stripe and that token then can be reused in your server-side implementation to

finalize your payment so you your application never sees uh any part of the credit card

and so you don't have to be pci dss compliant which you otherwise would be would have to be if

if you would see the credit card numbers

that's something i've not seen at any other payment service provider they always redirect

you to their site, then the customer has to type in his credit card information, and then

the client is redirected back to the shop.

Yeah, and the debugging experience there is horrendous.

And in that phase, you never know what happens.

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

And with Stripe, you don't have those problems.

Right. Well, I remember Patrick Collison, the CEO, who came to our office 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 same thing we have to do with PayPal and other ones.

I mean, I think what basically Stripe takes on that risk at the cost of usability for

users, and then they have to rely on being much better at their own fraud detection because they

They're assuming that basically client risk, which is how they're able to not force companies to go through those steps themselves, which is a brilliant idea, but also requires that you really are better at your fraud prevention, which in a way, I think the whole...

Sorry, go ahead.

No, just proceed.

Oh, I was just going to say, if you look at the payment space, it's interesting that it really all comes down to that balance between they want to have as many people using their platform as possible, but not trip the fraud wires where they're blocked.

And so it's that tension where in many things in business, you know, you could say we're only going to 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 opening it up to more individuals and more companies and figuring out that acceptable level of fraud.

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

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

That's sort of the secret sauce, because if they don't get that right, they're going to lose money long term.

One of the previous questions where you said that integrating a cart in a shopping framework was one of the most hardest parts.

Others told you, in Django Shop, I grabbed a deer, which was already there, and that was called the card modifiers.

And it's actually a way to program, to change prices on the way you proceed to the checkout.

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

or you have to add a variable amount for shipping costs

depending on the weight you have in the cart and so on.

By using those cart modifiers in Django Shop,

it really becomes easy

and they're all integrated into the 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 cart with updated data

information on the cards total.

So from my point of view,

it's not so difficult to implement the framework.

It might be difficult to implement the card modifiers

because they can get quite complicated.

But that's a part which I leave out intentionally

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 I have not only payment service providers, but also shipping service providers in Django Shop.

Oh, wow.

So you can calculate the weight and just ask the shipping provider 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 a plug-in system or so.

That sounds super powerful.

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

Well, the documentation is, there is some documentation, there is a cookie cutter template, and probably you should use that one and just create a project for yourself.

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

One of the major 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 then you use the Django admin to administer those products.

So what you can do is to have lots of variations built into the products.

And you don't have to rely on attribute value peer tables where you can define properties and so on.

So you use for each property, you create your own row in the table

or your own field in a Django model.

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

And that's, in my point of view, a nice...

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 price fields.

And even the commercial offerings, you have this same thing of this key value.

You have to define this property and the value.

And it's like, well, it's difficult and laborious.

Yeah, and that's a problem you don't have in Django shop.

You only have the fields you need.

And therefore, if you start, I have three different sample models.

There are models which are based on a polymorphic base so that you can do variations of the products.

Or you can, if you just want to sell one single type of product, you don't need a polymorphic base class.

And then you can just proceed from there

and remove fields, add fields, however you want.

And the Django admin will just reflect the fields

and you just reuse the Django admin

to get your backend in Django shop to it.

So it's worth, if I'm integrating with an existing site,

it's worth using the cookie cutter project,

Experimenting with the sample models and then moving into my existing project?

That's my intention, yes.

Okay, super. Brilliant.

And if you have product variations, let's say you have T-shirts and they have different sizes and they have different colors and they have different additions on them.

You implement into the product, you implement the decision if this is a variation of itself or if it's a new product.

Because in the cart, if you add a product twice, in the cart you want to have it shown as two different products or you want to have shown it as just an increase in the quantity of the product.

And by putting that functionality from the shop framework into the product, this question, the product can decide if it's equal or if it's a variation of itself.

Anything else you particularly want to mention or cover, Jakob?

Yeah, there's something else in Django Shop where I also wanted to add some hooks in there.

If you have orders, the order is there.

Then you have to wait until the money is arriving.

Then you have to go to your stock just to pick up the goods.

And then you have to pack the goods and you have to give that to a courier.

And all these steps are, again, not implemented into Django, the Django Shop framework itself.

But you have a kind of order workflow.

We're together with the Finitz Django FSM, which is a Django Finitz state machine.

You can just program if your order reached that state, then those other actions are available.

And so you can reprogram the whole ordering process even with aborts and even if something comes back because somebody sends back a goods they didn't want.

you can all integrate that into into that 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

remains relatively small fine there's a lot to look at we should do an episode on um well

some of these other packages because dango fsm is great um for controlling finite state machines

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 your absolute stalwart of the community it's really

been good chatting to you okay thanks yes thank you okay everyone um you can always find new

episodes at DjangoChat.com and reach out to us at ChatDjango on Twitter. Bye-bye.