I feel we're getting a bit derailed here, but it seems I didn't explain what I was doing well enough.
I'm saying that in both approaches I've used, I was authoring an isomorphic React application - i.e. returning a fully-rendered html document with all the React checksum IDs pre-populated. In my first approach I had a very thin express server in node that passed request parameters to React Router, which ultimately returned a rendered page. In my second approach, I had Django hand over template context and request parameters to the node process, which also returned the fully-rendered document. I picked the second approach because it performed better to start with, but I prefer the first approach in terms of how clean the stack is. I'm a big fan of all the front-end work Facebook is putting out, I'm a total convert, it's basically solved almost everything that's annoyed me about web dev for the last 10 years. But Django has an excellent data layer, and I want to keep using it if I can. Andy On 2 June 2015 at 18:17, Emil Stenström <e...@kth.se> wrote: > On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote: >> >> Based on my own experiences building isomorphic JavaScript apps with >> Django, I haven't had any issues where I felt Django was getting in my way. >> I've tackled the problem in two different ways, both of which worked >> without any great difficulty: >> > > I think the reason that Django has not been in the way here is that you > have pushed it out of the way, and just reimplemented features that Django > should have in javascript instead. I'm not saying this is bad for your > project, it's just a shame that it's not something that Django can handle. > More concretely: > > 1. The primary web-app is actually a node process. Everything you'd >> consider a view is handled by React and React-Router, data requirements are >> handled by making an HTTP request to Django REST Framework. This isn't >> especially efficient, since the base response times aren't great when >> you're depending on HTTP for data (this can obviously be improved by >> getting the data via other channels). >> > > Here you use routing and views from React instead of using Django. The > problem with this is as you say latency since getting data is a HTTP > request, but you also get slow initial load times since there's no content > to show. Rendering on the server first to get a quick initial load, and > then delegating to React would give us the best of both worlds. > > >> 2. Use node purely as a rendering engine. I actually created an >> alternative to TemplateResponseMixin that communicated with a node process >> via zerorpc (chosen for the sake of simplicity) rather than rendering a >> template from disk. This abstraction could be made neater by packaging it >> up as a custom template engine that takes care of converting the data into >> a format that zerorpc accepts (ie no querysets or rich objects). This >> approach was significantly faster with base response times of about 8ms for >> a simple page with no data dependencies, but I felt I was implementing my >> routing logic twice (once in Django, once in node). >> > > This sounds excellent. It's almost like implementing a new template > engine, but instead just running it through node. The downside is that it > requires you to install, deploy and maintain a separate javascript > environment. What js template language were you using? > > I think implementing that same language for Django would give you the best > of two worlds. All server-side rendering would remain like for any > server-side app, but you could also send your templates to the view for > fast client side rendering. > > >> The second approach is easier to get running at acceptable performance >> levels quickly, but is quite clunky to implement. Going forward I'm >> probably going to favour the first approach, which essentially means >> turning my Django projects into nothing more than a data layer, which is >> fine for me because I've found that once you're using React (or similar) >> heavily, you're not using much else from Django anyway. >> > > Did you read the Twitter post on this ( > https://blog.twitter.com/2012/improving-performance-on-twittercom)? They > went the same route, moving all template logic to the client, found it was > too slow on initial load, and then favoured the dual approach I'm hoping > for. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/da6ffda5-b6b0-4d41-91f0-d6101a3ddd2d%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/da6ffda5-b6b0-4d41-91f0-d6101a3ddd2d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOA51CU9Qif%2BHzSSNYhEvpuQNfoYVS8QYFQdScZW9wL97fnOoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
