Getting Started

#1

Hello all,

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?

0 Likes

#2

Hi Jonathan!

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:

  1. Side-by-side within the router (same Python as Crossbar.io, using Twisted)

  2. within a Container worker (same Python as Crossbar.io, using Twisted)

  3. within a Guest worker (any installed Python runtime, can be asyncio)

For more information see

http://crossbar.io/docs/Router-Components/

http://crossbar.io/docs/Container-Configuration/

http://crossbar.io/docs/Guest-Configuration/

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.

Regards,

Alex

···

Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:

Hello all,

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?

0 Likes

#3

Hello Alexander,

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]

if all(facts):

hooray()

else:

request_clarifications(facts)

Regards,

Jonathan

···

On Friday, 6 March 2015 06:17:44 UTC-5, Alexander Gödde wrote:

Hi Jonathan!

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:

  1. Side-by-side within the router (same Python as Crossbar.io, using Twisted)
  1. within a Container worker (same Python as Crossbar.io, using Twisted)
  1. within a Guest worker (any installed Python runtime, can be asyncio)

For more information see

http://crossbar.io/docs/Router-Components/

http://crossbar.io/docs/Container-Configuration/

http://crossbar.io/docs/Guest-Configuration/

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.

Regards,

Alex

Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:

Hello all,

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?

0 Likes

#4

Hi Jonathan!

F1: You can do that, i.e. use Crossbar.io as a starter wrapper for components. You can also have Crossbar.io start guest workers on the same machine, i.e. start Crossbar.io with a router and all application components which connect to it on the machine.

F2: Sorry, that was too vague. What I meant is: To start your backend, all you do is “start crossbar”, and Crossbar.io takes care of starting up any workers you’ve configured.

F3 + F4: In both cases, there is no direct dependence on the router process, i.e. these are separate processes. They are controller not by the router process, but by the node controller - see http://crossbar.io/docs/Architecture/

Regards,

Alex

···

Am Freitag, 6. März 2015 13:28:25 UTC+1 schrieb Jonathan Dobson:

Hello Alexander,

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]

if all(facts):

hooray()

else:

request_clarifications(facts)

Regards,

Jonathan

On Friday, 6 March 2015 06:17:44 UTC-5, Alexander Gödde wrote:

Hi Jonathan!

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:

  1. Side-by-side within the router (same Python as Crossbar.io, using Twisted)
  1. within a Container worker (same Python as Crossbar.io, using Twisted)
  1. within a Guest worker (any installed Python runtime, can be asyncio)

For more information see

http://crossbar.io/docs/Router-Components/

http://crossbar.io/docs/Container-Configuration/

http://crossbar.io/docs/Guest-Configuration/

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.

Regards,

Alex

Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:

Hello all,

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?

0 Likes

#5

Jonathan,

It took me a few tries to grasp the model as well, sounds like you got it! If you would like to see some experimentation that might save you some time check out my blog post: http://www.pynut.com/?p=36 and autobahn google groups post here: https://groups.google.com/d/msg/autobahnws/0YlRlShCEpE/P4NK41oZ7jcJ

My questions were around how to get a python 3.4 component (for lack of better term, technically crossbar states: Python Components are worker processes spawned by Crossbar.io which directly host application classes written in Python deriving from autobahn.twisted.wamp.ApplicationSession.) that was NOT tied to the crossbar instance running. This was a separate VM running the python 3.4, serving as my web “backend”, or “database access layer” calling into the crossbar.io VM (these could be on the same VM just seperate processes like Alex says in his guest worker example) to handle sending async data back to clients out on the Internet over WAMP (WebSockets).

This is a very scalable feature now that they have published the ability to do shared registrations of “back-end” guest workers running on “n” number of VM’s, esentually making a web farm or cluster from guest worker VM’s and high speed WAMP Crossbar routers connecting all the dots out to clients.

Thoughts?

Dave

0 Likes

#6

Thank you Alex.

···

On Friday, 6 March 2015 08:49:36 UTC-5, Alexander Gödde wrote:

Hi Jonathan!

