Django Newbie Mistakes • Hacker News Board

Re: Django Newbie Mistakes

#141

Post by Daishiman » Thu, Jun 28, 2018, 7:44 PM UTC

pure_ambition wrote: post #124

k1ns wrote: post #11

Earlier quoted context omitted.

Seconded. It provides an API similar to that of Django's various Form classes. It should feel somewhat familiar, even to newcomers. Their documentation is also great with rich examples and explanations.

It's my understanding that you can use Django's Form classes to replicate any POST/UPDATE/DELETE operations you'd like to use DRF for. I'm not sure what else DRF gets you besides more API-like auth - for example I don't know how well Django would support token-based auth out-of-the-box as compared to DRF.

You get:

* pluggable authentication methods (literally adding JWT, session and cookie tokens takes one line of code * pluggable output serializers (want YAML? Plug in a renderer. XML? Same thing) * pluggable documentation generators * Utility methods for handling RESTful response types

DRF has a staggering amount of features that, if implemented by hand, require a stupid amount of time and a 100% guarantee of subtle bugs.

Re: Django Newbie Mistakes

#142

Post by iliaznk » Thu, Jun 28, 2018, 7:48 PM UTC

mixmastamyk wrote: post #128

Django is great at being "batteries included," with tons of functionality for free. One thing that bugs me about these frameworks however is that you have to wire everything together by hand, sometimes from both sides. Would be great if there were a product built on top that let you drop a model or a view file in a folder and everything would be wired automatically for the default case, customizable later of course.

Django Rest Framework is getting close to that.

Re: Django Newbie Mistakes

#143

Post by ademarre » Thu, Jun 28, 2018, 7:50 PM UTC

JoachimSchipper wrote: post #116

scrollaway wrote: post #108

Earlier quoted context omitted.

Good SPAs are fantastic . It's just a lot of people suck when implementing them. The Serverless documentation, an SPA, blew my mind in terms of how fast and clean it is: https://serverless.com/framework/docs/

Really ? Randomly clicking e.g. Providers > Azure, I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time. (Compare e.g. https://docs.python.org/3/library/weakref.html. ) (Single Page Applications arguably have their place. I'm just really confused why you think this is a particularly good example.)

> "I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time."

You can test the difference yourself by toggling JavaScript in your browser.

Re: Django Newbie Mistakes

#144

Post by ryanisnan » Thu, Jun 28, 2018, 7:51 PM UTC

Daishiman wrote: post #137

ryanisnan wrote: post #80

I've worked with django for a considerable amount of time now (~9 years), and I have found the documentation a joy to work with. The documentation generally covers each piece of functionality, and the source code is rich with documentation. When it comes to django itself, there are nuances, and yep, some of them probably can be smoothed over for developer experience, but developers must have knowledge over their tool…

Usually when people complain about the magic in Django it means that they're trying to work with things that are complete antipatterns. Django usually has one, really good, solid way to do each task and going against the grain is always going to hurt.

To add to this, when you want to go against the grain, you can quite easily, at the core, it's mapping HTTP requests to python functions. Outside of middleware, it's trivial to strip all unnecessary additions.

Re: Django Newbie Mistakes

#145

Post by alexbecker » Thu, Jun 28, 2018, 8:01 PM UTC

acdha wrote: post #131

alexbecker wrote: post #111

I don't remember running into any of these issues learning Django or maintaining a Django codebase, but I've written the problems I ran into: https://alexcbecker.net/blog/django-is-dangerous.html In general, I think Django makes it way too easy to shoot yourself in the foot.

“Validation defined on the model is only enforced on the form” hasn't been true since 2010 when Django 1.2 was released. Most of the database-related discussion shares that pattern of either being factually incorrect (“queries can't use computed columns”), blaming Django for MySQL's many problems or failing to fix problems caused by other code failing to do things like input validation. There's a real discussion abou…

You must not have read the section "Validation defined on the model is only enforced on the form". The validations I referenced, e.g. `choices`, are only run in when [`full_clean()`](https://docs.djangoproject.com/en/dev/ref/models/instances/?...) is called, and it's not called on `save()`--it is usually called through form validation.

Regarding computed columns, it looks like the specific issue I ran into repeatedly was [fixed in 1.8](https://docs.djangoproject.com/en/2.0/releases/1.8/#query-ex...). I should have been explicit that I was referring to not being able to define such computed columns on the model the way one would a normal column, not to being unable to use `F`-expressions.

Re: Django Newbie Mistakes

#146

Post by terminalcommand » Thu, Jun 28, 2018, 8:07 PM UTC

sbov wrote: post #93

terminalcommand wrote: post #51

Earlier quoted context omitted.

I would argue that it's simplicity. I believe I've read somewhere that Golang was designed with junior engineers in mind. They wanted to create a language that young engineers could learn easily yet cannot make a lot of mess due to its simplicity. They baked all features necessary right into the language. You get a http server, ssl support, templating engine etc. right in the language. You also have a database agnost…

> They baked all features necessary right into the language. Not really. What about sessions? Auth? CSRF protection?

That's true Golang does not come with automatic session management, authentication, csrf etc.

But if you look at it, csrf is just a hidden form value involving a token injected into the page. It is not hard to implement. In that sense Flask doesn't have csrf proection either.

Session management on the other hand could be troubling, but in the end they all rely on cookies: if I take a look at https://golang.org/src/net/http/cookie.go , I can easily make sense of it. But I can imagine the need for a higher level library for session management.

There is something called gorilla toolkit which has session management, but you're right it isn't included in the standard library. Golang's own template engine is also very primitive.

Re: Django Newbie Mistakes

#147

Post by Xeronate » Thu, Jun 28, 2018, 8:09 PM UTC

jojo64 wrote: post #97

aidos wrote: post #86

Earlier quoted context omitted.

What’s the motivation for moving away from python?

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…

I'm surprised you are worried about JSON performance and not ORM performance. It seems like if you really needed better serialization/deserialization you could just call a c module from python.

Re: Django Newbie Mistakes

#148

Post by terminalcommand » Thu, Jun 28, 2018, 8:16 PM UTC

Karunamon wrote: post #76

terminalcommand wrote: post #51

Earlier quoted context omitted.

I would argue that it's simplicity. I believe I've read somewhere that Golang was designed with junior engineers in mind. They wanted to create a language that young engineers could learn easily yet cannot make a lot of mess due to its simplicity. They baked all features necessary right into the language. You get a http server, ssl support, templating engine etc. right in the language. You also have a database agnost…

I ran into this problem hard while learning Rails, and a full 99.9% of tutorials out there have you using generators rather than learning how it works. As a result, I didn't learn Rails for ages, writing it off as magic beyond my ken since none of them were teaching me what I thought I needed to know. The tipping point for me was actually progressing through these tutorials a few times. In Ralis land, creating a new…

That is exactly what I felt. Even while using Flask I was put off by having to rely on magical decorators @app.route() etc. While I was experimenting with ruby I had really enjoyed toying around with the cgi module.

Nowadays I want to dig a little deeper into uwsgi with Python.

Maybe at the end of my journey, I will reach enlightenment and get to the point where I start seeing the generators as serious time savers. For now I feel like, if I want a generator, I'll build one :).

Re: Django Newbie Mistakes

#149

Post by nurettin » Thu, Jun 28, 2018, 8:21 PM UTC

jtchang wrote: post #36

One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free". I've had the "pleasu…

Play! framework for Scala was pretty close to Django back in 2012, has something changed? Did they stop developing Play! ?

Re: Django Newbie Mistakes

#150

Post by terminalcommand » Thu, Jun 28, 2018, 8:22 PM UTC

michaelcampbell wrote: post #118

terminalcommand wrote: post #51

Earlier quoted context omitted.

I would argue that it's simplicity. I believe I've read somewhere that Golang was designed with junior engineers in mind. They wanted to create a language that young engineers could learn easily yet cannot make a lot of mess due to its simplicity. They baked all features necessary right into the language. You get a http server, ssl support, templating engine etc. right in the language. You also have a database agnost…

> I believe I've read somewhere that Golang was designed with junior engineers in mind. Interesting, when one of the complaints about Java is exactly this.

I found the link again, apparently Rob Pike had said:

  The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.  [1]

But I think we should also keep Rob Pike's experience and wits in mind. It was probably intended as a humble witty remark. If you consider how complex concurrency is, and how Golang has made it simple with a single keyword to spawn coroutines (go) and a straightforward data structure (channels), I think he is right to say that Golang is easy to understand and easy to adopt.

[1] http://nomad.uk.net/articles/why-gos-design-is-a-disservice-... citing the quote from http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...