aiohttp 1.1

[asvetlov]

My plan is:

• Incorporate yarl for URL handling (almost done)
  • switch client API to yarl.URL as well as old good str
  • rewrite server API for serving URLs in non-ambiguously way
• get rid of ResourceAdapter and PlainRoute/DynamicRoute for sake of resources.
• rewrite static file handling on top of resources
• add sub-applications maybe

[fafhrd91]

i agree with @iamybj sub-applications look like over-complication

[jettify]

While sub-application is not most urgent feature, but can help with extensibility of aiohttp. My project aiohttp_admin (https://github.com/aio-libs/aiohttp_admin) would benefit greatly from ability define own sub routes and sub middleware.

[asvetlov]

I want try to implement sub-apps now and see how easy to achieve the target.

[asvetlov]

@iamybj your comment is not constructive

[kxepal]

@iamybj Such kind of attitude doesn't helps to run productive discussions for fun and profit. Can you please be specific on the problems that subapps may introduce and how does this all correlates with UNIX theory of simple (btw, same systemd seems violates it and that's totally fine, but offtopic) instead of shifting down to personal attacks?

I don't understand why subapps need as well, but I hope some prototype will show us the reason and their goal. There is no much information about them for now to judge. For now I imagine they as sort of Flask blueprints which I also never used while idea behind was pretty useful.

[asvetlov]

Actually aiohttp sub-applications should be more complex that flask's blueprints. The blueprint is just a sketch for routes without own state. aiohttp subapps in my mind should be real web.Application instances with own state (app['value']) middlewares and signals. Reverse URL resolving should be supported as well. Root app's middlewares etc. should be processed in chain: root -> app1 -> app2.

Hope, I've described my goal. P.S. There are tho kinds of sub-apps. Technically these are should have the same implementation but routed by prefix and subdomain name.

[kxepal]

@asvetlov Thanks. So basically, they are sort of microservices within a service which could cooperate to process a request, right? If it would be possible to customize their discovery then it feels like aiohttp apps can be distributed as well (:

[ludovic-gasc]

+100 for sub-applications: On the paper, microservices is awesome, but when you benchmark, the fact you could have a lot of network HTTP requests behind the scene for a public HTTP endpoint, isn't a help to reduce latency.

For me, I understand sub-applications like microservices, but the integration/communication is in pure Python, instead of to use HTTP. You might name that "nanoservices" ? ;-)

Moreover, at least to me, both patterns aren't exclusive: you can have several HTTP daemons that can share some sub-applications: Finally you decide how many instances of your code you need, how to interact and where it runs.

For me, your architecture splits between microservices and nanoservices depend more about your political hierarchy of your company or your project, to define the limits of responsibilities of each dev team, than a pure technical choice. For me, both design patterns are necessary to enlarge our architectures possibilities.

FYI, I'm experimenting with stevedore for a project: It's a plugins library based on entry points. If you know another library, I'm interested in. You don't need that to implement sub-applications however, depends on you architecture sub-applications, it might be possible for developers to implement a sub-application as a stevedore plugin, to help the reuse of sub-applications.

[asvetlov]

Also there is pluggy used by pytest internally.

[asvetlov]

Subapplications are implemented by #1301

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

If you feel like there's important points made in this discussion, please include those exceprts into that new issue.