Sanic: Features/Milestones for 19.9

[yunstanford]

thread for discussing goals of 19.9 release

[ahopkins]

I am working on an alternative Router implementation. Whether it is something we want to introduce To Sanic is another question. My goal was to make it faster, but also to reduce and correct some of the... idiosyncrasies of the Sanic router. I should have my proposal ready in the next week or so.

[ahopkins]

Fixing websockets in the native Sanic server. #1629

[harshanarayana]

@yunstanford Here's what I have in my todo list

1. I am working on adding the changes required to manage Release note automatically using towncrier. This should help us manage a better changelog and eventually start publishing it to the Website directly at some point.

2. Add signal support for request and response middleware so that the events can externally be handled. These events can come handy when someone wants to integrate sanic application with Opetracing client or other monitoring tools. This is still a proposal for me. I will put a new Ticket with a detailed proposal in a day or two.

3. Documenting the LTS guidelines to both Document here as well as the Sanic community website.

[ahopkins]

@harshanarayana

The signal idea sounds awesome. Looking forward to hearing about that.

I would be happy to work with you about those guidelines. It needs attention I agree. I also would like to get some people together to start working on a proper website: docs, examples, tutorial, announcements. Integrating that with towncrier for a changelog sounds great. Not sure if the website is something to do for 19.9, but I think we should certainly try and have it in place for the next LTS. It would go a long way towards building a public face for the project.

[harshanarayana]

The signal idea sounds awesome. Looking forward to hearing about that.

Just opened a new Proposal ticket in Issue with the details https://github.com/huge-success/sanic/issues/1630

I would be happy to work with you about those guidelines. It needs attention I agree.

Couldn't agree more. Getting the basic design right the first time is really important. I have the initial draft of the proposal. Please feel free to use the ticket for further discussion. I am eager to hear more from the @huge-success/sanic-core-devs

Integrating that with towncrier for a changelog sounds great.

Right now the idea is to just simplify the effort required in managing the changelog while cutting a new release. But that can later be integrated with the release.py script we have to make sure the change logs are auto-published when we have the website ready to go.

It would go a long way towards building a public face for the project.

Absolutely. I would be more than happy to help in any way I can.

[likern]

I would like to see plugin API. As I see some extensions they all connected differently. It will allow build extensions in a unified way.

Fix notorious bug that middleware blueprints are registered globally.

[ashleysommer]

@likern
That is the reason I created https://github.com/ashleysommer/sanicpluginsframework I was frustrated at seeing all extensions attempting to attach to Sanic in different ways. And most plugins treating Sanic app as if it was Flask, with mixed results.

SPF has been around since October 2017, and has been compatible with all Sanic versions since Sanic v0.6.0.

It adds a common plugin interface for Sanic, which can be used to create almost any kind of plugin. It also adds commonly requested features that plugins need, like a request-context dict.

So far there are only four public plugins I know of that are made using SPF, and they are plugins I've written or ported personally. Its pretty hard to get other plugin makers to switch from their preferred ways of working.

[likern]

@ashleysommer I've seen your work and I like it. But plugin API should be officiall, so users and devs can be sure it's reliable and it will not break accidentally, it's difficult to invest time to plugin if SPF at time might become unsupported. But it might be merged as official or be base of plugin API

Anyway, I think it's good time discuss plugin API and how to extend Sanic All major Node.js competitors have that support

[harshanarayana]

@likern Enabling a standardized way of writing plugin is one of the reasons I opened a new proposal under #1630

If implemented right, that proposal will go a long way in standardizing how the sanic plugins can be built and integrated while following a standard, conventional and official API. Please feel free to go over the document and add comments accordingly.

[yunstanford]

Regarding the unified plugin API, we should have an official spec in our Documentation, e.g if we adopt the one @ashleysommer created/proposed.

[subhoreck0n]

Does it make sense for Sanic to have its own ORM rather than relying on SQLAlchemy?

[Tronic]

Does it make sense for Sanic to have its own ORM rather than relying on SQLAlchemy?

No. Sanic has nothing to do with databases (or templating etc). Besides, you could be using Redis, Mongo or other no-SQL databases (I certainly am).

[sjsadowski]

I'd be really interested in officially adopting @ashleysommer 's plugin framework to allow for standardizing things better as well as having a 'recommended, official' way for people to extend sanic.

[sjsadowski]

With ASGI in place, I'd like to start looking at deprecating the WSGI stuff. Stripping out the custom gunicorn workers and generally working toward 100% ASGI. 18.12LTS will continue to support them through 2020, and I'd like for us to have a decision for 19.9 so that we have a deprecation period before this year's LTS.

[ashleysommer]

@sjsadowski I'm happy to work closely with the rest of the devs to make SanicPluginsFramework the adopted standard for extending Sanic, if that is the path we choose to go down.

The way SPF currently attaches to a Sanic App, is it uses monkey-patching to create wrappers for the handle_request, _run_request_middleware, and _run_response_middleware methods, in order to inject the extra functionality. The idea is, SPF should do this one time, in a correct and standard way (without introducing side-effects), then all plugins will attach to SPF. Rather than having 10 plugins each monkey-patch and attach to the app separately with indeterminable results.

This could be further streamlined by either:
1) Adding built-in functionality in the Sanic app for allowing replacing/wrapping its handle_request, _run_request_middleware, and _run_response_middleware methods.
2) Or adding new signals as suggested by @harshanarayana to allow SPF to intercept and respond to the request.

[ahopkins]

@sjsadowski I am not sure that I am personally ready (nor do I think the project ready) to start discussing the deprecation of the gunicorn worker. I would like to see ASGI get a little more robust, and perhaps tackle that in the 2020 release cycle.

@ashleysommer While I 100% appreciate what you have attempted with SPF, I do not personally like its approach with monkey-patching, etc. This is why I did not opt to use it for sanic-jwt. I am very intrigued by the signal idea, and think that something that is native and built in makes a lot of sense.

[Garito]

Giving the fact that sanic is async, I see no point on gunicon or similar
I run it on a docker containers (for scalability)
Perhaps someone could explain to me for what is this needed

About SPF: agree with @ahopkins: monkey-patching bad

A side note: I tend to respect more projects that, from time to time, reduce their code base
The less code the better ALWAYS and the majority of projects tend to add, add, add, never clean up
In the same note: one method for doing things much better than more than one

[bronte2k7]

loading config from JSON

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions.

[danieldaeschle]

1. A sanic command would be nice. sanic run
2. Custom commands for the sanic command.
3. Dependency injection please! (like vibora did it)
4. Type annotations

[ashleysommer]

Hi @danieldaeschle
This issue/topic is for the 19.9 release, that was completed back in September 2019.
If you have any new feature requests, please open a new issue, title something like [Feature] my feature request
And it might make it way into the features/milestones of the next release!