Responder: A familiar HTTP Service Framework • Hacker News Board

Re: Responder: A familiar HTTP Service Framework

#61

Post by amirathi » Wed, Oct 17, 2018, 5:00 AM UTC

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.

Re: Responder: A familiar HTTP Service Framework

#62

Post by a1369209993 » Wed, Oct 17, 2018, 5:06 AM UTC

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…

Regarding #2, the python code has the arguable advantage that (with appropriate variables in scope) it's valid standard python code[0] that could evaluate to (a representation of) the desired type, whereas the typescript isn't valid javascript code, and I don't think it's a valid (value-level) typescript expression either.

3 and 4 are disappointing though.

0: I'm assuming the extra [ after Callable is a typo.

Re: Responder: A familiar HTTP Service Framework

#63

Post by basil-rash » Wed, Oct 17, 2018, 5:18 AM UTC

a1369209993 wrote: post #62

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…

Regarding #2, the python code has the arguable advantage that (with appropriate variables in scope) it's valid standard python code[0] that could evaluate to (a representation of) the desired type, whereas the typescript isn't valid javascript code, and I don't think it's a valid (value-level) typescript expression either. 3 and 4 are disappointing though. 0: I'm assuming the extra [ after Callable is a typo.

Is there a utility to having your types and your values in the same namespace?

The extra [ is not a typo, the syntax is: `Callable[[Arg1Type, Arg2Type], ReturnType]`. Or, if the arguments don't matter, `Callable[..., ReturnType]`, but this does not mean that the type is not a valid expression.

Edit: I was missing a ] actually, separating the arguments from the return value.

Re: Responder: A familiar HTTP Service Framework

#64

Post by gigatexal » Wed, Oct 17, 2018, 5:23 AM UTC

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.

Re: Responder: A familiar HTTP Service Framework

#65

Post by ForHackernews » Wed, Oct 17, 2018, 5:29 AM UTC

paultopia wrote: post #49

meddlepal wrote: post #44

Earlier quoted context omitted.

So I've been using it a bunch on my more recent Python projects. The promise and the reality are unfortunately not close. For the record I love having a one stop tool for virtualenvs and dependency management. That's quite nice. The Pipfile is nice. The Pipfile.lock is awesome. The tool itself is: 1. Painfully slow. 2. Very buggy. For example `pipenv graph --json` is broken in the latest release. This is the mechanis…

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.

Re: Responder: A familiar HTTP Service Framework

#66

Post by korijn » Wed, Oct 17, 2018, 5:29 AM UTC

Are benchmarks available? And "nginx not needed"? Is uvicorn really that great?

Re: Responder: A familiar HTTP Service Framework

#67

Post by andrewstuart » Wed, Oct 17, 2018, 5:33 AM UTC

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.

Re: Responder: A familiar HTTP Service Framework

#68

Post by blocked_again » Wed, Oct 17, 2018, 5:37 AM UTC

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…

Ohh please. No mixing of NPM with Django.

Re: Responder: A familiar HTTP Service Framework

#69

Post by giancarlostoro » Wed, Oct 17, 2018, 5:41 AM UTC

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

Re: Responder: A familiar HTTP Service Framework

#70

Post by philwelch » Wed, Oct 17, 2018, 5:41 AM UTC

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.