
Kore4 and Python - fcambus
https://blog.kore.io/posts/kore4-and-python
======
dkh
Yeah, this is very cool, and I’m surprised I hadn’t heard about it. Though I
think we’re finally at the point where async python web frameworks and tools
are great, to the point where I’m no longer jonesing for something better like
I used to, both in terms of performance and usability.

Yeah, aiohttp was where it all really began, and sanic is nice for recovering
Flask users, but if you really want to see performance and momentum, check out
Starlette ([https://www.starlette.io](https://www.starlette.io)) and FastAPI
([https://fastapi.tiangolo.com](https://fastapi.tiangolo.com)) which is built
on top of Starlette and is very clever and probably the most rapid way to
build an API that I’ve ever seen. In most practical tests Starlette also
outperforms aiohttp/etc. by a factor of 5, and the ASGI spec it’s built on is
the actual successor to WGSI and the future of python web programming.

Things have come a very long way the last handful of years, and there are many
great options. Nice to see yet another one.

~~~
madelyn
For anyone interested in Starlette or general async programming in Python, I
also want to point out that there's a few great packages maintained by
Encode/Tom Christie (of Django Rest Framework fame).

The developer ergonomics are getting really good, I especially love
encode/databases, which has full support for SQLAlchemy Core, and
encode/httpx, a requests-like HTTP client.

[https://github.com/encode](https://github.com/encode)

~~~
dkh
Agreed completely. I also use ‘databases’ and... most of their other packages.
One of my favorite devs to watch.

------
wruza
Why do project like this spawn in hordes? I don’t ask it to criticize kore4 in
any way, let me explain.

Every new framework for web does almost the same thing in slightly different
way: serve http routes by assigning functions to it and inserting some
middleware to check/replace something in the request. But why is it important
at all? Why don’t we see numerous both-side frameworks which make http (rest,
ws, etc) completely transparent?

As a long-time desktop dev I would like to use an object lib, which would take
the burden of api and provide clean interfaces between client/server/db. Like
this pseudocode:

    
    
      # backend
      @net()
      @db()
      class Car:
        members
        methods
      Car.export(some_members)
      Car.export(some_methods)
    
      // front
      let edit = await db.edit()
      let car = edit.new(db.Car)
      car.year = 2013
      car.pic = await edit.upload(some_pic, progress_handler)
      car.vendor = db.Vendor.find({
        title:’Ford’})
      ...
      await edit.save()
      // or edit.cancel()
      //    which also removes pic
    
      // eventually
      let car = db.Car.find({year:2013})
      car.drive_to(some_loc)
    
      # car drives to some_loc in backend
      # Your taxi app prototype
      # almost done here
    

Instead we happily define routes in yet another way, which feels like when I
was in a school writing masm 100-liners to open a file and print its contents.
Am I missing something?

I know about vaadin and outsystems, but these are enterprise behemots, one
paid, one too complex* and opinionated to begin with. Why not npm install
dbnetlib, app.use(dbnetlib()) and go create?

* a good sign that you’ll have to jump through hoops on non-standard tasks.

~~~
rumanator
> But why is it important at all?

Because that approach fits the problem of implementing a request/response
message pattern to a tee.

> Why don’t we see numerous both-side frameworks which make http (rest, ws,
> etc) completely transparent?

Because you'd be making the mistake of mixing up how to handle your messages
with how you parse and interpret the messaging protocol.

You should not be mixing up responsibilities which are entirely orthogonal.
You either parse HTTP requests to decide how their messages should be
interpreted (i.e., routing) or you act on the message that has been correctly
routed (i.e., what you actually wanted to do in the first place ).

Do keep in mind that HTTP just serves as a messaging protocol, and in order to
deliver a message first you need to validate it and pick where and how it
should be handled. Web APIs are designed arbitrarily to depend on some
features of HTTP to validate and route messages, and some of these design
decisions are so common that some web framework make developers' lives easier
by providing built-in modules that avoid boilerplate code (i.e., middleware).

If you're developing a web API and you are systematically having to deal with
HTTP then, to put it bluntly, you are doing it wrong. That job is already done
if you pick one of these frameworks, and you're simply reinventing the wheel
with no good reason.

> Instead we happily define routes in yet another way, which feels like when I
> was in a school writing masm 100-liners to open a file and print its
> contents. Am I missing something?

Yes, the fact that with these frameworks you are able to focus on implementing
what you're supposed to be implementing (essentially message handlers) instead
of having to waste your time reinventing the wheel filling in boilerplate code
just to get to your task at hand.

~~~
wruza
What are frameworks/middleware you’ve mentioned? I’m confused since if the
snippets above reinvent some wheel, I would like to use that wheel instead.

The other commenter suggested looking at Phoenix/Elixir, but its getting
started doc doesn’t seem to do net-transparent objects - it’s the same “hey
route, hey handler” approach. My idea is that if you do e.g. a taxi app, then
the only ‘routes’ you should care about are routes on the map.

~~~
rumanator
> My idea is that if you do e.g. a taxi app, then the only ‘routes’ you should
> care about are routes on the map.

There are no routes on the map.

As a backend developer, your job is to define what are the valid routes and
how to handle non-compliance but valid requests.

Take for example content negotiation. Do you honour the Accept header or do
you serve content based on the request path, such as the resource extension?
What should you do if you receive a request where both approaches are used but
in a contradicting manner?

Now, keep in mind that API versioning is handled as content negotiation.

Now, let's add auth to the mix. Do you intend to hand-roll a few OpenId
connect workflows by hand, which involve 3 or 4 HTTP requests behind exchange
between 2 or 3 actors? Are you intending to hand-roll token expiration checks?
Or do you prefer to use an API key or session cookies, or any other, or a mix
of all of them put together?

And what about caching? Are you expecting to check and tweak cache control and
etags headers each and every time you receive a request?

Or do you only want to receive a request and act upon it's request body?

If you use one of these web frameworks, all you need to do is configure your
middleware to specify how you handle auth and cache and content negotiation,
define routes based on the outcome of your content negotiation process, and
proceed to implement your web API.

------
gigatexal
How am I only hearing about this now? Looks intriguing

------
jimnotgym
What I really need is a very concise methodology to help idiots like me
understand why I would need yet another web framework.

------
sp527
For people interested in a high-performance Python asyncio web server, sanic
([https://github.com/huge-success/sanic](https://github.com/huge-
success/sanic)) is also worth evaluating.

------
ngcc_hk
Seems perfect for my purpose. Thanks.

------
salmo
Does anyone use this for anything real?

~~~
hiwk
Yes.

------
ralala
Can I use this with aiohttp?

------
juped
I always forget Kore has Python support. It is not a bad fit.

