Best practices to manage clientlibs in AEM(Adobe CQ) | Community
Skip to main content
K
krishna_kalyan
Level 2
October 16, 2015
Solved

Best practices to manage clientlibs in AEM(Adobe CQ)

  • October 16, 2015
  • 6 replies
  • 7575 views

Hi,

 

I'm trying to get the best approaches to manage clientlibs in AEM. I have tried the following approaches:

Approach 1)     Created component level client libs for each component under "/apps", included them in the component and a site level clientlibs which are common across all the pages of the site under "/etc/designs/" and included that in the headlibs of a base template. 

This approach makes the code modular and easy to debug.

Drawback: The problem with the above approach is in the webserver "/apps" will be restricted and I'm getting "403 forbidden error" while accessing these component level clientlibs and also there will be multiple calls to get each component level client libs.

Approach 2)     Created component level client libs for each component under "/apps", embeded them in site level client libs  under "/etc/designs" and included this site level client lib in the headlibs of base template.

With this approach only one call will be made to get all the clientlibs.

Drawback: The problem with this approach is that all the component clientlibs are included in each and every page even though that particular component is not included in that page which makes the client libs redundant. If some js code is dependent on a component and if that component is not present in that page then it is throwing js errors.

Approach 3)    Created component level client libs for each component under "/apps", embeded them in site level client libs  under "/etc/designs" and included this site level client lib in the headlibs of base template. Now code in each js file of component client libs are written in a function and this js function is called from the component.

With this approach we can control the js errors as component js will be executed only when the component is included in the page.

Drawback: The problem here is we can't control the naming of those functions across all the components and the code will still be redundant.

Approach 4)    Create client libs for each component under "/apps", now create client libs for each template and embed only those component level client libs in each template where these components are present.

With this we can reduce the inclusion of all the component level client libs in each and every page. 

Drawback: The problem with this approach is we will have so many client libs under "/etc/designs" and if a component is included in multiple templates we need to embed those component level client libs in all the templtes. Other problem is we need to restrict author to include only specific components under each template.

 

Please check out above approaches and give feedback and suggest best practices to mange client libs in AEM.

 

-Thanks in advance

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by JustinEd3

    Hi,

    I would generally suggest following Approach #2. The first drawback you listed (all component clientlibs are included in every page) tends, with some edge case exceptions, to be not as significant as the caching benefit of having users load a large JS file once and then never again until it changes. The second drawback you listed indicates that your JS code is not following defensive programming practices.

    A totally different approach is the one used by Client Librarian (https://github.com/Citytechinc/client-librarian). I can't vouch for this one way or the other, but one of the authors did an interesting presentation on this at Circuit this year. As I wrote above, I tend to think that this kind of thing is overengineering compared with the caching benefits of using a single (or maybe minimal number of is a better way to put it) clientlibs. But if your JS code really can't handle being loaded in a different context, Client Librarian at least offers a way to deal with that.

    Regards,

    Justin

    6 replies

    J
    Adobe Employee
    JustinEd3Adobe EmployeeAccepted solution
    Adobe Employee
    October 16, 2015

    Hi,

    I would generally suggest following Approach #2. The first drawback you listed (all component clientlibs are included in every page) tends, with some edge case exceptions, to be not as significant as the caching benefit of having users load a large JS file once and then never again until it changes. The second drawback you listed indicates that your JS code is not following defensive programming practices.

    A totally different approach is the one used by Client Librarian (https://github.com/Citytechinc/client-librarian). I can't vouch for this one way or the other, but one of the authors did an interesting presentation on this at Circuit this year. As I wrote above, I tend to think that this kind of thing is overengineering compared with the caching benefits of using a single (or maybe minimal number of is a better way to put it) clientlibs. But if your JS code really can't handle being loaded in a different context, Client Librarian at least offers a way to deal with that.

    Regards,

    Justin

      Sham_HC
      Sham_HC
      Level 10
      October 16, 2015

      If it is aem6 I would suggest to use Approach 5 which is [1].

      @Justin:-  I am about to publish an article with example of proxy servlet. Is there any reason you do not prefer it?

      [1]   http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manager.topic.html/forum__5oey-in_5_6_therewasa.html

      J
      Adobe Employee
      JustinEd3Adobe Employee
      Adobe Employee
      October 16, 2015

      @Sham - it isn't that there's anything wrong with the proxy servlet per se, but overall web best practice is to have as few JS (and CSS) includes as is reasonably possible. I usually find that the per-component JS+CSS size is minimal, so there's significant value in *not* loading these individually. Are there exceptions? Definitely - if you have a particularly large or complex piece of code, that would be worthwhile to load separately and selectively, but those are the exceptions, not the rules.

      The other related issue is that when you include clientlibs in components, by which I mean that the cq:includeClientLibrary JSP tag or the Sightly equivelant is actually in your component's code, that leads to loading clientlibs throughout the page. This also is a violation of web best practices which calls for CSS to be loaded in the head and (in general) JS to be loaded just before the </body> tag.

      Sham_HC
      Sham_HC
      Level 10
      October 16, 2015

      Thanks justin. Make sense.

      The article[1] to use proxyservlet aligned w.r.t approach2.  

      [1]   http://aemfaq.blogspot.com/2014/08/manage-clientlibs-in-aem-through.html

      K
      krishna_kalyanAuthor
      Level 2
      October 16, 2015

      Hi Sham,

       I have read the blogpost, if we are going with approach 2 there is no need of using any proxy servlet itself.

      Thanks,

      Kalyan.

       

      Sham HC wrote...

      Thanks justin. Make sense.

      The article[1] to use proxyservlet aligned w.r.t approach2.  

      [1]   http://aemfaq.blogspot.com/2014/08/manage-clientlibs-in-aem-through.html

       

      K
      krishna_kalyanAuthor
      Level 2
      October 16, 2015

      Hi Sham,

       I have read the blogpost, if we are going with approach 2 there is no need of using any proxy servlet itself.

      Thanks,

      Kalyan.

      Terms & ConditionsAccessibility statement

      Loading footer...