Hi Andrew, I'm rally sorry but I have very much work actually and I have forgotten your request! :( I'll come back with links to my packages ASAP, but I have to add a few comments because the documentation is far for complete (but I'm looking for contributors if anyone is interested! :D :D ). Best regards, Thierry -- https://www.ulthar.net -- http://pyams.readthedocs.io
Le mar. 26 nov. 2019 à 01:30, Andrew Martin <[email protected]> a écrit : > Yeah, I'm very interested in seeing as many different approaches to > solving this as possible. Please do share if you don't mind. > > On Sunday, November 24, 2019 at 3:56:57 AM UTC-6, Thierry Florac wrote: >> >> Hi Andrew, >> >> I've built a notification mecanism using websockets in a Pyramid >> application. >> This is based on a second application process using gunicorn, while the >> main application process is using classic WSGI (with Apache). >> The two processes also communicate using websockets; I handle client >> redirections between classic requests and websockets in Apache (using >> mod_ws_tunnel). >> I can share experience if you're interested with this project... >> >> Best regards, >> Thierry >> -- >> https://www.ulthar.net -- http://pyams.readthedocs.io >> >> >> Le dim. 24 nov. 2019 à 08:47, Andrew Martin <[email protected]> a écrit : >> >>> One thing I figured out almost immediately is that I can do what I want >>> with ${ request.resource_url(resource, host=api_url) } >>> >>> Where the api_url is configured at runtime. That might be the simplest >>> way to do things. But I will look into aiopyramid as mentioned. >>> >>> Thanks! >>> >>> On Sunday, November 24, 2019 at 12:40:02 AM UTC-6, Andrew Martin wrote: >>>> >>>> Hi there, >>>> >>>> I'd like to add a few real-time features to an existing pyramid app. >>>> Notifications when queued tasks are complete and some real-time dashboards, >>>> and chat. >>>> >>>> I'm thinking of an implementation that doesn't seem like it would be >>>> super invasive, but I though I would check here and see if some of you more >>>> experienced used see any obvious major problems first. >>>> >>>> Basically, I want to farm out the realtime elements to a websocket api >>>> server. FastAPI seems like a good framework to do this. But I'd like to be >>>> able to use the traversal machinery in pyramid to hit those endpoints in my >>>> mako templates. So my javascript for opening the websocket can use >>>> the request.resource_url() pattern and I don't have to do a ton of work to >>>> figure out where in the external API I should be connecting. >>>> >>>> So for example if in my web app I'm at mywebsite.com/users/123456, >>>> then I can have my websocket enpoint constructed by calling ${ >>>> request.resource_url(request.api, 'users', '123456') } and it would >>>> generate a URL as api.mywebsite.com/api/v1/users/123456 where " >>>> api.mywebsite.com/api/v1" is configured in the .ini file. >>>> >>>> To make that work I'd create a resource factory that adds the api >>>> property to the Root object with the value set in the .ini file. >>>> >>>> The pyramid view would continue to provide the current values from a db >>>> query, so there's a sane default to fall back on in case the websocket >>>> can't connect. For authentication and authorization, I'd server the redis >>>> instance I'm already using for server side sessions and just have the >>>> FastAPI server check that session for whether or not the user is >>>> authenticated/authorized or not. >>>> >>>> I think it should be relatively easy to share the SQLAlchemy models >>>> between the two frameworks as well. >>>> >>>> Is this totally insane? Is there a better way to do this? Am I setting >>>> myself for a world of pain that I'm not able to see right now? Just >>>> wondering if anyone can offer any guidance before I buckle down and >>>> implement this? >>>> >>>> I realize some of this is totally out of scope for this mailing list, >>>> and I"m not asking anyone to comment on whether this is a good idea from >>>> the FastAPI end of things. Just pretend that all just works. I'm really >>>> just curious about the Pyramid implementation. >>>> >>>> thanks! >>>> >>>> -andrew >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "pylons-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/pylons-discuss/2deaba67-cca3-4cb5-8ef1-5b11a59c4087%40googlegroups.com >>> <https://groups.google.com/d/msgid/pylons-discuss/2deaba67-cca3-4cb5-8ef1-5b11a59c4087%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/517e1550-1c38-48c2-982c-4c7be6d4f991%40googlegroups.com > <https://groups.google.com/d/msgid/pylons-discuss/517e1550-1c38-48c2-982c-4c7be6d4f991%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAPX_VWB2RP%3DC6TJR4wRFzJ%3DMWdt%3DEzSuOiFDyqNUK-UVLAWuWg%40mail.gmail.com.
