Forum Discussion

Claudius's avatar
Claudius
Boss
9 years ago

Community API v1 vs v2: Performance comparison

Currently working on moving our components to responsive we found a lot of custom components in our inventory still using sprinkles of v1.

There's a comparison on when to use community API v1 vs v2 here:

https://community.lithium.com/t5/Developer-Documentation/bd-p/dev-doc-portal?section=communityconcepts#v1v2

 

But what about the performance (=processing time) aspect? Is it worth converting custom components with lines like

<#assign dateRegistered = rest("/users/id/${page.context.user.id}/registration_time").value />
<#assign totalPosted = rest("/users/id/${page.context.user.id}/posts/count").value />
<#assign kudosReceived = rest("/users/id/${page.context.user.id}/kudos/received/count").value />

...into v2 code? Would it reduce server load and in sum make the community experience in milliseconds more responsive (as in "responding quicker"?

 

  • VarunGrazitti's avatar
    VarunGrazitti
    Boss
    9 years ago

    Claudius - It actually depends how extensively are the v1 calls being made in those components. I remember we had so many v1 API calls in some of the custom components, which were reduced to less than half when converted to v2. I won't mind a few v1 calls in the components, but if there are too many of these, you should definitely try and get it updated. Also, performance wise, run some tests on the online tools such as https://gtmetrix.com/ or firebug to see what is your current load time. We have been in the process of converting most of the v1 components into v2 because of following reasons:

     

    • Lesser API calls in code as well as BAC's
    • Faster processing
    • Less code to manage

     

    One staggering stat I'd like to share is that after moving to v2, we have reduced our BAC's by as much as 80%. Moreover, it might be just a few milliseconds in the performance tests, but that's all what matters.

    • Claudius's avatar
      Claudius
      Boss
      9 years ago

      Thanks for the detailed answer, VarunGrazitti

      I understand that the move to v2 can often result in consolidating multiple calls into one. But is there an improvement expected even when replacing calls 1 on 1 (e.g. a new v2 call instead of a v1)?


      I guess I'm trying to hone in on the "Faster processing" statement you are making. Even GTMetrix won't allow to measure it directly since the server side of page load is what I'm interested in.

       

      So are v2 calls "processed faster"?

      • VarunGrazitti's avatar
        VarunGrazitti
        Boss
        9 years ago

        This is something which can be measured by the server waiting time in the waterfall model. Run a few tests and compare if your pages have a long waiting time. However, this is something that can be only checked at the page level and not at a component level, so you'll have to narrow down this to check your low performing components. We did not entirely moved all the components to v2, some of our components are still using v1 where we absolutely don't have an available v2 API, but it has improved a lot.

         

        Waiting time corresponds to the processing which is being carried over on the server, so - it might definitely be worth exploring.

  • ttadej's avatar
    ttadej
    Advisor
    7 years ago

    Would also like to know if simple calls like this:

      <#local threadRepliesCountQuery = "SELECT count(*) FROM messages WHERE parent.id = '${threadId!}'" />
  <#local threadRepliesCount = rest(API_VERSION, "/search?q=" + threadRepliesCountQuery?url).data.count!0 />

    versus this

    <#local threadRepliesCount = rest("/messages/id/${(threadId)!}/replies/direct/count").value!?number />

    are any different in terms of performance or if one is recommended over the other. Sometimes the brevity of v1 is nice.