[meric]

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.

[beambot]

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!

[meric]

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. :)

[Vignitus]

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