Installed apps vs. Web apps in Google Cloud Platform (GCP)
Tags: serverless, webdev, googlecloud
Published: 2022-01-15 22:31:12

### **<u>Intro</u>**

Google glass, Google assistant, Google Cloud, not mentioning Google Google Workspace offered Google Drive with its related services like Google Docs, Sheets, Slides, etc.  just like people tend to say – Google is everywhere . Although Google is everything not everything is perfect & that's the documentation they provide , although I noticed they are already working on it (_maybe someone's feedback on docs been worth the time_) , they even published live docs on a new re-furbished PWA series [check it out](https://web.dev/learn/pwa/) . I could talk and talk, although my intensions are very simple : I am building external application that will utilize some GCP provided service APIs . The problem is that documentation does not clearly define difference between **Installed apps** & **Web Apps** . Luckily a few opened issues on GitHub, not mentioning hours of patience reading on developers.google , in my opinion, averagely organized docs (at the time of writing) , I've managed to demystify the following :

### **<u>Installed apps</u>**

- **Service-to-Service** using service account : none of End-user (_human like me & you_) interactions intended , the application you build impersonates End-user maintaining only two parties . Such OAuth 2.0 flow called 2LO (two-legged flow)

- **Server-side** within user-account : this is three-legged (3LO) OAuth 2.0 flow that encapsulates three parties i.e.: a) End-user which delegates one's consent for the client , b) the client (your application) that talks with c) Google services provided APIs on behalf of End-user's consent given . 

---

### **<u>Web apps</u>**

- Apps Scripts deployed within Google Cloud (JavaScript application whereas your application is divided into : a) Front-End on your machine & b) the Back-end on Google Cloud , idiomatically said – within Apps Script service environment [[see this hotspot.js as for practical example](https://github.com/projektorius96/hotspot.js)])

> NOTE : It can be a scenario your **Web app** will be required to use 3LO grant (flow) . In such scenario you would be required to switch your Default GCP Project to Standard one explicitly targeting specified **Project's ID** to Apps Scripts codebase ([steps 2-4 to follow](https://developers.google.com/apps-script/api/quickstart/target-script#step_2_switch_to_a_user-managed_google_cloud_platform_project)) . 
**TIP** : It's good practice to switch before taking any development actions, as switching to Standard for development later may have – "[side effects](https://developers.google.com/apps-script/guides/cloud-platform-projects#switching_to_a_different_standard_gcp_project)]" .
**FINALLY** : there are aplenty other reasons why to switch ([read the list](https://developers.google.com/apps-script/guides/cloud-platform-projects#when_standard_gcp_projects_are_required))  

---

### **<u>To recap</u>**

Default to Standard , including whether or not to utilize service-account may be found daunting experience, that's I made this table to conclude everything to said above :

| **Default** | vs.| **Standard** |
| --- |:---:| ---:|
|2LO with user-account (_e.g. Web app with**out** consent screen_)|...|3LO with user-account (_e.g. Server-side as Web app with consent screen_)|
|...|...|2LO with service-account (_e.g. Service-to-Service with**out** consent screen_)|

### **<u>Final notes</u>**

You can probably guess I've already had some basic experience with Web Apps , the answer is correct, I had ! When it came about **NOT** Web Apps, say Server-side application that would be exploited by other End-users (_e.g. developer building application for some company_), which is not a type of application (client) I am building personally , rather then that, Service-to-Service with service-account is a way to go ! Service account help you avoid End-user (human) involvement which means you don't need any consent screen configured – that's basically what 2LO flow is all about – service-account impersonates End-user on its own (managing its own data rather than End-user's) , resulting into involvement of two parties only i.e.: application (client) you building & Google's service-account as identity for protected resources .

---
<u>In case you'd be concerned..:</u>

[Please support my bug issued on Drive API for Node.js](https://github.com/googleapis/google-api-nodejs-client/issues/2899)   

---

<u>References</u>

- [*legacy (older)](https://github.com/googleapis/google-cloud-node)
- [**present (newer)](https://github.com/googleapis/google-api-nodejs-client)

> **NOTE** : *currently experimenting with legacy as it provided with larger list of GCP services supported APIs

---

If anything to add, please leave a comment in the comment section below . Thanks & see you in the next one !