F1: You can do that, i.e. use Crossbar.io as a starter wrapper for components. You can also have Crossbar.io start guest workers on the same machine, i.e. start Crossbar.io with a router and all application components which connect to it on the machine.

F2: Sorry, that was too vague. What I meant is: To start your backend, all you do is “start crossbar”, and Crossbar.io takes care of starting up any workers you’ve configured.

F3 + F4: In both cases, there is no direct dependence on the router process, i.e. these are separate processes. They are controller not by the router process, but by the node controller - see http://crossbar.io/docs/Architecture/

Regards,

Alex

Am Freitag, 6. März 2015 13:28:25 UTC+1 schrieb Jonathan Dobson:

Hello Alexander,

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]

if all(facts):

hooray()

else:

request_clarifications(facts)

Regards,

Jonathan

On Friday, 6 March 2015 06:17:44 UTC-5, Alexander Gödde wrote:

Hi Jonathan!

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:

  1. Side-by-side within the router (same Python as Crossbar.io, using Twisted)
  1. within a Container worker (same Python as Crossbar.io, using Twisted)
  1. within a Guest worker (any installed Python runtime, can be asyncio)

For more information see

http://crossbar.io/docs/Router-Components/

http://crossbar.io/docs/Container-Configuration/

http://crossbar.io/docs/Guest-Configuration/

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.

Regards,

Alex

Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:

Hello all,

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?

0 Likes

#7

Thanks for the links. What you described is exactly what I am looking for. We’ve got a monolithic app where I work, and we are in the process of splitting it up into smaller micro-services/micro-apps. Crossbar looks almost too good to be true. We have to do this well from the get-go, and prove it out, otherwise we will be dragged back into Monolithium, a violent and dangerous land no sane programmer wants to pass through, let alone live.

I believe the micro-services/apps approach is doable with a bunch of disconnected, independent tools, but the concept count is high, and there are many moving parts.

···

On Friday, 6 March 2015 09:33:39 UTC-5, Dave Thomas wrote:

Jonathan,

It took me a few tries to grasp the model as well, sounds like you got it! If you would like to see some experimentation that might save you some time check out my blog post: http://www.pynut.com/?p=36 and autobahn google groups post here: https://groups.google.com/d/msg/autobahnws/0YlRlShCEpE/P4NK41oZ7jcJ

My questions were around how to get a python 3.4 component (for lack of better term, technically crossbar states: Python Components are worker processes spawned by Crossbar.io which directly host application classes written in Python deriving from autobahn.twisted.wamp.ApplicationSession.) that was NOT tied to the crossbar instance running. This was a separate VM running the python 3.4, serving as my web “backend”, or “database access layer” calling into the crossbar.io VM (these could be on the same VM just seperate processes like Alex says in his guest worker example) to handle sending async data back to clients out on the Internet over WAMP (WebSockets).

This is a very scalable feature now that they have published the ability to do shared registrations of “back-end” guest workers running on “n” number of VM’s, esentually making a web farm or cluster from guest worker VM’s and high speed WAMP Crossbar routers connecting all the dots out to clients.

Thoughts?

Dave

0 Likes

#8

Hello,

New to wamp/crossbar.io, I’m also trying to figure out what is the best way to start with wamp and wanted to know a bit more about guest configuration and how to add new guest workers to an existing application.

Is it enough to add this new guest worker definition to the config.json file ?

Do I have to stop/restart the whole router (crossbar.io) (so all the workers will also restart) or can I start this new worker without restarting the router or the other workers

Tia.

···

On Friday, March 6, 2015 at 2:49:36 PM UTC+1, Alexander Gödde wrote:

Hi Jonathan!

F1: You can do that, i.e. use Crossbar.io as a starter wrapper for components. You can also have Crossbar.io start guest workers on the same machine, i.e. start Crossbar.io with a router and all application components which connect to it on the machine.

F2: Sorry, that was too vague. What I meant is: To start your backend, all you do is “start crossbar”, and Crossbar.io takes care of starting up any workers you’ve configured.

