Happy birthday Django! 🎂
rhymes

rhymes @rhymes

About: Such software as dreams are made on. I mostly rant about performance, unnecessary complexity, privacy and data collection.

Joined:
Feb 2, 2017

Happy birthday Django! 🎂

Publish Date: Jul 20 '20
25 23

Django is 15 years old!

Do you have a Django story to share?

Comments 23 total

  • Zubair Mohsin
    Zubair Mohsin Jul 20, 2020

    Just started learning Django.
    Coming from Laravel, only thing I miss is native Jobs/Queues for background processes.

    • rhymes
      rhymesJul 20, 2020

      Just started learning Django.

      Nice!

      Coming from Laravel, only thing I miss is native Jobs/Queues for background processes.

      They are not native indeed but I suggest you look at django-rq which as far as I know are still one of the simplest ways to add a queueing system to a Django application.

      • Zubair Mohsin
        Zubair Mohsin Jul 20, 2020

        Yeah I found it while doing my research. Thanks.

        Is it only possible to enqueue functions? 🤔

        • rhymes
          rhymesJul 20, 2020

          What do you mean?

          • Zubair Mohsin
            Zubair Mohsin Jul 20, 2020

            In Laravel we have Job classes which we dispatch. But in django-rq, it seems like it's only possible with functions.

            • rhymes
              rhymesJul 20, 2020

              If there's one thing I learned by using multiple programming languages in my career is not to try to bend one framework to be similar to another. Just embrace it :-)

              Django is (mostly) function based, I think it's normal that django-rq is as well.

              Are you having specific issues/limitations with using django-rq as is?

              • Zubair Mohsin
                Zubair Mohsin Jul 20, 2020

                No not really. A Django codebase has just been thrown at me 😅
                There's a module which sends number of emails so I thought why not do it in background.
                Right now, I am just trying to figure out things using Laravel knowledge and googling.

    • Maxime Moreau
      Maxime MoreauJul 20, 2020

      You can also take a look at Celery (docs.celeryproject.org/en/stable/), such a great piece of software, and the integration with django is really smooth.

      • Zubair Mohsin
        Zubair Mohsin Jul 20, 2020

        Does it offer a GUI/dashboard where we can see how our jobs are doing like in django-rq??
        Also, do you find it easier to maintain in production?

        • rhymes
          rhymesJul 20, 2020

          Celery has flower.

          I personally think Celery is a bit over-engineered and not all backends are as developed as the others. It's a solid tool though. I used it to process millions of images, Instagram used it for years (they probably still do, but I'm not up to date). The two things are unrelated :D

          I think it's a bit more complicated to maintain in production than RQ because it does so many things and can use different combinations of backends.

          A good way of choosing: do you need RabbitMQ for complicated queue topologies or need to basically build trees of subtasks? If yes, use Celery, otherwise you can stick with RQ which by only supporting Redis makes it all a bit easier.

          As always, it depends on what you need :)

          • Maxime Moreau
            Maxime MoreauJul 20, 2020

            We can use Flower to have nice visualizations (flower.readthedocs.io/en/latest/sc...) or RabbitMQ admin if we're using Rabbit as backend (Redis can also be used).

            Also, do you find it easier to maintain in production?

            I don't know as I don't have any experience with django-rq

  • Max Ong Zong Bao
    Max Ong Zong BaoJul 20, 2020

    For many more years to come!!!

  • Omar
    OmarJul 20, 2020

    I was learning Django for while , but I notice it's not good for beginners who never work on backend before .
    It's very easy to write , but it teach you nothing about how things work.
    I like to hear your oppinion.

    • rhymes
      rhymesJul 20, 2020

      Hi Omar! I understand your point of view. Django is a full framework, which means it tends to hide details about how the underlying request/response cycle works but it's also there in plain sight in a way.

      Basically a HTTP request comes in, goes through a parser (let's ignore it :D), then a bunch of middlewares which are basically classes and functions that take the request and some variables and return a modified request (authentication for example) or an error, it then lands on the URLs modules which we can interpret as a giant dictionary/hash which associates URLs with functions (Django's views), then once the response is ready it goes back to the middlewares so that you can optionally modify the response (gzipping for example) and then finally to the web server and the user's browser.

      Most web frameworks work this way: read the request, do stuff, send a response. The how is how one differs from another.

      Let me know if any of this makes sense or if it's not clear

Add comment