Responder: A familiar HTTP Service Framework

Re:Responder: A familiar HTTP Service Framework by giancarlostoro on Wednesday October 17, 2018 @01:41AM (#18236381)

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.

[ Parent | on HN ]

Re:Responder: A familiar HTTP Service Framework by amirathi on Wednesday October 17, 2018 @03:18AM (#18236858)

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

[ Parent | on HN ]

Re:Responder: A familiar HTTP Service Framework by giancarlostoro on Wednesday October 17, 2018 @05:04AM (#18237369)

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

[ Parent | on HN ]

Re:Responder: A familiar HTTP Service Framework by kdmytro on Thursday October 18, 2018 @11:47AM (#18249300)

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.

[ Parent | on HN ]