F3 + F4: In both cases, there is no direct dependence on the router process, i.e. these are separate processes. They are controller not by the router process, but by the node controller - see http://crossbar.io/docs/Architecture/

Regards,

Alex

Am Freitag, 6. März 2015 13:28:25 UTC+1 schrieb Jonathan Dobson:

Hello Alexander,

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]

if all(facts):

hooray()

else:

request_clarifications(facts)

Regards,

Jonathan

On Friday, 6 March 2015 06:17:44 UTC-5, Alexander Gödde wrote:

Hi Jonathan!

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:

  1. Side-by-side within the router (same Python as Crossbar.io, using Twisted)
  1. within a Container worker (same Python as Crossbar.io, using Twisted)
  1. within a Guest worker (any installed Python runtime, can be asyncio)

For more information see

http://crossbar.io/docs/Router-Components/

http://crossbar.io/docs/Container-Configuration/

http://crossbar.io/docs/Guest-Configuration/

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.

Regards,

Alex

Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:

Hello all,

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?

0 Likes

#9

Hi Tia!

Workers are configured via the config.json file. Any changes to this require a restart of Crossbar.io to take effect (the configuration is read once only at startup). We’re looking into having a (configurable) automatic restart on changes to the config.json, but this isn’t there yet. There are also the beginnings of a management API for live changes, but this is very much under development and completely undocumented - not worth trying to use as it is.

For the time being, if you want to add/remove components from your application at runtime, you need to run these externally to Crossbar.io.

Regards,

Alex

If you want to add/remove components to your application while the application is running

···

Am Freitag, 13. März 2015 12:01:24 UTC+1 schrieb Rejo:

Hello,

New to wamp/crossbar.io, I’m also trying to figure out what is the best way to start with wamp and wanted to know a bit more about guest configuration and how to add new guest workers to an existing application.

Is it enough to add this new guest worker definition to the config.json file ?

Do I have to stop/restart the whole router (crossbar.io) (so all the workers will also restart) or can I start this new worker without restarting the router or the other workers

Tia.

On Friday, March 6, 2015 at 2:49:36 PM UTC+1, Alexander Gödde wrote:

Hi Jonathan!

F1: You can do that, i.e. use Crossbar.io as a starter wrapper for components. You can also have Crossbar.io start guest workers on the same machine, i.e. start Crossbar.io with a router and all application components which connect to it on the machine.

F2: Sorry, that was too vague. What I meant is: To start your backend, all you do is “start crossbar”, and Crossbar.io takes care of starting up any workers you’ve configured.

F3 + F4: In both cases, there is no direct dependence on the router process, i.e. these are separate processes. They are controller not by the router process, but by the node controller - see http://crossbar.io/docs/Architecture/

Regards,

Alex

Am Freitag, 6. März 2015 13:28:25 UTC+1 schrieb Jonathan Dobson:

Hello Alexander,

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]

if all(facts):

hooray()

else:

request_clarifications(facts)

Regards,

Jonathan

On Friday, 6 March 2015 06:17:44 UTC-5, Alexander Gödde wrote:

Hi Jonathan!

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:

  1. Side-by-side within the router (same Python as Crossbar.io, using Twisted)
  1. within a Container worker (same Python as Crossbar.io, using Twisted)
  1. within a Guest worker (any installed Python runtime, can be asyncio)

For more information see

http://crossbar.io/docs/Router-Components/

http://crossbar.io/docs/Container-Configuration/

http://crossbar.io/docs/Guest-Configuration/

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.

Regards,

Alex

Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:

Hello all,

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?

0 Likes

#10

Thanks Alex,

So it is not (yet?) like supervisord where you can tell supervisorctl to update de configuration and so, start and supervise new components or stop/start/restart components individualy.

In case crossbar would act like supervisord, it would be interesting to be able to split config.json and include all .json files that could be found in a specific directory. Adding a new worker would be as simple as adding the worker’s specific .json file to this config directory. No impact on the global config.json file, so it is easy to add/remove workers in a multi-developpers environment.

···

On Friday, March 13, 2015 at 12:14:26 PM UTC+1, Alexander Gödde wrote:

Hi Tia!

Workers are configured via the config.json file. Any changes to this require a restart of Crossbar.io to take effect (the configuration is read once only at startup). We’re looking into having a (configurable) automatic restart on changes to the config.json, but this isn’t there yet. There are also the beginnings of a management API for live changes, but this is very much under development and completely undocumented - not worth trying to use as it is.

For the time being, if you want to add/remove components from your application at runtime, you need to run these externally to Crossbar.io.

Regards,

Alex

If you want to add/remove components to your application while the application is running

Am Freitag, 13. März 2015 12:01:24 UTC+1 schrieb Rejo:

Hello,

New to wamp/crossbar.io, I’m also trying to figure out what is the best way to start with wamp and wanted to know a bit more about guest configuration and how to add new guest workers to an existing application.

Is it enough to add this new guest worker definition to the config.json file ?

Do I have to stop/restart the whole router (crossbar.io) (so all the workers will also restart) or can I start this new worker without restarting the router or the other workers

Tia.

On Friday, March 6, 2015 at 2:49:36 PM UTC+1, Alexander Gödde wrote:

Hi Jonathan!

F1: You can do that, i.e. use Crossbar.io as a starter wrapper for components. You can also have Crossbar.io start guest workers on the same machine, i.e. start Crossbar.io with a router and all application components which connect to it on the machine.

F2: Sorry, that was too vague. What I meant is: To start your backend, all you do is “start crossbar”, and Crossbar.io takes care of starting up any workers you’ve configured.

F3 + F4: In both cases, there is no direct dependence on the router process, i.e. these are separate processes. They are controller not by the router process, but by the node controller - see http://crossbar.io/docs/Architecture/

Regards,

Alex

Am Freitag, 6. März 2015 13:28:25 UTC+1 schrieb Jonathan Dobson:

Hello Alexander,

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]

if all(facts):

hooray()

else:

request_clarifications(facts)

Regards,

Jonathan

On Friday, 6 March 2015 06:17:44 UTC-5, Alexander Gödde wrote:

Hi Jonathan!

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:

  1. Side-by-side within the router (same Python as Crossbar.io, using Twisted)
  1. within a Container worker (same Python as Crossbar.io, using Twisted)
  1. within a Guest worker (any installed Python runtime, can be asyncio)

For more information see

http://crossbar.io/docs/Router-Components/

http://crossbar.io/docs/Container-Configuration/

http://crossbar.io/docs/Guest-Configuration/

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.

Regards,

Alex

Am Donnerstag, 5. März 2015 16:10:00 UTC+1 schrieb Jonathan Dobson:

Hello all,

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?

0 Likes

#11

Rejo,

I think there is some issue with nomenclature and it took me a while to pick up on it… so for definition:

  1. A guest worker can be any python 2 or 3 endpoint that does something OUTSIDE the router this could be on the SAME system running as a separate process or half way around the world, like Alex says, “with the only connection with Crossbar.io being the WAMP connection to the router”… it’s websockets after all so it doesn’t really matter where “your” code lives except from a latency standpoint. Think of the crossbar router as the hub to a “hub and spoke” network… spokes in this case being ANY endpoint that is trying to talk to ANY OTHER endpoint in the network. If you have an endpoint in the data center that is sitting on the next VM over and has a database on it for backend access, or a user on their mobile phone, those are just two examples of endpoints that can pub/sub or RPC to each other.

  2. A container worker, this must be python 2, on the same machine as the router running from within (I believe) the router but as a separate process, that spawns other processes if using any of the (must use) twisted async IO operations. This is defined in the config of the router in a separate JSON tree, and therefor as Alex points out in this thread requires a process restart toi re-read the config (as of right now, maybe plans to add feature to halt IO and re-read config on router :slight_smile: ???). I see this implementation for testing or vertical systems as it doesn’t scale as nicely as #1 above.

  3. Side-by-side within the router, I believe this is running inside the router process and may (a real guess here) offer the lowest latency for transactions (if you REALLY need things to be fast!)… but this also means things like almost no scalability.

