Client side Event bus

Jiri Kremser jkremser at redhat.com
Tue Oct 9 11:28:48 UTC 2012


The increase of footprint holds also for compressed and/or unobfuscated JS (bellow is the sizes of the whole directory war/org.rhq.enterprise.gui.coregui.CoreGUI, including *.gwt.rpc ie GWT serialization policy files).

current | current-obf | current-obf-gz  x  errai | errai-obf | errai-obf-gz
----------------------------------------------------------------------
40.8      12.3            3.0               62.7     55.8       4.6

The largest file (.cache.html) has 752 kB gzipped and obfuscated for errai it is 1.5 MB.

> Is there not any way to reduce this?
I don't think so, but theoretically, we can use the code splitting from pure GWT https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting, but I am not sure if it works with SmartGWT. SmartGWT library modules located in war/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules are very large as well: 
ISC_Grids.js 747 kB
ISC_Core.js 696 kB
ISC_Forms.js 629 kB
...
the whole directory = 7.5 megs
Here the SmartGWT JS libraries are not obfuscated even if the project is compiled with OBF flag, so here we could make some improvements. I haven't found anything about this though.

> Can you push the branch so we can check it out?
pushed to jkremser/errai-integration

JK


----- Original Message -----
From: "mike thompson" <mithomps at redhat.com>
To: rhq-devel at lists.fedorahosted.org
Sent: Tuesday, October 9, 2012 5:43:21 AM
Subject: Re: Client side Event bus

Jirka this is good research,

The transparent eventing between client and server is a very desirable behavior (especially via CDI). Pub/sub via javascript client(GWT) to java backend would definitely enhance the user experience as notifications and other pushes would become available on instantaneously.

I'm quite surprised by the large footprint (64% increase) as we already have the largest javascript application I have ever seen. I'm assuming these figures are uncompressed. What is the gzipped number?  [ I know that we are around 700kb gzipped and obfuscated; we pay a high price for stack traces.]  Is there not any way to reduce this? Why is the reason this is so large (especially when smartgwt wraps native javascript libs? Maybe the Errai guys can address this as it directly effects their/our technology. Out of curiosity what is the GWT OBF size? And the last question: Can you push the branch so we can check it out?



On Oct 5, 2012, at 6:11 AM, Jiri Kremser <jkremser at redhat.com> wrote:

> Hi, 
>  I was playing with Errai lately and I was able to integrate it with RHQ, here are my 2 cents.
> 
> what we would get:
> ------------------
> * CDI, once the migration to as7 is ready, there will be same technology used on back-end and front-end. CDI events supports loosely coupled components removing the direct dependencies and DI itself may allow for easier testing.
> 
> * Server push, errai bus allows for sending the events "across the wire" from client side to server side and vice-versa. This could significantly improve the responsiveness of UI (instead of manual polling by pressing the refresh button).
> Following Ajax push technologies are supported by Errai:
>  -short/long polling
>  -web socket: netty (side channeling)
>               as7.1.2 (experimental)
>  Technology should be autoselected considering the fallbacks if not supported.
> 
> * they are going to support super dev mode
> 
> * from version 2.1 they want to support a subset of JPA utilizing the browser's local storage. In theory it could be used for storing user prefs on client with the same code as now serves for storing it on the server side. Depending on how large subset it is.
> 
> * they provide their own solution for building the UI, I haven't looked how much it is compatible with SmartGWT though.
> 
> 
> what we would lose:
> -------------------------------------
> * the footprint is bigger: 
>  -Server side libs: (current x Errai) 15.9 MB x 24.9 MB (63% increase)
>  -JS (1 locale, 1 browser): 40.8 MB x 63.6 MB (64% increase)
> 
> * compile time (1 locale, 1 browser, 4 worker threads on my tp520): ~2:05s x ~1:35s (31% increase)
> 
> * -xmx=1024M is not enough for GWT compiler, 2048M works ok
> 
> 
> To sum it up, I am +1 on integrating it, but it is a big step and there could be some performance issues. Please respond with your thoughts. Unfortunately, SmartGWT doesn't allow for code splitting, at least for the SmartGWT library itself, and there is one big file with all the javascript code making the users accessing from mobile devices unhappy. (RHQ Pocket solves this for tablets.)
> 
> 
> JK
> 
> ----- Original Message -----
> From: "Lukas Krejci" <lkrejci at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Tuesday, July 31, 2012 10:15:51 PM
> Subject: Re: Server side Event bus
> 
> While polling, etc. are nice concepts that are quite easy to grasp and 
> implement, I'd very much like to see some sophisticated event bus solution 
> employed in RHQ (spanning the server and clients).
> 
> We might not see the possibilities or use cases right now but tying ourselves 
> to a more "primitive" technology (that, after all, the event buses build upon) 
> would later require us to invest much more time into refactoring/restructuring 
> the code.
> 
> We already discussed the deficiencies of our GUI, which we ran into by choosing 
> an obsolete development model (GWT pushes the MVP style of development but we 
> chose swing-like approach, even though we knew about its scalability 
> problems). Let's try and pick carefully this time.
> 
> 
> On Tuesday, July 31, 2012 15:45:15 John Mazzitelli wrote:
>>> Nothing really specific ; it could even be a part of the UI that just
>>> polls some generic API every second and then informs other parts in the
>>> UI.
>> 
>> This is how I implemented that fast prototype I did with the UI messages
>> coming from the agent. Used polling.
>>> Perhaps GWT or SmartGWT also offers something similar out of the box
>> 
>> There is the concept of a GWT timer. Just something that gets triggered
>> after N milliseconds. You can implement a simple polling mechanism using
>> that and have it continually poll the server. This is what Errai helps with
>> - IIUC, Errai avoids the need to continually poll, since it involves
>> pushing from server to gwt client. But we don't currently integrate with
>> Errai as we all know. _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

_______________________________________________
rhq-devel mailing list
rhq-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list