Hacker News Reader

Comment by sudo_bang_bang | Hacker News Reader

I loved Django when I started using it about 4 years ago. Lately, I've switched to Flask and replaced the templating with React. I love the new way, but I still have a place in my heart for Django. Does anyone on HN still start new projects with Django or have you moved on as well?

View on HN

Django-Rest-Framework still seems to beat any equivalent in any language that I've found... coupled with the admin, it's a dream. But I also use React for views, and avoid any HTML coming from the server whatsoever (except the admin, which is due for a more complete overhaul than this brings)

We have the exact same setup. DRF + server-rendered React is pure awesomeness.

Could you expand on your server rendering of React ?

We built an javascript API mapping that's "isomorphic". The express server receives a request, and for each route we have a function that takes the request, uses the API mapping that sends REST calls to our django server to grab the appropriate data, sends the data through to the store (server calling createStore from redux), the body rendered using Provider from react-redux, and using the react-router, which is rendered back on to the express response. The state is pasted onto the page using JSON.stringify (with some caveats to escape </script> tags), and is hydrated back onto the elements on the page by the browser, by calling on createStore on the state pasted onto the page.

Hmm I'm still not following. Can you dumb that down a bit? Or is there a simple example you can point to?

Like others have mentioned, I love django for all the batteries-included features (admin, sessions, ORM, etc). But I still haven't really found a good way to use Django with React JSX as the template engine -- rendering & caching serverside for SEO purposes, but still responsive client-side.

I haven't seen a good description of how to pull this off... but it would make a great eBook (I'd buy it!).

It seems like the Django RESTful API would be one solution... but it would result in a lot of extra REST requests (so blocking & latency) being generated during server-side rendering, so perhaps not the best solution.

Thoughts?

(I am aware of solutions like this, but it misses the server-side rendering aspect with contexts: http://stackoverflow.com/a/28646223 )

To reduce blocking and latency from network calls, we spent a day or two to write a batch view library that will take a list of request bodies, parses it, use the django router to send each request to the appropriate django view, running the middleware, and in the response returns a list of response bodies. Implementing this protocol almost exactly. https://cloud.google.com/storage/docs/json_api/v1/how-tos/ba... We also had to write a piece of javascript client middleware that would delay all requests by 0.01 seconds and batch up all the requests that happen in that time to send to the batch view. Proprietary code I'm afraid we cannot share but there's the idea, it's not patented and takes about two days. We use server rendering for all non-logged in views.

I think I'm starting to get it... but perhaps I can parrot back for clarification? So you setup django as usual: REST framework with the normal REST API endpoints.

For client-side, everything works as normal: The React code starts with static values for state/props that are pre-populated (ie. the return value for getInitialState was already determined during server-side rendering). Upon app updates (eg. user interaction), the app will make asynchronous calls to the correct REST endpoints -- perhaps batched, as you mention. Client-side is the "easy" part of this one. :)

For server-side rendering you have a normal HTTPresponse-returning Django view (eg. for /). That view compiles/renders the React JSX "template" in NodeJS. Only for server-side, when you call renderToString to get the initial HTML, getInitialState is actually a series of REST requests (in javascript) which are batched, sent to django, and returned (map-style) to node as JSON for initial rendering.

Two questions:

(1) Does the REST request batching get sent to a different, special endpoint for batching? Or when you say "middleware", do you mean that any REST request is capable of being a batched request via the middleware?

(2) There seems to be some nuance in structuring getInitialState (or props) so that it makes the REST calls on the server-side, but not on the client-side. I'd be curious to see how you structured that.

PS -- You might shoot me an email (in profile) since this is somewhat OT to the thread? I'm super-appreciative of your insight!

The client description sounds good.

The the server-side rendering description is a bit off. We have the Django REST framework server that never serves HTML except Django Admin. All pages go to the Node.js server which renders the HTML using React, and sends it through when the page is loaded. The same react code is also loaded onto the browser to update the HTML asynchronously later. We have two projects setup - one django project and one node project.

"Only for server-side, when you call renderToString to get the initial HTML, getInitialState is actually a series of REST requests (in javascript) which are batched, sent to django, and returned (map-style) to node as JSON for initial rendering."

Sounds mostly good, except we return the list of responses using the protocol I've linked to in the comment. (multipart response with boundaries, responses written one after the other in the same order as sent). This is taken care of by the middleware and is transparent to the rest of the node/react code. The data gets parsed as usual into JSON and used for initial rendering.

1. Yes. It's a special endpoint for batching. By "middleware" I meant client-side middleware. On django it's just a view we've written, that parses the request(s) and puts them through django's `WSGIHandler`, and extracts the responses and render them one by one into the same HttpResponse.

2. I've posted how we've done this in another comment. :)

What is your opinion of https://github.com/markfinger/python-react ?

Django is still my default goto for starting projects. I create backend data entry as an old style CRUD app. And I do the front end on wordpress and use REST API to fetch data from Django.

This is interesting. I have written a django backend written for an organization already having a wordpress site. Having never written a piece of php code i must ask: Are you aware of any resources that could be particularly helpful for the php/wordpress part? Or is it more like embedding a lot of javascript into your wordrpess site?

I write functions to interact with the REST api in PHP and use them in theme code.

Lets say you have a page for location based doctor search. When the search form in this page is submitted, wordpress makes API calls to django backend where real search happens and a list of doctors is returned to wordpress. Wordpress then genereates html and send it to the browser.

Similar process for dislaying a specific doctor details.

The CRUD and other application logic for doctor data is handled in Django. And with rest API you can then create a web based UI or a mobile application.

I use the same architecture... DRF for the API, admin for quick data manipulation, Ember for the interface and I enjoy it immensely. I am learning Phoenix because it would allow me to handle bidirectional communication in the same codebase along with other Erlang advantages. So far it doesn't seem to have anything comparable to DRF.

Might worth checking out webmaching: https://github.com/webmachine/webmachine/wiki/Overview

I use django for big stuff & flask for little stuff (like a proxy server or url forwarding app).

I used Django at my last startup ~3 years ago, but now I use Flask for any new projects. Django is great if you need all the functionality, but the more lightweight Flask fits my needs now. With flask-bootstrap, I can make something nice in a jiffy.

I do start new projects with Django all the time. It's very efficient and not too complex. Really a good fit for most site and it excels at creating APIs too.

My main toolbelt these days is DRF + React. So yes.

Reply on news.ycombinator.com