Crossbar.io, future focus ...

#1

Hi,

I just wanted to make a few comments about what I’m seeing in terms of people’s perception of what crossbar “is” (in reference to the Crossbar.io home page)

There seems to be a heavy focus on;

  • Driving interactive widgets
  • IoT

Although (a) and (b) initially attracted me, and indeed that’s what I started using crossbar for, it’s not really what I’m now using it for. I’ve found it makes rather a good platform for microservices based SPA’s, and now I’m essentially using crossbar for literally “everything”. Although I may be tempted to run it behind a caching service of some sort for off-loading static content on high volume sites, I’m mostly using it as a replacement for NGINX and everything I previously ran behind NGINX. (i.e. FastCGI etc)

In practice, I load an initial page/JS using the Flask component of Crossbar, and at the same time authenticate a session against a websocket connection as a “guest” user.

Then everything else on the site is a websocket / crossbar load, not only for dynamic widgets, but for “all” content.

  • this works “very” well, giving a dynamic website with all the ‘features’ associated with the Crossbar model.

  • it also means you have a completely consistent model for all scripting, database work etc.

By only ever loading ONE page via HTTP, you can keep the Crossbar / websocket connection open all the time, which makes the application fast and very responsive.

In practice the code looks something like this (this is working code but incomplete / without complete context);

In the main HTML file;

(headers, JS, CSS, etc …)
(common header)

(common footer)

``

Then a JS snippet;

