That’s great - thanks for pointing me to the right spots in the documentation. Decoupling everything is a main attractor for me, so this is perfect. To be clear, guest configuration would have me “crossbar start” the router, and then independently “crossbar start” any WAMP components, correct?
Also, when you say “…that in many cases enable you to run your entire backend using Crossbar.io”, do you mean “…that in many cases enabled you to run your entire backend within a single Crossbar.io process”? Because in all three of the configurations (router, container, guest) I am running everything “using Crossbar.io”, no? (It’s just the process models that are different, yes?)
The documentation at http://crossbar.io/docs/Guest-Configuration/ says:
“Guest workers are worker processes spawned by Crossbar.io which run application components written in languages other than Python (the language which Crossbar.io is written in), or in Python 3.x (Crossbar.io is currently on Python 2.7).”
Although the focus here is on the fact that Crossbar.io can incorporate languages other than Python 2.7 (which is super), the far greater story (in my opinion) is process isolation/decoupling! Additionally, the above wording makes it seem as though one wouldn’t use guest configuration if one *was *using Python 2.7. From my (probably ignorant) view, I would always want to use guest configuration.
Although container configuration spawns separate processes, it does rely on the process that the router is within, right? Guest configuration has no such dependency, yah?
I’ve just noticed I’ve sprinkled questions throughout this response. Let me compile:
F1 = guest configuration would have me “crossbar start” the router, and then independently “crossbar start” any WAMP components
F2 = when you say “…that in many cases enable you to run your entire backend using Crossbar.io”, you meant “…that in many cases enabled you to run your entire backend within a single Crossbar.io process”
F3 = although container configuration spawns separate processes, it does rely on the process that the router is within
F4 = guest configuration differs from container configuration in that it has no dependency on the router process
facts = [F1, F2, F3, F4]
On Friday, 6 March 2015 06:17:44 UTC-5, Alexander Gödde wrote:
The template shows one way of running a Python component. You can, of course, run application components anywhere, with the only connection with Crossbar.io being the WAMP connection to the router within Crossbar.io.
With the templates, we use the possibility to have Crossbar.io run components. This is a comfort feature, not a requirement in any way.
There are three ways of running Python components using Crossbar.io:
- Side-by-side within the router (same Python as Crossbar.io, using Twisted)
- within a Container worker (same Python as Crossbar.io, using Twisted)
- within a Guest worker (any installed Python runtime, can be asyncio)
For more information see
So your mental model is not wrong in any way - it’s just that Crossbar.io offers additional features that in many cases enable you to run your entire backend using Crossbar.io.
Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:
I’ve decided to go ahead and try to build something with Crossbar. (Hooray!). I’ve been using AutobahnPython (without WAMP) in production for a couple of years. Crossbar seems to offer a heck of a lot, and it has become too tempting to pass up.
The output for “crossbar templates” shows this:
Available Crossbar.io node templates:
default A WAMP router speaking WebSocket plus a static Web server.
hello:python A minimal Python WAMP application hosted in a router and a HTML5 client.
The hello:python description indicates that it is a WAMP application hosted in a router. The description for the default template indicates that it is just a WAMP router (with no application).
My mental model (before embarking on trying Crossbar out) was that I would spin up a router process at a well-known address:port, and then spin up application components as separate processes that utilize the router. The hello:python template embeds the application component right in with the router. But is this the typical (and/or advised) deployment scenario? Or was it just so that the hello example would contain everything in one template?