Proceedings of the IE 2017 International Conference www.conferenceie.ase.ro
CLOUD COMPUTING BASED WEB APPLICATIONS. EXAMPLES AND CONSIDERATIONS ON GOOGLE APPS SCRIPT Dinu AIRINEI The Department of Accounting, Business Information Systems and Statistics, Faculty of Economics and Business Administration (FEAA), “Alexandru Ioan Cuza” University of Iasi (UAIC)
[email protected] Daniel HOMOCIANU The Research Department, FEAA, UAIC
[email protected] Abstract. The ordinary use of the ICT related “cloud” term mostly refers to the use of it for storing common office type files and accessing them with their corresponding remote applications. If considering the operating and processing part, the cloud computing collocation it is more inspired to use. The paper comes after some experiences of the authors in developing small general purpose applications by using the Google’s cloud scripting language put to work behind Google Drive and able to automatically run sequences triggered by different events including time or dynamically deploy them as web applications with a distinctive macro indicative in their URLs. The paper also presents some considerations on processing needs exceeding daily quotas of a single account and not suitable to be solved just by scripting behind a Google form or sheet. Consequently the authors exemplify some sides of the concept of installable and scalable cloud based web application requiring sign in to someone’s account together with authorizations for execution on his cloud drive and meant for real world scenarios in business, education and so on. Keywords: cloud computing, GAS (Google Apps Script), quotas, application scalability JEL classification: C88, O33, Y80 1. Introduction The fashionable term of cloud computing have been studied a lot lately. It uses standardsbased technologies and, as concluded by Michael Gendron [1] after analyzing information proposed by: Gartner, American National Institute of Standards and Technology and Microsoft’s experts, it has required and optional characteristics. From this point of view the required ones are: use of Internet technologies, services-based, scalable and elastic infrastructure, fault tolerant, broad network access, shared resources and metered use, while the optional ones are: metered use with pay as you go, geo-replication, on-demand selfservice and security. When it comes to the service models the practice and the scientific literature give us three well-known categories: Software as a Service (SaaS: e.g. Google Apps), Platform as a Service (PaaS: e.g. Microsoft Azure) and Infrastructure as a Service (IaaS: e.g. Amazon Web Services). Early approaches [2] mentioned only SaaS and utility computing. As provider of cloud computing resources Google also offers many possibilities in terms of development including: the fully managed App Engine platform, its own version of server side Java Script (GAS) and some dedicated application programming interfaces (e.g. Google Maps APIs). In those last two cases the limitation for consumer usage (everyone with standard account) does not mean a trial free of charge access (usually 30 days) but restrictions based on consumed resources which are specific to public clouds (e.g. number of requests per day [3], execution minutes per script or total execution time per day [4], etc.). 64
Proceedings of the IE 2017 International Conference www.conferenceie.ase.ro The idea of having both basic cloud storage and basic cloud processing power for any consumer account although both limited in some ways is something that makes the Google Cloud somehow different from other similar products from current competitors. The paper wants to give some useful ideas concerning the development of cloud computing based web applications by using GAS despite many of its limitations. And the fact that Google gave a sign of improving the permissiveness regarding processing quotas since the end of 2016 was another standing motivation (e.g. GAS triggers total runtime from 60 to 90 minutes / consumer account). 2. GAS based applications including scripting behind Google forms and sheets There are many well-known applications of GAS starting from checking the status of a web site, encrypting all draft e-mails and transmitting them, sending auto confirmation e-mails for Google forms, building add-ons for sheets or docs and even enterprise applications [5].
Figure 1. Querying the Wolfram Alpha knowledge engine by using its dedicated API in a GAS sequence defined behind a Google spreadsheet associated with a Google Form
We have also developed some applications such as: evaluation forms with automatic feedback via e-mail, a dynamic random generator of such evaluation forms (GPS4GEF) [6] fed with IDs of Google Sheet data sources, an add-on (goo.gl/Mv41Xv) for quickly obtaining a high order (specified) polynomial trend function associated to a custom time series, encryption prototypes based on Google forms, a dashboard automatically updated as response to continuous input data (OL2RAM) [7], a real time viewer of dynamic and interactive charts (goo.gl/kaQnW1) inspired by the one of Elsevier [8] but fed with Google Sheets URLs (scientific and business data sources) instead of .csv uploaded files and installable in a Google Drive account, a dynamic generator of interactive .pdf routes (GPS4GISVR) [9] built on the logic of exploiting animation effects when scrolling (presentation mode) thru .pdf pages containing both 2D Google Maps and 3D street shots integrated as images and 65
Proceedings of the IE 2017 International Conference www.conferenceie.ase.ro connected to Street View in each individual point corresponding to a page. Another example of GAS app via a dedicated API is that able to automatically respond to knowledge processing type requests familiar to the users of the Wolfram Alpha computational knowledge engine (fig.1, the source script at goo.gl/K1QUhy was added behind a Google sheet associated to a Google form: goo.gl/wmrc7r because of speed of design reasons). 3. Limitations due to processing quotas and support for more scalable applications For time consuming applications such as those requiring to do a lot of processing (e.g. thousands of requests per day, large volumes of data to deal with, fetching images from URLs, pattern recognition, predictions, etc.), the programming approach must be reconsidered. First of all we can no longer rely on just a single quota (90 minutes / day / consumer account or even 6 hours for other types of accounts) as in the case of an owner of a common and easily designed Google form powered by processing scripts (fig.1).
Figure 2. Running a custom form made in Google Apps Script with support for intensive use thru own quota due to the sign in and cloud install permissions required and granted
In such cases we have succeeded to make the applications more scalable in terms of processing power only as extra time allowed to run on the server side. We did this by avoiding Google Forms which consume only the owner’s quota. Instead we exemplified with a custom defined form (in Google Script only - fig.2, or combined with the use of the .html service) published as a web app accessible by anyone and executed (fig.3) as the user accessing the web app. We have not performed bandwidth tests focusing only on presenting a 66
Proceedings of the IE 2017 International Conference www.conferenceie.ase.ro general example of web app form with (figs.2 and 3) or without (fig.2) support for data persistence, with extra processing power by setting the involvement of the web app user’s own quota (sign in required) and immediate results in browser by using client and server-side event handlers programmatically defined (fig.2, source script at goo.gl/NWGmCJ). We must also consider to: programmatically split the execution into several stages, write and later read processing status markers and permanently refer to the current timestamp to overcome the shortcomings caused by the script runtime quota (usually 6 minutes / execution). When developing in GAS which is accessible thru a web interface and a Google account making it less dependent on the local platform (we successfully used it even on a modest Android based mobile phone - single core 1.0 GHz Cortex-A7 CPU with 512 MB of RAM), we were also aware of the fact that Google might change certain related components (e.g. deprecated methods such as Chart API, new support such as the one for Android add-ons) without prior notifications except updating some on-line support sections (e.g. developers.google.com/apps-script/releases). Under these circumstances synthesized above, we consider tracking GAS updates and doing corresponding sudden changes to applications as being the main drawback of this developing approach. In case a minimum support for data persistence is mandatory we can make use of a Google Sheet (fig.3) shared for edit with anyone authenticated but with a secret ID defined as 44 characters (and an alphabet of at least 64 characters: 26 uppercase, 26 lowercase, 10 digits, hyphen and underscore) in the source script with a special concern for not sharing it (security by obscurity as for any other API IDs - see figs.1, 3). Such basic security could be improved at least by writing encrypted values in cells by using a row level encryption scheme (e.g. a combination of substitutions, permutations, and fast base 64 web safe encoding [10] applied in a variable order depending on a combination of variable and master key) and scheduling backups of this transaction table (bottom of fig.3) by using time-driven triggers (variable time intervals to choose from) associated to another account (additional stable processing quota).
Figure 3. Adding a script section as basic support for data persistence and updating the web app
4. Effective configuration mechanisms and support for collecting data The image below (fig.4) synthesizes two examples of how to uninstall such a cloud based web application as the aforementioned one in case the user has changed his mind concerning the permissions. More than by starting from a message with the corresponding uninstall link 67
Proceedings of the IE 2017 International Conference www.conferenceie.ase.ro (implicit) any user may access the explicit option (Sign-in & security section, connected apps & sites subsection, Generic Form Application) of his Google account (bottom side of fig.4).
Figure 4. Implicit and explicit ways of uninstalling a Google cloud based web app developed in GAS
The uninstalling (fig.4) and especially the installation (fig.2) of such cloud based web applications visually reminds us of the same processes for software products made for the Android operating system by using Google Play Store on mobile devices. Therefore the continuity principle in designing such web apps is respected when thinking of the worldwide spread of mobile devices delivered with the aforementioned products. We have also tested some scenarios of using rough Google Sheets data collectors (fig.3) skipping time consuming joins required when reading data from the tables of a traditional normalized data structure and we have reached some encouraging results. In fact, a script associated to a consumer account was able to verify the value of an attribute (if equal to the “Y” character – Yes and not null) from a total of eight attributes including the timestamp (average of 15 characters per field value) for 10.000 records in less than 900 milliseconds. Moreover, in those collectors every stored record might be put in relation or not to another record or set of records at runtime by using an ID [11] or full URL (additional field) of another data collector of this type (only the default sheet was involved). We consider that and the Google Sheets’ novel versatile Query function [12] being of major impact on applications dealing with shifts from abstract views of data to more detailed ones and vice versa such as Online Analytical Processing tools.
68
Proceedings of the IE 2017 International Conference www.conferenceie.ase.ro 5. Conclusions This paper has a strong connection with topics such as: persistent data, advanced row level security techniques, record to record and record to record set ad-hoc relations, “retry-able” designs, execution time optimization, execution on stages and scalable, elastic and on demand processing power based on cloud computing. The ideas came after some practice with Google products and own or third party APIs. The examples described or at least mentioned ranged from scripting behind Google forms and sheets and more complex designs suitable for cloud based web applications responding to real world scenarios in terms of ease of use, flexibility and security. Consequently the paper contains considerations on a number of advantages and disadvantages of using Google Apps Script and also on scenarios with time consuming processing needs exceeding certain quotas. The paper’ text part and the short links to the source scripts are accompanied by complex and suggestive figures consisting in screen capture parts able to synthesize fully functional examples including advanced options and settings. They were included by the authors to better explain and support theoretical ideas by following the old saying which reminds us that “a picture is worth a thousand words”.
References [1] M. S. Gendron, BI and the Cloud. Strategic Implementation Guide. New Jersey: John Wiley and Sons, 2014, pp.27-30. [2] E. Knorr, (2008, April, 7). What cloud computing really means, InfoWorld [Online]. Available:http://www.infoworld.com/article/2683784/cloud-computing/what-cloudcomputing-really-means.html [3] https://developers.google.com/maps/documentation/geocoding/usage-limits [4] https://developers.google.com/apps-script/guides/services/quotas [5] J. Ferreira, Google Apps Script. Web application development essentials. Sebastopol: O’Reilly, 2014, pp.51-194. [6] D. Homocianu, D. Airinei and F. Dumitriu, “2CASE - Cloud Computing Based Audit Staff Evaluation by Using the GPS4GEF On-Line Prototype”, Journal of Financial Audit, vol.127, no. 7, pp.94-106, July 2014. [7] D. Homocianu and D. Airinei, “On-Line Dynamic Dashboards in Audit Activities”, Journal of Financial Audit, vol.125, no. 5, pp.91-100, May 2015. [8] http://authortools.elsevier.com/interactiveplots/verification [9] D. Homocianu and D. Airinei, D., “GPS4GISVR - General Purpose System for Generating Interactive Street View Routes”, in Proc. The 15th International Conference on Informatics in Economy, Cluj-Napoca, Romania, 2016, pp.1-6. [10] D. Homocianu and D. Airinei, “64B3AC - SYmmetric Crypto-System for Business using the Ascii Alphabet and Algorithm Codes Called in Cascade”, Journal of Economic Computation and Economic Cybernetics Studies and Research, vol. 50, no. 4, December 2016. [11] B. McPherson, Going GAS. Fom VBA to Google Apps Script. Sebastopol: O’Reilly, 2016, pp.129-130 [12] M. Maguire, Google Sheets programming with Google Apps Script. Your guide to building spreadsheet applications in the cloud. Lean Publishing, 2016, pp.1-2
69
