Live data from Hacker News

Node.js on Google App Engine Goes Beta

cloudplatform.googleblog.com

61–70 of 114 posts

Re: Node.js on Google App Engine Goes Beta

#61

So many negative views of GAE, I have to add our, overwhelmingly positive, experience. We were paying $200/month for a load balanced EC2 setup in 2011, that's for around 2k unique daily users. The load balancer kept on false triggering new instances, so we went to GAE in 2012. Since then our uptime has been horrifically good, heavily thanks for GAE, trashing that of our competition, who mostly use AWS. Last month we…

did software change to account for efficiencies?

No, the basic architecture hasn't changed, but the app does a lot, lot more than it did in the AWS days.

Re: Node.js on Google App Engine Goes Beta

#62
post #2

This seems to be for Managed VM [1] only, so it's a case of better documentation & tooling, but no new functionality. You can already run arbitrary code of any language on Managed VM instances. [1] Managed VM is a sort of meet-half-way service from Google that is quite freeform like Compute Engine, but also offers access to a good chunk of App Engine's services. Still, it's very much not the standard App Engine.

I don't mind managed vms, I just wish they had the same pricing model as app engine.

Re: Node.js on Google App Engine Goes Beta

#63

is anyone using node.js in enterprise? because everyone seems to be convinced that the enterprise companies are going to uproot all the network of partners, developers, vendors, and billions of dollars of investment made over the past decade? Like it or not, JVM pretty much rules the enterprise space and there's just no way to do it another way. Literally, you will be turned away because you told the IT department th…

[deleted]

Re: Node.js on Google App Engine Goes Beta

#64
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...

Re: Node.js on Google App Engine Goes Beta

#65

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…

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.

Re: Node.js on Google App Engine Goes Beta

#66

is anyone using node.js in enterprise? because everyone seems to be convinced that the enterprise companies are going to uproot all the network of partners, developers, vendors, and billions of dollars of investment made over the past decade? Like it or not, JVM pretty much rules the enterprise space and there's just no way to do it another way. Literally, you will be turned away because you told the IT department th…

Honestly what is the enterprise these days? Internal apps are getting very quickly replaced by SaaS. Some of them are built on Node.js and many of them aren't. Most of the larger ones are built on a mix of technologies.

And so is the enterprise. You'll find it impossible to find a single Fortune 500 company with everything they do in one single stack. It just doesn't happen. Microsoft have Linux services and systems. Banks are a mish mash of multiple stacks.

They might have larger amounts of one stack than the other, but so what?

To answer your question: yes, enterprises are using node.js. Both directly and indirectly. It's not just fanboy technology. It works. We switched Craigslist from postfix to Haraka and they love it. Just one example but there are plenty out there.

Re: Node.js on Google App Engine Goes Beta

#67

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…

> 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.

Re: Node.js on Google App Engine Goes Beta

#68
post #49

Earlier quoted context omitted.

it irks me when a 19 year old CTO on the autistic spectrum This added literally nothing to your post aside from a nice dose of ableism. This is HN, not reddit (if that still means anything these days)

you add nothing to the discussion on whether you are using node.js in enterprise or not. feel free to nit pick further by adding nothing to the discussion. reply to the other guys comment below: what's a BRE? true but a bulk majority of businesses (fortune 10,000) are built on some type of Java. I just don't see them uprooting their investments. It's always easier to think of tearing things down then building on top…

They aren't nitpicking, it's a shitty thing to say. Period.

Re: Node.js on Google App Engine Goes Beta

#69

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…

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...

Re: Node.js on Google App Engine Goes Beta

#70

Don't use AppEngine. I migrated Homejoy off of AppEngine in 2014 and I can't recommend the platform for any reason whatsoever. It's slow, expensive, not based on OSS, and not particularly stable. Bits of it (urlfetch, search, etc) would go down for hours at a time and you're basically hosed until they fix it. I think Heroku is usable with a similar level of effort -- and you have a much easier migration path to somet…

Apologies you had a bad experience. There's no doubt the original App Engine had some... quirks. You may want to take a look at Managed VMs. All of the new runtimes are based on Docker images, are entirely extensible, and don't require the use of the original App Engine APIs: https://cloud.google.com/appengine/docs/managed-vms/ You can use whatever Database or NPM modules you want.

Hi Justin,

I'm currently trying to get my feet wet on GAE. Judging from your statement, are you suggesting that people should look into Managed VMs and maybe skip the regular GAE (or known as the original GAE)?

Perhaps the original GAE will be deprecated in the future?

Post reply on HN