Flask Gunicorn Embed where gunicorn bound to unix socket

[crlot]

Is it possible to embed Bokeh within a Gunicorn based Flask app but where gunicorn is bound to a unix socket as opposed to an IP and port?

i.e. Gunicorn:

/usr/bin/python3 /usr/local/bin/gunicorn --workers 2 --bind unix:mysocket.sock -m 007 myproject:create_app()

And then replicating the flask_gunicorn_embed.py example on github doesn’t work as presumably the line:

sockets, port = bind_sockets(“localhost”, 0)

…sees the server later bound (using bokeh_http.add_sockets(sockets)) to the sockets on localhost (or whatever IP is specified in that field) as opposed to the unix socket?

I see there was once an issue raised for this feature but it was closed: Make bokeh server posible to listen unix socket. · Issue #5383 · bokeh/bokeh · GitHub

If I just try to specify the server IP, localhost or 127.0.0.1 in the bind_sockets call, I see net::ERR_CONNECTION_TIMED_OUT for: https://127.0.0.1:41779/bkapp/autoload.js?bokeh-autoload-element=1001&bokeh-app-path=/bkapp&bokeh-absolute-url=https://127.0.0.1:41779/bkapp presumably because gunicorn has bound to the socket and not the IP.

Can anyone advise whether they’ve been able to embed bokeh in a Flask app where Gunicorn is bound to a socket and note the adjustments they’ve had to make to the flask_gunicorn_embed.py example? I’ve tried specifying mysocket.sock in the bind_sockets call instead but this crashes the app…

Thanks,
Carl

[Bryan]

There was never any work done to support this use case (and I would not expect it to work without some new development).

[crlot]

Hi Bryan,

Thanks for coming back to me and seasons greetings! I’ve just ended up running a Bokeh server separately and making calls to the server’s IP & port from the Flask app so have managed to embed as required. At the moment in testing and from the docs I can’t see any drawbacks to this other than running Bokeh server and Flask as opposed to just running it all within Flask, would you agree?

Thanks,
Carl

[_jm]

Hi @crlot

The setup you describe – with Flask and bokeh server running as separate applications – is a perfectly reasonable partitioning of functionality.

I deploy my applications to Heroku (an online platform as a service), and because of how it constrains websockets, I found it easiest to organize my code similar to what you describe.

I ended up with a Flask application than handles user management (authentication, access, etc.) and other tasks like using dropzone to upload large-ish datasets.

A bokeh server is running as a separate application (separate Heroku dyno in my case). The Flask app integrates this into its website layout via bokeh’s pull_session(...) and server_session(...) calls.