Can the Google Calendar API events watch be used without risking to exceed the usage quotas?












1















I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.



The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.



To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.



I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.



My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?










share|improve this question



























    1















    I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.



    The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.



    To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.



    I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.



    My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?










    share|improve this question

























      1












      1








      1








      I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.



      The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.



      To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.



      I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.



      My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?










      share|improve this question














      I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.



      The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.



      To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.



      I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.



      My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?







      google-calendar-api watch quota






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 22 '18 at 8:53









      AlexAlex

      63




      63
























          1 Answer
          1






          active

          oldest

          votes


















          1














          AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:





          • Use push notifications instead of polling.

          • If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).

          • Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.

          • Increase page size to retrieve more data at once by using the maxResults parameter.

          • Update events when they change, avoid re-creating all the events on every sync.

          • Use exponential backoff for error retries.




          Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.






          share|improve this answer
























          • Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.

            – Alex
            Nov 26 '18 at 8:49











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427067%2fcan-the-google-calendar-api-events-watch-be-used-without-risking-to-exceed-the-u%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:





          • Use push notifications instead of polling.

          • If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).

          • Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.

          • Increase page size to retrieve more data at once by using the maxResults parameter.

          • Update events when they change, avoid re-creating all the events on every sync.

          • Use exponential backoff for error retries.




          Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.






          share|improve this answer
























          • Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.

            – Alex
            Nov 26 '18 at 8:49
















          1














          AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:





          • Use push notifications instead of polling.

          • If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).

          • Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.

          • Increase page size to retrieve more data at once by using the maxResults parameter.

          • Update events when they change, avoid re-creating all the events on every sync.

          • Use exponential backoff for error retries.




          Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.






          share|improve this answer
























          • Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.

            – Alex
            Nov 26 '18 at 8:49














          1












          1








          1







          AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:





          • Use push notifications instead of polling.

          • If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).

          • Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.

          • Increase page size to retrieve more data at once by using the maxResults parameter.

          • Update events when they change, avoid re-creating all the events on every sync.

          • Use exponential backoff for error retries.




          Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.






          share|improve this answer













          AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:





          • Use push notifications instead of polling.

          • If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).

          • Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.

          • Increase page size to retrieve more data at once by using the maxResults parameter.

          • Update events when they change, avoid re-creating all the events on every sync.

          • Use exponential backoff for error retries.




          Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 23 '18 at 5:05









          Mr.RebotMr.Rebot

          5,1162757




          5,1162757













          • Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.

            – Alex
            Nov 26 '18 at 8:49



















          • Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.

            – Alex
            Nov 26 '18 at 8:49

















          Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.

          – Alex
          Nov 26 '18 at 8:49





          Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.

          – Alex
          Nov 26 '18 at 8:49


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427067%2fcan-the-google-calendar-api-events-watch-be-used-without-risking-to-exceed-the-u%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Wiesbaden

          Marschland

          Dieringhausen