4 ms·

I haven't actually tried it out yet (about to) , but just by reading the instructions on deploying, it looks like you stage your code in a GCS bucket or on a Gi

by waprin 11y ago

I haven't actually tried it out yet (about to) , but just by reading the instructions on deploying, it looks like you stage your code in a GCS bucket or on a Git repository (Google Cloud Source), so I think your local data would refer to any files in that bucket/repository along with your code. *edit note: looks like you can definitely add more files via the package.json and import them as node modules, but I wouldn't rely on reading and writing from the file system. As for persistency, if it's just Javascript code you can install node modules to accomplish what you want including talking to those cloud APIs. Unfortunately Bigtable might be the exception since I'm not sure if there's a good nodejs client yet (Bigtable only supports gRPC, not REST), but you could use Cloud Datastore instead. Firebase will also be a very popular choice for persistence. Cloud Functions naturally complements Firebase to complete Backend-as-a-Service. The hope of Firebase is you don't need a server at all, but sometimes you have logic that really doesn't belong on a client (background jobs, "master" logic). Cloud Functions can fill in those gaps. Firebase: https://www.firebase.com/ https://www.firebase.com/ hand-rolled clients nodejs clients for google cloud apis: https://github.com/GoogleCloudPlatform/gcloud-node https://github.com/GoogleCloudPlatform/gcloud-node auto-generated nodejs clients for google apis: https://github.com/google/google-api-nodejs-client https://github.com/google/google-api-nodejs-client disclosure: work for GCP

planetjones 11y ago
So the local data comment implies the file system is writable? Or is it read only? After a bad experience with Google cloud end points I think I'll give this a mess - especially as Amazon have (what at first glance) seems a much mature and feature complete offering with lambda. I wasn't aware of those libraries for accessing Google cloud sql - so thanks for those.
- waprin 11y ago
  I agree the docs could use some improvements. After playing around with it, I'm not sure if the filesystem works, which makes sense given you just have a bucket or repo underneath and the code can be called at unpredictable times. You can, however, add additional javascript files via the package.json and import them, so if you can express your data as JSON or base64, you're good to go. Maybe there is a way to add other types of resources via the package.json but I haven't figured it out yet. Generally you would interact with Cloud SQL using a regular node MySQL library, since it's just managed MySQL. The API would only be used to automate creating and setting up the CloudSQL instance.

by waprin 11y ago

planetjones 11y ago

So the local data comment implies the file system is writable? Or is it read only? After a bad experience with Google cloud end points I think I'll give this a mess - especially as Amazon have (what at first glance) seems a much mature and feature complete offering with lambda. I wasn't aware of those libraries for accessing Google cloud sql - so thanks for those.

waprin 11y ago
I agree the docs could use some improvements. After playing around with it, I'm not sure if the filesystem works, which makes sense given you just have a bucket or repo underneath and the code can be called at unpredictable times. You can, however, add additional javascript files via the package.json and import them, so if you can express your data as JSON or base64, you're good to go. Maybe there is a way to add other types of resources via the package.json but I haven't figured it out yet. Generally you would interact with Cloud SQL using a regular node MySQL library, since it's just managed MySQL. The API would only be used to automate creating and setting up the CloudSQL instance.