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

71–80 of 116 posts

Re: Responder: A familiar HTTP Service Framework

#71

Post by sdrothrock »

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…

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

Re: Responder: A familiar HTTP Service Framework

#72

Post by giancarlostoro »

monkmartinez wrote: post #2

Pretty cool, but I can't shake the feeling that the first example looks an awful lot like javascript... Perhaps... Maybe ... its because I have been "cheating" on Python with JS. I mean, it is a pain in the booty to code up a web app in python without JS. Try to code a mobile app with Python and Kivy... not all that fun (not practical). In less than a week with React, I have done both. So... why not just skip Python…

I love Python for back-end web development, it's hard to shake it off of me, except if I were doing ASP .NET Core (I'm ok with C#). So I think in that area it's pretty solid, but I agree, I wish the GUI side of Python got more love, maybe a proper RAD environment like VB had, hate on VB all you want, but damn it was neat. I'm surprised Kivy doesn't have a RAD editor, if it does then I am way behind. For now I'll keep using Tkinter.

Re: Responder: A familiar HTTP Service Framework

#73

Post by giancarlostoro »

andrewstuart wrote: post #67

async & fstrings - seems Kenneth is on board with Python 3 then. One of his other really great applications is "das inbox" https://github.com/kennethreitz/inbox.py - it's brevity is inspiring - actually Responder seems very similar to das inbox.

It's not very encouraging to see that one as archived by the developer. I'd hope this new web framework he made doesn't end up the same way. I wouldn't mind experimenting with it.

Re: Responder: A familiar HTTP Service Framework

#74

Post by existencebox »

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…

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.

Re: Responder: A familiar HTTP Service Framework

#75

Post by rtpg »

philwelch wrote: post #70
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…

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.

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

Re: Responder: A familiar HTTP Service Framework

#76

Post by akubera »

basil-rash wrote: post #58
jnwatson wrote: post #45

Earlier quoted context omitted.

You need `import typing`, and an editor with integrated mypy (e.g. vim). It is almost as good as static typing.

Initial thoughts from looking through https://docs.python.org/3/library/typing.html# : 1. Love that it doesn't use structural typing, NewType seems great. 2. The syntax is bad. Maybe this is a "it just takes getting used to" thing, but I actually find it really bad. In TS, the syntax for typing almost always directly matches the syntax for the rest of the language. In Python, its a weird sort of LISPy DSL think that…

If you use isinstance(x, (int, float)) instead of type(x) == int then I think you'll find your expected behavior.

When you say type narrowing do you mean floats should be automatically interpreted as int? There is typing.{SupportsInt, SupportsFloat} which can be considered "number" base classes which you may consider as type narrowing. Otherwise if you mean "type of x is known in this if-block" you do get that with `isinstance` type checks (which is the preferred, pythonic way).

I agree that mypy should warn if a NoReturn is assigned; apparently it just ignores typechecking below the NoReturn function call, and is really only used to ensure the NoReturn function is guaranteed to raise before it returns.

Re: Responder: A familiar HTTP Service Framework

#77

Post by philwelch »

rtpg wrote: post #75
philwelch wrote: post #70

Earlier quoted context omitted.

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.

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

Re: Responder: A familiar HTTP Service Framework

#78

Post by daenz »

gigatexal wrote: post #64
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 is Kenneth Reitz, it’ll be supported.

Sorry, but invoking the name of someone who has many half-baked projects on their github (and again, that's totally fine), doesn't instill confidence in me to put my business's new product on it. There's nothing groundbreaking here. Innovation has to outweigh the lack of project maturity for serious people to use it in production, and the innovation just isn't here.

Re: Responder: A familiar HTTP Service Framework

#79

Post by jakear »

akubera wrote: post #76
basil-rash wrote: post #58

Earlier quoted context omitted.

Initial thoughts from looking through https://docs.python.org/3/library/typing.html# : 1. Love that it doesn't use structural typing, NewType seems great. 2. The syntax is bad. Maybe this is a "it just takes getting used to" thing, but I actually find it really bad. In TS, the syntax for typing almost always directly matches the syntax for the rest of the language. In Python, its a weird sort of LISPy DSL think that…

If you use isinstance(x, (int, float)) instead of type(x) == int then I think you'll find your expected behavior. When you say type narrowing do you mean floats should be automatically interpreted as int? There is typing.{SupportsInt, SupportsFloat} which can be considered "number" base classes which you may consider as type narrowing. Otherwise if you mean "type of x is known in this if-block" you do get that with `…

`isinstance` is what I wanted for narrowing, thanks!

Re: Responder: A familiar HTTP Service Framework

#80

Post by y4mi »

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…

Builtin Django templating isn't Jinja thought...
Post reply on HN