Comment by TheAceOfHearts | Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

Parent Full thread

So, considering that it's beta, where should I expect rough edges? Is there any list that shows what's missing to go from beta to full production? I'm actually really interested in trying this out, but I want to know what potential issues I should expect to deal with.

Something I found really awesome about Google's services is that they provide fake local implementations that you can run from the CLI. This means that you can run tests without having to hit the outside world!

Somewhat related to that, if you're using S3, check out s3rver [0]. It's a node implementation of fake-s3 [1], which is a local implementation of S3 that you can use during development and testing.

Looking through the examples, I'm confused about the deployment strategy for SPAs. Looking at the webpack example [2], you build the frontend app every time the server runs? That's REALLY slow for any reasonably sized SPA :(. It means you generate a new build each time the server restarts, and for something like node that's really common. (AFAIK, the suggested strategy is to just let it crash and restart quickly.) But it also means that you might have multiple servers running different version of your dependencies (since there's no shrinkwrap). Even worse, if you're running multiple servers with slightly different dependencies, it might also mean that you'll end up building slightly different versions of your SPA in every server for any given release! I'd love to see an example where you build and tag the SPA in a single place, and you make sure all the servers are serving the same bundled code.

[0] https://github.com/jamhall/s3rver

[1] https://github.com/jubos/fake-s3

[2] https://github.com/GoogleCloudPlatform/nodejs-docs-samples/b...

In that example we don't need to run the webpack build inside the Docker image when the container is started. There are multiple points in the application deployment lifecycle where a webpack build could be performed.

When you deploy with the gcloud cli a Docker image will be packaged for you and and deployed. You could easily run a webpack build before the image is packaged so the built files get packaged as well, or extend the image with your own Dockerfile to customize the Docker steps, or build the image yourself locally and deploy your already built image, etc...

On regular (non-Managed VM) App Engine, developers are encouraged (but not required) to access services such as Datastore or Mail via App Engine specific APIs. The SDK includes a Development Server that emulates these APIs locally for rapid development.

The Node.js runtime on App Engine Managed VMs encourages you to write against public APIs for Cloud Platform (and other) services - including the public Datastore API, which means your code on Managed VMs is written similarly to how you might write it anywhere else. As such, there's no limit to the potential APIs you might want to emulate.

The gcloud CLI tool does early support for emulating two of the more popular Cloud Platform APIs used by Managed VMs customers, and we hope to add more - you can read more in [1]. In this way you can locally emulate services when writing code that talks to them, independent of the platform you choose to deploy too.

As to builds, your application is re-built at deploy time (not run-time) as a Docker image, cached, and distributed out to new instances as needed. As with all Docker builds it is hermetic and so any code running is the same across all instances for a given version.

(Disclaimer: I work on Google Cloud Platform).

[1] https://cloud.google.com/sdk/gcloud/reference/beta/emulators...

> Looking at the webpack example [2], you build the frontend app every time the server runs? That's REALLY slow for any reasonably sized SPA

Of course, the alternative is to commit your built/minified frontend code to the repo, but that's easy & doesn't really require an example.

I know the conventional wisdom is "never commit compiled code" but a lot of the reasoning behind that idea doesn't really apply to JS built for the browser. FWIW my usual setup is to have a dev server which rebuilds the frontend SPA like this on every re-deploy/restart - but for production releases, I build locally into a `build` directory and commit it to my repo, and the production server only serves code from `build`. That way I don't have to build on every commit, just when I'm putting new code in prod.

This is my understanding about Google Cloud services;

  - Alpha means sub par quality / rough edges / unresolved issues.
  - Beta means fairly stable but no SLA, no guarantees from Google.

So I'd guess it's fine to use now.

With Google it's either beta or deprecated.

Reply on news.ycombinator.com