vault backup: 2024-05-04 00:04:33

.obsidian/workspace.json

@@ -170,7 +170,8 @@
       }
     ],
     "direction": "horizontal",
-    "width": 300
+    "width": 300,
+    "collapsed": true
   },
   "left-ribbon": {
     "hiddenItems": {
@@ -183,7 +184,7 @@
       "audio-recorder:Start/stop recording": false
     }
   },
-  "active": "2c0d9f492abf6a7e",
+  "active": "61f95828c4c1ff87",
   "lastOpenFiles": [
     "Android App.md",
     "Cloud Infra.md",

Cloud Infra.md

@@ -23,4 +23,6 @@
 	* 400000 GB-seconds
 	* 200000 GHz-seconds
 	* 5GB outbound (non-Google outbound)
-* 1M requests/mo @ 600ms runtime = $6.15/mo
+* 1M requests/mo @ 600ms runtime = $6.15/mo
+# Decisions
+5/3/2024 - [This blog post](https://cloud.google.com/blog/products/serverless/cloud-run-vs-cloud-functions-for-serverless) has a good analysis of Cloud Run vs. Cloud Functions. App Engine seems a bit more restrictive than I would want, since it has to be in one of their more supported runtimes. With the operations the app needs to make, Cloud Functions/Lambdas seems to be a good first step. Parts of the code should be written to be modular enough to convert from Cloud Functions to Cloud Run (i.e. logic in business layer, called from different entrypoints). It could even turn out that some stuff is good to leave in Cloud Functions while other more frequent things should be moved to Cloud Run/some other framework.