As a beginner I don't like how Django uses strings for everything. installed apps etc. otherwise it is very good for me
Django 4.0 release candidate 1 released
91–100 of 126 posts
Re: Django 4.0 release candidate 1 released
#92As someone who mostly has worked with minimal web frameworks (no ORM, admin site, etc), Django seems appealing. My only concern is that the ORM seems to be pretty coupled with different pieces of the framework, and I'd prefer to write SQL and wrapper it on a function on the model. Is my observation on the coupling off? Does anyone here have a good bit of experience using the raw SQL option for queries most of the tim…
I took that approach on my latest Flask project and it’s gone quite swimmingly. The problem I ran into was that a lot of the ecosystem, and therefore documentation, blog posts, helper libraries, etc., are all written under the assumption that you’re using an ORM. It took a while to figure out how to work around that, but once I did, I was home clear. I also used a helper library to automatically map namespaced .sql f…
I remember seeing aiosql a bit back and being impressed. I'll give that a shot.
Right now I have a Flask application with separate dataclass models where I write a function like `get_by_id` and then then query the DB and get a dict back (using psycopg2 with DictRow returns) and then I can pass that directly to the dataclass constructor with `User(**row)`. Very flexible and working really well so far. Not sure how this scales though, but I'm happy with it at the moment.
Re: Django 4.0 release candidate 1 released
#93Earlier quoted context omitted.
> For instance, in my experience the admin site is best thought of as glorified DB UI. If you need something more than what it can offer out of the box, you should switch to coding it yourself, or live with a quick hack. Agreed. My biggest Django headaches ultimately resulted from me trying to make the admin console do more than it's meant to do.
There are certainly limitations to the admin console/module, but it is still rather amazing. The amount of stuff that it will allow you to do is pretty impressive. Sure, you easily get into a situation where you're out of luck using the admin module, but there are also entire classes of problems that can be solved using only the build in admin functionality.
Yeah, the trick I've learned is to design my models in a way that I know will work well in the admin. It's a little backwards, but it means I can keep using the admin.
Re: Django 4.0 release candidate 1 released
#94Earlier quoted context omitted.
For most frameworks,etc... I find that things get harder as the project grows in size and more code is added. Strangely, I find the complete opposite with Django. I find that adding new features and apps in my day job is easy and I barely even think that I'm using Django, but trying to start a hobby project with it is initially a bit of a nightmare That being said, weighing up the good with the bad, its still my favo…
Not my experience. I inherited two Django projects, and adding features is quite cumbersome. I had to add one boolean switch which Django only has to pass from an Angular form to a template, and I had to alter the code in 7 places (one of which is the Angular code). It's just not suitable for REST-like access from a front-end, nor for data that's not a tree, nor for heavy processing: I ended up pulling all kinds of t…
> It's just not suitable for REST-like access from a front-end, nor for data that's not a tree, nor for heavy processing
It obviously depends very much on your opinion on what defines "heavy processing", but we do all those things without too much trouble. Obviously we may, and probably do, do things differently to you (we dont use Angular for example, though that seems like it wouldnt be too big a factor) so YMMV, but yeh, for us its been pretty solid
Re: Django 4.0 release candidate 1 released
#95Here’s my post summarizing new testing features in Django 4.0: https://adamj.eu/tech/2021/09/28/new-testing-features-in-dja...
Re: Django 4.0 release candidate 1 released
#96Earlier quoted context omitted.
You could use Django just for the backend and have your frontend code be written in React+Typescript, no?
But that means throwing out a large part of Django and writing lots of "interconnect" code. At that point I think it's better to choose a different backend, one that will generate typed Typescript client code (or use Typescript on the server and some clever metaprogramming).
Doesn’t Django Rest Framework solve most of the issues you raise?
Re: Django 4.0 release candidate 1 released
#97Earlier quoted context omitted.
But that means throwing out a large part of Django and writing lots of "interconnect" code. At that point I think it's better to choose a different backend, one that will generate typed Typescript client code (or use Typescript on the server and some clever metaprogramming).
You can also just generate an Open API spec and use something like openapi-generators to produce typed client code for data fetching ( https://github.com/OpenAPITools/openapi-generator )
This has been such a life saver for me these past couple of months
Re: Django 4.0 release candidate 1 released
#98Earlier quoted context omitted.
This is a question that's largely impossible to answer, but there's a performance vs developer (or business) time calculation to be made. More aptly, if one can throw another physical server at it, is it worth fixing the underlying performance issue? Sometimes the answer is yes. If you're at a place with even a thousand physical servers running your process and you can save 2% overall performance with a rewrite, that…
That remind me of a meeting a few days ago where we were discussing if we should add another server or spend a bit more time developing something. After some time, I asked about the server cost, and it ended up being something like 100€ a month more to not have to worry about performance for the next year. In that case the decision was easy enough, but maybe some organisations have fixed server budgets and developers…
Yes, 100% it depends on many factors. 100€ euro a month = 1200€ euro a year... Now if a developer can address that in 15 minutes- wonderful, but if it takes her a week... have you won very much, because it's not just the time calculation but it's the other would this same developer could have been doing in this same time.
Moreover, you're right to calculate this per year because maybe you'll throw this entire code away in a year, or maybe it will become the key code for something else, and you'll need to optimize it anyway.
Even sometimes having a meeting to discuss the performance is not cost effective. Six employees around a table for an hour discussing whether or not to improve the performance of 1200€ a year is not cost efficient.
But then again, sometimes it really is. In one environment we were asked to use some tooling on top of the OS that reduced performance by 5%. It was some management toy that would have made the Linux boxes do the same thing as the Windows boxes, but there was a performance penalty of 5%...
5% of 1000 machines is 50 machines, or just over one rack of servers, and so we could go back to management and say "The performance penalty of this is over a rack of machines. Are you sure you want this?" and then they can decide if it's worth it or not.
Re: Django 4.0 release candidate 1 released
#99If anyone's looking something close to FastAPI but for Django, checkout django-ninja [1][2]. I recently joined a team that uses it, and it's pretty nice so far.
Re: Django 4.0 release candidate 1 released
#100Earlier quoted context omitted.
Template engines are already configurable and pluggable for quite a while. The "problem" is that most of the third-party apps that want to provide templates end up using the default, so either you have to reimplement those or stick with the default engine.
You can use both the Django Template Engine and other template engines side-by side in the same project. You can then write your custom templates in whatever you want, and have your third-party apps use whatever template engine they want to.
My comment was more in the sense of wanting to extend third-party templates, but yeah, if you don't need to touch them you should be fine as well.