load = function(target,tag)
{
var good = function(data) {
$(’#’+tag).html(data.html);
};
var fail = function(data) {
console.log("Failed to load "+target);
}
session.call(target,[{}],{},{disclose_me:true}).then(good,fail);
}

``

And a sample of the backend Python;

@wamp.register(u’app.demo.page’)
def app_demo_page(self,params,details):
“”" return a processed Jinja2 template “”"
tmpl = self.env.get_template(“demopage.j2.html”)
if not tmpl: return { ‘html’:‘Missing template’ }
return { ‘html’:tmpl.render({}) }

``

So to switch pages within an application, when someone clicks on a link or tab, all you would do is;

<a href="javascript:load(‘app.demo.page’,‘main-content’)

``

And you can have a new page without losing your Websocket connection(s). (or for that matter, having to reload all your JS, CSS etc …)

Anyway, my point is that Crossbar makes a “great” dynamic web development framework and after using this to write some fairly hairy stuff, it makes traditional PHP solutions laughable …

It wouldn’t hurt to make more of this type of use-case on the Home page … if I have to tell someone “it’s not ‘just’ for driving widgets” one more time … :wink:

0 Likes

#2

Hi Gareth!

First of all thanks for the kind words - and for sharing a different way of using Crossbar.io! We ourselves have only used Crossbar.io with “traditional” SPAs, i.e. where all the content gets loaded initially and is then only displayed/hidden/mutated based on WAMP messages, so what you do is new and interesting to me.

I also get the promotion angle - Crossbar.io is a powerful tool and we should show more ways of using it. (I’ve added an issue for this - https://github.com/crossbario/crossbarwww/issues/86)

Could you maybe spare some time to help us in doing so? A quick write-up of what you are doing (a bit more detail than you’ve provided so far), pointing out some of the benefits this brings, would be great to have, e.g. as part of the documentation. (I daren’t dream of a minimal working example for crossbarexamples.)

Thanks for sharing this and we’ll keep this in the back of our head when next working on the Crossbar.io landing page!

Regards,

Alex

···

Am Samstag, 21. November 2015 03:25:02 UTC+1 schrieb Gareth Bult:

Hi,

I just wanted to make a few comments about what I’m seeing in terms of people’s perception of what crossbar “is” (in reference to the Crossbar.io home page)

There seems to be a heavy focus on;

  • Driving interactive widgets
  • IoT

Although (a) and (b) initially attracted me, and indeed that’s what I started using crossbar for, it’s not really what I’m now using it for. I’ve found it makes rather a good platform for microservices based SPA’s, and now I’m essentially using crossbar for literally “everything”. Although I may be tempted to run it behind a caching service of some sort for off-loading static content on high volume sites, I’m mostly using it as a replacement for NGINX and everything I previously ran behind NGINX. (i.e. FastCGI etc)

In practice, I load an initial page/JS using the Flask component of Crossbar, and at the same time authenticate a session against a websocket connection as a “guest” user.

Then everything else on the site is a websocket / crossbar load, not only for dynamic widgets, but for “all” content.

  • this works “very” well, giving a dynamic website with all the ‘features’ associated with the Crossbar model.
  • it also means you have a completely consistent model for all scripting, database work etc.

By only ever loading ONE page via HTTP, you can keep the Crossbar / websocket connection open all the time, which makes the application fast and very responsive.

In practice the code looks something like this (this is working code but incomplete / without complete context);

In the main HTML file;

(headers, JS, CSS, etc …)
(common header)

(common footer)

``

Then a JS snippet;

load = function(target,tag)
{
var good = function(data) {
$(’#’+tag).html(data.html);
};
var fail = function(data) {
console.log("Failed to load "+target);
}
session.call(target,[{}],{},{disclose_me:true}).then(good,fail);
}

``

And a sample of the backend Python;

@wamp.register(u’app.demo.page’)
def app_demo_page(self,params,details):
“”" return a processed Jinja2 template “”"
tmpl = self.env.get_template(“demopage.j2.html”)
if not tmpl: return { ‘html’:‘Missing template’ }
return { ‘html’:tmpl.render({}) }

``

So to switch pages within an application, when someone clicks on a link or tab, all you would do is;

<a href="javascript:load(‘app.demo.page’,‘main-content’)

``

And you can have a new page without losing your Websocket connection(s). (or for that matter, having to reload all your JS, CSS etc …)

Anyway, my point is that Crossbar makes a “great” dynamic web development framework and after using this to write some fairly hairy stuff, it makes traditional PHP solutions laughable …

It wouldn’t hurt to make more of this type of use-case on the Home page … if I have to tell someone “it’s not ‘just’ for driving widgets” one more time … :wink:

0 Likes

#3

Hi Alex,

Ahh, it hadn’t occurred to me that you guys wouldn’t be doing this, I’d sort of assumed you had other reasons to focus elsewhere … so … the way to go is probably a worked example. I will try to do something over the next week or so, to make it worthwhile I’m going to need to include some of my library code for handling authentication, logins etc.

Benefits … well, once you stop and think about it, there’s a paradigm shift to be had in terms of performance and general user experience.

The main reason local applications win (when they win) over web based applications, is usually performance and UI smoothness, local apps stick up a screen then update it, they don’t continually transition from page to page. At a technical level, during this transition they don’t have to reload large blocks (albeit they may be cached) of CSS and JSS and reinitialise JS engines with new contexts. You may not see this difference on powerful new workstations, but you definitely see the difference on lower-end devices and shared / Terminal Server platforms.

So … if you can do away with page transitions, there really is very little difference between local apps and web based apps … with the possible exception that UI work is somewhat easier in HTML/CSS than it is (generally) at a native level. Not only that, but in the context of Crossbar, page transitions mean you need to drop and re-establish any existing Websocket connections … do away with page transitions and all of a sudden things get a whole lot faster and more efficient because you open a websocket connection once and (effectively) it persists across different pages. (I’ve seen some documentation on the site about trying to maintain websockets over page transitions - using this method, all that messing around becomes obsolete)

Going one stage further, when you load a page via the mechanism I described, you’re effectively loading based on a topic … which can come from any application connected to crossbar, so you immediately get the ability to easily share pages (and other resources) between sites (or online applications) … and this sharing is done “behind” crossbar, the browser always thinks it’s accessing the same site.

This was one of the appealing features about chaining Crossbar’s, the ability (effectively) to natively load components and pages from (effectively) other sites.

In summary, I think that all you really need to say is;

  • Makes websockets persistent over page transitions
  • Negates the need to reload or re-address either JS or CSS on page transitions
  • Faster / less latency than HTTP connections (no socket open/closed required)
    And I think (!) that pretty much makes a case for it …

Then of course, when you invariably do come to use a dynamic widget, or want to recover information from a Pi, well, the framework is already there … (!)

0 Likes

#4

Hi Alex, Ok, 'tis done!

The code is here; https://github.com/oddjobz/ionman

The demo site is currently running on a dedicated VM here; https://crossbardemo.linux.uk:8443

Just for good measure I included a little bootstrap styling and some login/out/session functionality.

  • what’s running on the VM is what’s in the Git repo.
0 Likes