See my post here for getting started and a little more detail… the framework of the router is almost so OPEN it makes it HARD to wrap your head around :slight_smile:

https://groups.google.com/forum/#!msg/autobahnws/0YlRlShCEpE/P4NK41oZ7jcJ

Dave

0 Likes

#12

Hi Dave!

Glad you’re continuing with your exploration of Crossbar.io!

Some clarifications:

  • Guest workers, container workers and side-by-side components are all application components which a started by Crossbar.io based on the config.

  • Both side-by-side components and containers need to be Python 2/Twisted.

  • Guest workers can use any runtime (i.e. any Python, and any other runtime you have installed).

We should make this clearer in the docs - I just had a look, and while it is there (http://crossbar.io/docs/Architecture/, somewhere in the middle) it should really also be explained or at least linked in connection with the actual configuration documentation for these features.

Regards,

Alex

···

Am Mittwoch, 1. April 2015 02:35:56 UTC+2 schrieb Dave Thomas:

Rejo,

I think there is some issue with nomenclature and it took me a while to pick up on it… so for definition:

  1. A guest worker can be any python 2 or 3 endpoint that does something OUTSIDE the router this could be on the SAME system running as a separate process or half way around the world, like Alex says, “with the only connection with Crossbar.io being the WAMP connection to the router”… it’s websockets after all so it doesn’t really matter where “your” code lives except from a latency standpoint. Think of the crossbar router as the hub to a “hub and spoke” network… spokes in this case being ANY endpoint that is trying to talk to ANY OTHER endpoint in the network. If you have an endpoint in the data center that is sitting on the next VM over and has a database on it for backend access, or a user on their mobile phone, those are just two examples of endpoints that can pub/sub or RPC to each other.
  1. A container worker, this must be python 2, on the same machine as the router running from within (I believe) the router but as a separate process, that spawns other processes if using any of the (must use) twisted async IO operations. This is defined in the config of the router in a separate JSON tree, and therefor as Alex points out in this thread requires a process restart toi re-read the config (as of right now, maybe plans to add feature to halt IO and re-read config on router :slight_smile: ???). I see this implementation for testing or vertical systems as it doesn’t scale as nicely as #1 above.
  1. Side-by-side within the router, I believe this is running inside the router process and may (a real guess here) offer the lowest latency for transactions (if you REALLY need things to be fast!)… but this also means things like almost no scalability.

See my post here for getting started and a little more detail… the framework of the router is almost so OPEN it makes it HARD to wrap your head around :slight_smile:

https://groups.google.com/forum/#!msg/autobahnws/0YlRlShCEpE/P4NK41oZ7jcJ

Dave

0 Likes

#13

Thanks Alex! I hadn’t seen that page and that really helps to clear things up!

Does the page need to be updated to reflect the “Planned features”? Seems this is the new shared registrations?

0 Likes

#14

Hi Dave!

Glad I could help.

The shared registrations are not connected to the scale-up/out which the architecture page mentions. This is for router workers, while the shared registrations are for application components.

Regards,

Alex

···

Am Montag, 6. April 2015 23:07:46 UTC+2 schrieb Dave Thomas:

Thanks Alex! I hadn’t seen that page and that really helps to clear things up!

Does the page need to be updated to reflect the “Planned features”? Seems this is the new shared registrations?

0 Likes

#15

Hi Dave,

I had the same sort of difficulties in creating a mental map of this crossbar-business :slight_smile: Thanks for your effort trying to create better docs.

I think you might add a fourth type to your list:

  1. A completely decoupled, or stand-alone, application component that is not started by Crossbar.io. Most obvious example of this type are the javascript front-ends found abundantly in the examples.

Regards,

Roger

···

Op woensdag 1 april 2015 02:35:56 UTC+2 schreef Dave Thomas:

Rejo,

I think there is some issue with nomenclature and it took me a while to pick up on it… so for definition:

  1. A guest worker can be any python 2 or 3 endpoint that does something OUTSIDE the router …
  1. A container worker, this must be python 2,…
  1. Side-by-side within the router,…
0 Likes