The Magento / Joomla! bridge is created through a Joomla! component called MageBridge, which contacts through its own API a MageBridge extension on the Magento side. This API is based on JSON, and behaves differently from the SOAP or XML-RPC API of Magento itself. The main reason for this is that MageBridge creates its own entry-point to Magento to simulate a browser request, while the Magento API does not allow for this to happen. That said, every Magento API-request can also be made through the MageBridge API.

One single request

Unlike other bridging solutions MageBridge combines all API-requests into one single HTTP-request which is sent from Joomla! to Magento. To give you a picture with this, imagine a Joomla! page which shows the Magento webshop in the component-area (1 block-request), but also shows modules containing the shopping cart and the most popular tags (2 block-requests) and a menu-like listing of Magento categories (1 block-request). This sums up as 4 different API-requests, but making 4 different HTTP-requests would also mean initializing Magento 4 different times.

Instead MageBridge first registers all API-requests, bundles them and sends all requests to the other side of the API. The weird thing here is that this hooks into the Joomla! bootstrap procedure, during which modules are initialized later than the component. Because the main initialization of the bridge is being done within the component, the content of the modules are prefetched as soon as things are being dispatched to the component.

The only thing that doesn't fit into this is the concept of plugins. Luckily enough there are not that many cases that multiple plugin-calls are made in a single page-request. For instance, when using authentication plugins, after authentication Joomla! redirects to a new page. So MageBridge just builds and sends the API-request through HTTP as soon as the authentication plugin is called.

When calling the search-plugin, the plugin initializes the bridge and during this all modules are fetched again. And at this time the MageBridge component is not called, because Joomla! just handles one component for each page. Great.

In the end, we can pretty safely say that in almost all cases just a single HTTP-request is made to call the MageBridge API.

Caching

MageBridge tries to cache some data, but because many pages are still in need of at least one API-call (for instance the shopping cart should NEVER be cached), not caching anything is not too expensive. Still, caching is goooood. If the bridge needs to fetch less data, it will save a bit of bandwidth.

MageBridge differentiates in two different types of API-content: Ready-to-go HTML-blocks fetched from Magento and data-structures (arrays for instance) most commonly fetched from the MageBridge API-resources. The last kind of API-content is always fetched with full consciousness, so those type of resources could be cached easily after thorough testing.

But HTML-blocks could be either modules or the component. While modules could be considered fairly static, the component area is filled with HTML-code based on the current request of the user, and could thus contain anything - caching at this point is very dangerous.

Caching is ment to increase performance. We recommend performance tuning in different ways, for instance turning on the cache in Magento, or configuring both Magento and Joomla! on the same webserver. MageBridge customers get access to various resources that help with tweaking the performance.