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] > <javascript:>> 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] <javascript:>. >> 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.
