10 ms·

What I really need is a python web framework that has first class support for serving SPA applications (VueJS, React etc). I spent quite a bit of time setting

What I really need is a python web framework that has first class support for serving SPA applications (VueJS, React etc). I spent quite a bit of time setting up my Django app to serve VueJS (replacing the built-in Jinja templates). Once ready, it became a powerful application with ORM, middleware and all other Django goodies coupled with modern JS framework on the frontend. I hear Rails 6 is going to support modern web frameworks and using npm libraries, so something like that for Python/Django world.

blocked_again 8y ago
Ohh please. No mixing of NPM with Django.
giancarlostoro 8y ago
Sounds like you're confusing the purpose of the web framework. Don't try to force front-end specifics into a primarily back-end focused web server. Just because you create web templates for the back-end to RENDER does not mean you need to force it to push out VueJS. In theory VueJS should be able to run behind Apache stand-alone and make requests to your Python API which could be an entirely different codebase. No ambiguity if you did it this way instead, and some web frameworks let you serve up static files / HTML. If your JS front-end app is mostly static, you can just serve it up, and serve up basic HTML from the controller.
- amirathi 8y ago
  I understand the benefits of keeping front-end separate from back-end. - Separate teams working on front-end and back-end independently - Front end bundle can be served fast and cheap via CDN (only the naive serve static files with gunicorn/uwsgi right?) - and much more Knowing all that, I chose to mix up VueJS with Django solely to optimise for speed in a single person company. Thanks to this setup, - Authentication is handled via Django sessions (didn't have to spend time on JWT tokens) - I don't need to setup deployment pipeline, monitoring, testing for 2 applications. - Keep working on a single codebase and quickly iterate (slightly debatable, but still). While the setup is not ideal for everyone, it certainly has advantages that I value at my current stage. If you're curious this is the application: https://reviewnb.com https://reviewnb.com
  - giancarlostoro 8y ago
    > Authentication is handled via Django sessions (didn't have to spend time on JWT tokens) That's intriguing, wondered how that'd work out with a SPA. I'm not big on SPA's currently they only make sense for certain type of websites to me, don't mind them if they're done correctly though. But hey if what you've done works for you that's good to me, until I have to touch that code :) Hopefully it's not too awful, it just sounds a little bit out of the norm, but I'd lie if I said I've never done out of the norm solutions... > Front end bundle can be served fast and cheap via CDN (only the naive serve static files with gunicorn/uwsgi right?) Not just a CDN, for internal apps I seve all static files through Apache or nginx. I rather let a normal web server do it's job. I trust a C backend to serve static files more efficiently than some web framework, but that's just my personal view.
    - kdmytro 8y ago
      Using Django sessions in an SPA is actually very easy. It just works, the browser handles the cookies for you. The only thing that developers has to do is to remember to include CSRF header with unsafe requests (such as PUT or POST), this is usually done by adding some kind of a pre-send hook in your request library of choice. There is a section in Django docs that explains how to do just this.
philwelch 8y ago
Out of curiosity, what kind of “first class support” would you expect from a Python framework? You can write your React app as a fully decoupled codebase and then use any Python framework that serves HTTP for the API backend. The only other potentially useful feature might be server side rendering of (some of) your components, but you would have to do that in Node anyway.
- rtpg 8y ago
  (disclaimer: I don't know how this looks) if you follow the old-school web app model, you're working on the basis of stateless requests. This means that if you want to make a multi-page form, you have to build up coordination mechanisms between pages. In something like an SPA, you end up having frontend state, but you're lacking the corresponding backend state. There are a lot of times where I've wanted to do something in the backend like: first_response = await render('first_form.html') if is_valid(first_response): final_confirmation = await render('second_form.html') (This is obviously more conceptual than actual code, since actual code would require suspending python VMs for some unknown future) In a framework that is more amenable to the fact that frontend clients have state, you should be able to write out multi-request flows more easily. Perhaps with some base notion of a request trace (with the understanding that the frontend also need to send extra info to identify itself). Websockets are something interesting, but it doesn't quite enable this. And it won't be easy to get right. Failure cases in particular will require some coordination.
  - philwelch 8y ago
    The backend request handling layer pretty much has to be stateless if you want to horizontally scale it anyway. Granted, it’s really helpful to have good abstractions for managing session state, but multi-request flows are just a sequence of requests that you have to handle statelessly anyway, even if that involves maintaining, fetching, and sometimes caching session state and other data more explicitly. I see value in having mechanisms for doing that easily (e.g. my request handler function taking a “state” argument that’s automatically populated from a session state store based on a request trace, JWT, cookie, or other mechanism), but I don’t see how those mechanisms would require tightly coupling your frontend and backend aside from enforcing the session protocol.
sdrothrock 8y ago
> I spent quite a bit of time setting up my Django app to serve VueJS (replacing the built-in Jinja templates). Once ready, it became a powerful application with ORM, middleware and all other Django goodies coupled with modern JS framework on the frontend. Have you thought about writing this up? I'd be interested in reading how you went about it.
existencebox 8y ago
I'm somewhat torn about that idea. Here's why. My story is that I composed a django+angular app. Rather than replace the jinja templates, I treated them as a noop and wrapped the angular in verbatim blocks. Was a rather trivial bit of code and "Just Worked." For the same reason we look to circumvent jinja templates now is broadly why I don't think python web frameworks should be in the business of servicing one particular SPA framework. I can see some slight benefits in e.g. integrated routing support, maybe some level of model integration, but I'm hard pressed to think of how one could gain _huge_ conveniences without a real reorientation of how I look at the separations between the python and JS sides of things. (which is largely why I'm curious if I _am_ looking at all this in a very amateurish way) Anyway, I should probably take this as a reason to learn more than nothing about Rails, since all of the above may be answered by seeing what their end product looks like.
y4mi 8y ago
Builtin Django templating isn't Jinja thought...
benbristow 8y ago
Rails 5 already has webpack support and React support. https://github.com/rails/webpacker https://github.com/rails/webpacker https://github.com/reactjs/react-rails https://github.com/reactjs/react-rails Can use it pretty much fully in place of the asset pipeline. Can use standard ERB and spice it up with React using a simple tag with the component name and props as a hash.
metakermit 8y ago
I suggest you check out this development in Responder then –released in v0.1.0 40 minutes ago :) https://github.com/kennethreitz/responder/issues/53 https://github.com/kennethreitz/responder/issues/53 I'll continue helping Kenneth with this, cause that's a pain point I also want to solve for myself. On a related note, I tried to build something similar for Django in the past. (it worked, but it's somewhat under construction again due to changes in Django 2) https://github.com/metakermit/django-spa https://github.com/metakermit/django-spa

blocked_again 8y ago

Ohh please. No mixing of NPM with Django.

giancarlostoro 8y ago

Sounds like you're confusing the purpose of the web framework. Don't try to force front-end specifics into a primarily back-end focused web server. Just because you create web templates for the back-end to RENDER does not mean you need to force it to push out VueJS. In theory VueJS should be able to run behind Apache stand-alone and make requests to your Python API which could be an entirely different codebase. No ambiguity if you did it this way instead, and some web frameworks let you serve up static files / HTML. If your JS front-end app is mostly static, you can just serve it up, and serve up basic HTML from the controller.

amirathi 8y ago
I understand the benefits of keeping front-end separate from back-end. - Separate teams working on front-end and back-end independently - Front end bundle can be served fast and cheap via CDN (only the naive serve static files with gunicorn/uwsgi right?) - and much more Knowing all that, I chose to mix up VueJS with Django solely to optimise for speed in a single person company. Thanks to this setup, - Authentication is handled via Django sessions (didn't have to spend time on JWT tokens) - I don't need to setup deployment pipeline, monitoring, testing for 2 applications. - Keep working on a single codebase and quickly iterate (slightly debatable, but still). While the setup is not ideal for everyone, it certainly has advantages that I value at my current stage. If you're curious this is the application: https://reviewnb.com https://reviewnb.com
- giancarlostoro 8y ago
  > Authentication is handled via Django sessions (didn't have to spend time on JWT tokens) That's intriguing, wondered how that'd work out with a SPA. I'm not big on SPA's currently they only make sense for certain type of websites to me, don't mind them if they're done correctly though. But hey if what you've done works for you that's good to me, until I have to touch that code :) Hopefully it's not too awful, it just sounds a little bit out of the norm, but I'd lie if I said I've never done out of the norm solutions... > Front end bundle can be served fast and cheap via CDN (only the naive serve static files with gunicorn/uwsgi right?) Not just a CDN, for internal apps I seve all static files through Apache or nginx. I rather let a normal web server do it's job. I trust a C backend to serve static files more efficiently than some web framework, but that's just my personal view.
  - kdmytro 8y ago
    Using Django sessions in an SPA is actually very easy. It just works, the browser handles the cookies for you. The only thing that developers has to do is to remember to include CSRF header with unsafe requests (such as PUT or POST), this is usually done by adding some kind of a pre-send hook in your request library of choice. There is a section in Django docs that explains how to do just this.

philwelch 8y ago

Out of curiosity, what kind of “first class support” would you expect from a Python framework? You can write your React app as a fully decoupled codebase and then use any Python framework that serves HTTP for the API backend. The only other potentially useful feature might be server side rendering of (some of) your components, but you would have to do that in Node anyway.

rtpg 8y ago
(disclaimer: I don't know how this looks) if you follow the old-school web app model, you're working on the basis of stateless requests. This means that if you want to make a multi-page form, you have to build up coordination mechanisms between pages. In something like an SPA, you end up having frontend state, but you're lacking the corresponding backend state. There are a lot of times where I've wanted to do something in the backend like: first_response = await render('first_form.html') if is_valid(first_response): final_confirmation = await render('second_form.html') (This is obviously more conceptual than actual code, since actual code would require suspending python VMs for some unknown future) In a framework that is more amenable to the fact that frontend clients have state, you should be able to write out multi-request flows more easily. Perhaps with some base notion of a request trace (with the understanding that the frontend also need to send extra info to identify itself). Websockets are something interesting, but it doesn't quite enable this. And it won't be easy to get right. Failure cases in particular will require some coordination.
- philwelch 8y ago
  The backend request handling layer pretty much has to be stateless if you want to horizontally scale it anyway. Granted, it’s really helpful to have good abstractions for managing session state, but multi-request flows are just a sequence of requests that you have to handle statelessly anyway, even if that involves maintaining, fetching, and sometimes caching session state and other data more explicitly. I see value in having mechanisms for doing that easily (e.g. my request handler function taking a “state” argument that’s automatically populated from a session state store based on a request trace, JWT, cookie, or other mechanism), but I don’t see how those mechanisms would require tightly coupling your frontend and backend aside from enforcing the session protocol.

sdrothrock 8y ago

> I spent quite a bit of time setting up my Django app to serve VueJS (replacing the built-in Jinja templates). Once ready, it became a powerful application with ORM, middleware and all other Django goodies coupled with modern JS framework on the frontend. Have you thought about writing this up? I'd be interested in reading how you went about it.

existencebox 8y ago

I'm somewhat torn about that idea. Here's why. My story is that I composed a django+angular app. Rather than replace the jinja templates, I treated them as a noop and wrapped the angular in verbatim blocks. Was a rather trivial bit of code and "Just Worked." For the same reason we look to circumvent jinja templates now is broadly why I don't think python web frameworks should be in the business of servicing one particular SPA framework. I can see some slight benefits in e.g. integrated routing support, maybe some level of model integration, but I'm hard pressed to think of how one could gain _huge_ conveniences without a real reorientation of how I look at the separations between the python and JS sides of things. (which is largely why I'm curious if I _am_ looking at all this in a very amateurish way) Anyway, I should probably take this as a reason to learn more than nothing about Rails, since all of the above may be answered by seeing what their end product looks like.

y4mi 8y ago

Builtin Django templating isn't Jinja thought...

benbristow 8y ago

Rails 5 already has webpack support and React support. https://github.com/rails/webpacker https://github.com/rails/webpacker https://github.com/reactjs/react-rails https://github.com/reactjs/react-rails Can use it pretty much fully in place of the asset pipeline. Can use standard ERB and spice it up with React using a simple tag with the component name and props as a hash.

metakermit 8y ago

I suggest you check out this development in Responder then –released in v0.1.0 40 minutes ago :) https://github.com/kennethreitz/responder/issues/53 https://github.com/kennethreitz/responder/issues/53 I'll continue helping Kenneth with this, cause that's a pain point I also want to solve for myself. On a related note, I tried to build something similar for Django in the past. (it worked, but it's somewhat under construction again due to changes in Django 2) https://github.com/metakermit/django-spa https://github.com/metakermit/django-spa