Django is 15 years old!
Simon Willison
@simonw
...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
thanks you make it clear , there is a full blog or book to read more bc I like to deep dive into it more 👍👍.
I mean theory in general behind web.
Hi! @citizen428 suggested How the Web works on MDN.
Julia Evans has a great e-zine explaining HTTP, but it’s a paid resource, but the article about it links to her tweets about the same info. jvns.ca/blog/2019/09/12/new-zine-o...
Also, my co-worker @citizen428 suggested to check out MDN’s How the Web Works.
Just found out we have a podcast episode called "HTTP with Julia Evans":
You can also find the transcript at the source: softwareengineeringdaily.com/2019/...
Hope all of these help!
BTW Julia Evans is really good at explaning things ;-)
There's a talk about HTTP this year in Codeland: "You and Me Learn All About HTTP" by @captainsafia :D
codelandconf.com/#talks
Thanks I book a ticket ,
Also I will buy the book mentioned above.
Thanks for help guys <3
big thanks guys , I will check them <3
For many more years to come!!!
Just started learning Django.
Coming from Laravel, only thing I miss is native Jobs/Queues for background processes.
Nice!
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.
Yeah I found it while doing my research. Thanks.
Is it only possible to enqueue functions? 🤔
What do you mean?
In Laravel we have Job classes which we dispatch. But in django-rq, it seems like it's only possible with functions.
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?
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.
Good luck :)
Thank you 🙏
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.
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?
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 :)
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).
I don't know as I don't have any experience with django-rq