Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Responder: A familiar HTTP Service Framework

python-responder.org

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Responder: A familiar HTTP Service Framework

#81

Post by meowface »

reassembled wrote: post #18
setr wrote: post #7

Maybe I’ll accept non-monospace fonts for code. You get the right ligatures, decent kerning, the softer touch of sans-serif... it has some possibility But psuedo-cursive strings? This font that looks like a retro emulator using a vectorizing filter? This is too much. I’m not happy about this development at all.

I believe the font is called Operator Mono and seems to have become popularized by the React scene. I was using it for a while and actually kind of like it but lately I've been experimenting with Fira Code, which also has ligature support.

I've tried Fira Code but the ligatures and the overall look and feel of the font somehow feel too "loud" to me.

Now that I'm looking at Operator Mono, I think I'll actually give that a try.

Re: Responder: A familiar HTTP Service Framework

#82

Post by rtpg »

philwelch wrote: post #77
rtpg wrote: post #75

Earlier quoted context omitted.

(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 somethi…

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…

beyond the session protocol, you have to think about the bundle of state you need to carry between requests in a _clean_ way (preferably something that goes beyond "stuff it in the session dict", because that's basically global variables). You also most likely want ways to do things like fetch non-stale versions of objects from the DB, help with certain data assertions, etc.

You don't need to have a stateless backend for horizontal scale, you can have relatively smart routing, or relying on stuff like the database to help you with the coordination. Especially if you do things like say "this session is held to for up to an hour" you could even consider suspending VMs! If you have the resources to do so, that is.

I think that "coupling frontend and backend" is not really what is being requested here, but more about providing functionality that lets you build rich backends based on the fact that our frontends are way richer than they used to be

Re: Responder: A familiar HTTP Service Framework

#83

Post by amirathi »

giancarlostoro wrote: post #69
amirathi wrote: post #61

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…

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 am…

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

Re: Responder: A familiar HTTP Service Framework

#84

Post by benbristow »

amirathi wrote: post #61

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…

Rails 5 already has webpack support and React support.

https://github.com/rails/webpacker 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.

Re: Responder: A familiar HTTP Service Framework

#85

Post by tomchristie »

diminoten wrote: post #21
m_ke wrote: post #4

Earlier quoted context omitted.

I'd argue that python needs an async django, which will hopefully be django in a few releases.

Yeah I mean the async landscape for web frameworks isn't exactly as populated as the "yet another web framework" statement makes it seem. This is how we get to async Django, and I think that's part of why Tom Christie is helping out. I also doubt Reitz thinks this is the usurper of Django anyway. It's more than an experiment, but less than "the new One True Way". As for ASGI python web frameworks, there are no mature…

Yo. Yeah my (bit of) involvement is mostly around wanting to help guide the new ASGI ecosystem.

For example, I'd like to see Python's async frameworks building on ASGI middleware rather than all re-writing their own middleware APIs. That way we end up with lots of cross-framework compatible middleware implementations, and we're all working together much more coherently.

Similarly for test clients. We don't really need frameworks to all be building their own individual test clients to interact against their own interfaces, when we can instead build test clients to interface against ASGI, and then be able to use them against any ASGI framework.

That's part of what the Starlette project (which Responder uses) is all about: https://www.starlette.io/

(FWIW Starlette also composes all those bits and pieces into a framework in its own right)

Re: Responder: A familiar HTTP Service Framework

#86

Post by Bogdanp »

ForHackernews wrote: post #65
paultopia wrote: post #49

Earlier quoted context omitted.

Yeah, the speed thing with lockfiles is painful. But python dependency management is such a mess anyway that it's probably the best thing out there.

Consider https://github.com/sdispater/poetry as an alternative.

Another good one is pip-tools: https://github.com/jazzband/pip-tools (which pipenv set out to replace initially, but it does a terrible job of it IMO)

Re: Responder: A familiar HTTP Service Framework

#87

Post by giancarlostoro »

amirathi wrote: post #83
giancarlostoro wrote: post #69

Earlier quoted context omitted.

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 am…

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…

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

Re: Responder: A familiar HTTP Service Framework

#89

Post by roboyoshi »

daenz wrote: post #60

>The Python world certainly doesn't need more web frameworks. But, it does need more creativity. Then why create a "new python HTTP service framework"? The Flask and Falcon communities are very welcoming to creativity. This project strikes me as a fun side project that doesn't have serious legs or ambitions, which, don't get me wrong, is totally encouraged and fine! However, when it's being touted as a new framework…

> This project strikes me as a fun side project that doesn't have serious legs or ambitions

And it totally is! "The primary goal here is to learn, not to get adoption" [1]. Kenneth Reitz is just another developer who created a public repo with some docs, a logo and the clear indication that it is just for fun. I don't see why everyone is so on the fence with this.

[1] https://github.com/kennethreitz/responder#the-goal

Re: Responder: A familiar HTTP Service Framework

#90

Post by reilly3000 »

As a very regular Requests user I'm pretty excited about Responder. There are times when I just want to stand up a 'glue' API, and this looks extremely convenient for that purpose. I've wasted too many hours futzing with flask+WSGI+nginx+ubuntu to want to stand up something with it on a whim.
Post reply on HN