Django Code Review

[Ben Wilburn]

I will be starting a Django side project intended to be used by NSS. I'd like to get someone to review and critique my code and give me feedback on how to make my code more DRY and clean, via PR's and in person meetings. 

[JnBrymn]

Do you mind telling us a little more about your project? Do you have a public git repo?

[beck]

I could take a stab at reviewing it if you want :)

On Thursday, February 2, 2017 at 2:25:25 PM UTC-6, Ben Wilburn wrote:

[Max Shenfield]

Ditto - I love reviewing code.

[Ben Wilburn]

I would love to hear any feedback from you guys, the more the merrier! I will let you know when I get it started up. 

[Delaine Wendling]

I can't necessarily give you advice on the things you're looking for but I am starting a new project in Django and would love to see your approach! 

[Max Shenfield]

I'm also curious. I've only started two (toy) Django projects. Both times I used one of the django cookiecutter templates recommended in Two Scoops of Django.

[Max Shenfield]

We ended up meeting w/ Scott Burns and discussing

• How to start a Django project
• How Django fits into a world dominated by single page app frameworks
  

How to start a Django project: Scot recommended Cookiecutter Django, a community maintained project that lets you optionally configures favorites like White Noise, Celery, and Sentry.

Django and SPAs: Django was meant to have dominion over the entire generation of a web page. But over the past few years frameworks like React/Ember have overthrown HTML for JavaScript, with a popular optimization to pre "render" a React app in a Node process. This article describes the tension well, as well as a gamut of approaches.  Scott favors relegating Django to implement APIs and business logic with Django Rest Framework.  This approach is flexible enough to support client side rendering by serving static JS files, and eventually run Node processes to serve the frontend.  Eventbrite uses a tool similar to AirBnB's Hypernova to embed "rendered" React apps into Django templates, running Node as a separate service that just executes and caches React code.

Odds and ends: Scott recommends keeping business logic out of views, preferring to implement it in modules and models and leave views for input validation and authorization.

[JnBrymn]

My biggest questions dealt with the current shift in web development toward api-driven, single-page Javascript apps and how Django deals with this. The two biggest takeaways for me from Scott were Django Rest Framework, and pattern where Django pre-renders HTML using a Node server.

Django Rest Framework

Django's answer to api-driven, single page apps is Django Rest Framework (http://www.django-rest-framework.org/). According to Scott, DRF treats RESTful APIs similar to the way that vanilla Django treats HTML forms. Basically DRF provides a declaritive way for you to describe your data through Serializers and Deserializers and then you automagically get the full functionality of well-formed RESTful endpoints. DRF knows about various data types (JSON, XML, etc.), and DRF implements CRUD functionality associated with the HTTP verbs (GET, POST, PUT, DELETE, etc.). Finally, every aspect of DRF's REST model is pluggable. So if you don't like some aspect of what it's doing, you can surely find a function to patch that behavior.

Django Pre-Rendering HTL through a Node Server

I actually heard about this just one week back (apparently we do this at Eventbrite... who knew!?). The problem is this:

- Yes, the world is moving toward api-driven, single-page Javascript apps

- But, when a browser receives a web page it's still nice to have HTML pre-rendered because

  A) You're customers don't like staring at a blank screen while their browser downloads your 20MB javascript application.

  B) Google web crawlers won't pay much attention to your pages if they have to actually run a headless browser to figure out what humans see on your web page

- However, it's not nice to have to maintain both Django code and Javascript code that generates the same HTML (and additionally make sure it stays consistent!)

So here's what we've apparently decided to do... (And keep in mind here, I'm about as back-end as you can get... so I may be showing my backend here.) We decided to divide the task into the data collection chunk (Python) and the rendering chunk (Javascript). This way rather than having two code bases that are responsibly for rendering the same HTML response, we only have the Javascript side. But we still need to send HTML back to the browser for each request. So once Django has gathered the data required to render the page, we actually outsource the rendering to a Node server on the same machine. Node renders the HTML, ships it back to the Django app, and then Django sends it on to the browser. The browser then pulls in the HTML, CSS, scripts, etc., wakes up and continues it's life as an api-driven, single-page Javascript app. If it needs more data, it calls out to Django APIs (DRF perhaps?) and pull in what it needs.

The weird thing that remains though (and Max Shenfield helped my fully understand this) is that we still effectively render the HTML page twice - once on the Node server, and once again after the page wakes up in the browser and React or whatever starts retrieving the same data from APIs to fill in the HTML _again_. However, according to Max, improvements are already arriving wherein this second reload step is avoided when it is unnecessary.

Thanks Max and Delaine for showing up! And thanks Scott for teaching me a couple of big, new ideas.