Developing a Zabbix ExtJS frontend: Part Two

After quite lots of work, I’ve now a basic editing workflow done. As I’m using RESTful methods (due to the lack of a JSON-RPC on ExtJS), I’ve written a proxy which eats RESTful methods on the ExtJS side and proxies that to JSON-RPC for Zabbix.

Honestly, this doesn’t sound pretty amazing, but was necessary to work around one limitation of the Zabbix API: Pagination. This is an emulated pagination, which processes a big result set coming from the Zabbix API, counts the records and then applies a simple array_chunk() on the result. That way, the amount of data transmitted to the client is kept at a minimum.

Regarding the amount of data transmitted: I don’t filter individual fields of each record, even if much space is wasted. This is for two reasons:

  • Performance. Even if I could remove 50% of the fields transmitted, the CPU time (and of course, development manpower) wasted would probably be more than simply transmitting the data to the client. Most Zabbix users are on corporate networks, and even people who are using Zabbix remotely often have DSL connections. Sorry for all GPRS users, but a Zabbix Sencha Touch Frontend is not even planned.
  • Object Model. As the ExtJS frontend is using models, I never know when I need which data. So it’s better to transmit all properties, which saves headaches.

That brings us to a new topic:

How to handle relations for reading and writing objects

When writing a PHP frontend, things are pretty easy: You can write very specific SQL queries, and if you are missing data, you can simply load it prior displaying the page.

When implementing remote frontends, things are a bit worse: Think of each SQL query as a request to the server. On a LAN connection, things aren’t that bad: On my development environment, queries take 20-100ms to complete, so users even won’t notice that something is being loaded. Things are different on remote connections; with requests taking an unpredictable amount of time, one wants to reduce requests to the server to an absolute minimum.

I’ll make an example using templates:¬†When I load a template, I simply request the linked templates, macros etc when loading the template. No problem here.

But the user will eventually come to a point where he needs to add additional templates or macros, which aren’t transmitted. I basically have two options here:

Keep a cache of templates on the client.

I’ve used that in the first place on PartKeepr, but with mediocre success. The advantage was that data was immediately available. The biggest disadvantage was when somebody else added something; that required the ExtJS store to load all entities in a timed interval. And often it was confusing because there was no indication when a reload appears.

This method could probably be improved by creating a checksum and only asking the server if the checksum was changed, so the client would know to reload the data. However, I don’t feel too comfortable with that approach, and lately I’m rewriting things on PartKeepr to avoid that.

Load templates on demand.

This could happen using a specific kind of drop down or even grids, complete with filtering and pagination. While this might create quite some requests on-demand, it works better than caching, because the current data is available and not a cached copy of it.

Conclusion

Data handling in the world of AJAX applications is not easy, especially if you write a full-blown AJAX frontend where you have no page reloading at all. You have to decide carefully which data with which relations you really need, and which data you better load on demand.

Add Comment Register



Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">