Rework How IDOM Integrates With Servers

[rmorshea]

closes: #657

The change proposed here is that IDOM will expose a top-level idom.develop function that takes in a component definition and not much else. The configuration options here are intentionally limited since we want to push people away from using this function in production.

This change will also remove PerClientStateServer and SharedClientStateServer with a single configure function for each server implementation:

from idom.server.sanic import configure
configure(app, MyComponent)

As part of this change SharedClientStateServer will be removed. While it's cool, it can't be used in a production context - you need a real cross-process solution for synchronizing state (e.g. Redis).

Other issues I plan to address here:

closes: #678, closes #591, closes #669, closes #657

[Archmonger]

Will need to keep in mind that readme and docs modifications will need to occur here too.

I don't know if I agree with adding an app parameter to idom.run since it uglifies how new users will test IDOM. I think a warning message along with idom.run only taking one parameter (component) will suffice.

[Archmonger]

Here's an alternative syntax to consider, based more identically on WhiteNoise's design

from sanic import Sanic
from idom.server.sanic import IdomSanic

# Configure returns a wrapped ASGI/WSGI callable
asgi_app = IdomSanic(Sanic("My App"), MyComponent, endpoint="/idom")

[rmorshea]

I don't think IDOM has a particularly compelling reason to create provide an ASGI app, so for now I think sticking with a simple configure function should be fine.

[Archmonger]

The only compelling reason is if you want IDOM to behave more like configurable WSGI/ASGI middleware. Fairly common design pattern in the Python web dev space.

Side note, I'm assuming the reason the configure function exists is to set up the WS/HTTP endpoints, as mentioned in #653 ?

[rmorshea]

By "compelling reason", I mean that I can't think of any methods or middleware to add to an IDOM ASGI app.

And yes, the recommended way of running IDOM would be to instantiate a support application, idom.server.*.configure() it, and then run the app with an ASGI server.

[Archmonger]

Not pushing for this change, both design patterns accomplish the same task. But on the topic of middleware, it doesn't necessarily need to add methods. See Whitenoise().__call__.

[rmorshea]

I'm just not sure what IDOM would want to do in the __call__ method of its ASGI app.

I think we can stick with the configure method for now. If it turns out we want to create an ASGI wrapper it should be pretty straightforward to do so. We might not even need to deprecate the configure function since the ASGI app might continue to call that.