How to access memcache on App Engine Nodejs Standard - node.js

How does one access memcache from the nodejs standard environment?

The documentation apparently makes no reference to the App Engine memcache being available to the Node.JS standard environment, at least not at this time:
there is no Node.JS language tab in the Memcache Overview page(s)
there is no Caching Application Data section (under which the memcache-related docs exist for the other languages) under How-to Guides in the left-side navigation bar for Google App Engine Node.js Standard Environment Documentation
But there may be an alternative. From APIs & Reference:
Which leads to Node.js Packages, where I can see:
Which leads to Cloud Redis: Node.js Client.
This is inline with the suggestions from the Memcache section of the Migrating Services from the Standard Environment to the Flexible Environment guides, the flexible environment having the same problem (except clearly documented):
The Memcache service is currently not available for the App Engine
flexible environment

Related

Using Azure SDK for JS to create .NET 4.x App Service

I'm starting to wonder whether this is the right tool for the job, still here goes.
I'm attempting to automate the creation of our Azure Test environment using Azure SDK for JS. The environment spans many services (as you can imagine), including Classic ASP.NET app services.
Node is my safe space, so that is why I started with the JS SDK.
I have started scripting the creation of an app service using WebSiteManagementClient.webApps.createOrUpdate. I'm confused though, there is seemingly no way to configure any of the following:
Which app service plan the app service should be connected to. This feels fundamental.
The operating system, Windows or Linux.
The stack version, .NET 4.8, .NET Core, or whatever.
Is it possible to configure the above using the JS SDK, or am I going to have find another approach?
Update 23/03/21
Untested, but these are my findings so far:
App Service Plan - The plan is set using the serverFarmId property of the Site interface.
Operating system - Assuming Windows as the default, if you want a Linux app service, you change the kind property of Site from app, to app,linux.
Stack & version - In the SiteConfig interface, you have linuxFxVersion and windowsFxVersion. Again, I think the assumption is 'latest .NET' (e.g. .NET 4.8). For .NET Core 3.1, the setting looks to be DOTNETCORE|3.1.
It can be achieved using js SDK. I checked the source code and it is ok. But I don't recommend to use js sdk to do this.
Because you need to call the SDK, there are many internal logics that you need to code. This will waste a lot of your time. So I recommend you to use restapi.
The restapi method name is similar to the naming in the SDK, mainly because you can test api interfaces online to achieve the functions you want. So you can selectively choose the method you want to achieve the function you want.
Official doc
Web Apps - Create Or Update
As for your concerns, you only need to write all the configuration in json format and put it in the request body.
Tips:
First use the online interface, encode the json format, create a webapp according to your needs, and then integrate it into your code.

How to use GCP Runtime Configurator from Node.js?

I'm working on a Node.js application hosted on Google Cloud, using Google Application Engine. The app has a few settings like the following:
const TASK_BATCH_SIZE = 50;
Currently, every time we need to change some settings like that one to do some tests we need to re-deploy the app, and that happens very often. We are looking for some alternatives inside the Google Cloud ecosystem that allows us to configure our running services without needing to re-deploy.
One of the things we found in the docs was Runtime Configurator, which still seems to be a beta product. For Node.js specifically nodejs-rcloadenv is the only client library we found, but doesn't seem to support the Watcher / Waiter concepts described in the Runtime Configurator docs or any other way to subscribe to variable changes in a configuration resource.
Is Runtime Configurator the solution to our problem? Are there any other services inside the Google Cloud ecosystem, or any other library for Node.js that could help us with this?
If you want to update or to make some settings changes in the service, you need to re-delpoy the service.
You can't use Runtime Configurator as it's for Compute Engine and not for App Engine.
You can create a feature request on Google's Public Issue Tracker for your issue ( to update configurations without re-deploying the service).

Memcache in Google App Engine Standard environment for NodeJS [duplicate]

How does one access memcache from the nodejs standard environment?
The documentation apparently makes no reference to the App Engine memcache being available to the Node.JS standard environment, at least not at this time:
there is no Node.JS language tab in the Memcache Overview page(s)
there is no Caching Application Data section (under which the memcache-related docs exist for the other languages) under How-to Guides in the left-side navigation bar for Google App Engine Node.js Standard Environment Documentation
But there may be an alternative. From APIs & Reference:
Which leads to Node.js Packages, where I can see:
Which leads to Cloud Redis: Node.js Client.
This is inline with the suggestions from the Memcache section of the Migrating Services from the Standard Environment to the Flexible Environment guides, the flexible environment having the same problem (except clearly documented):
The Memcache service is currently not available for the App Engine
flexible environment

What's the difference between "Google App Engine Flexible project", "Standard project" and "Dataflow project"

After installing Google Plugin for Eclipse, there are options to create three different types of projects
Google App Engine Flexible Java Project
Google App Engine Standard Java Project
Google Dataflow Java Project
What is the difference between these three?
App Engine allows you to deploy application with minimum infrastructure related configuration. Standard is quicker in both deploying and scaling your application, but has a limited choice of languages and libraries to use. Flexible manages docker containers so it can run almost anything and has more powerful machines to chose from, same that Compute Engine has, but it takes longer to deploy and is in general more expensive.
Lightweight generic code that should be always available should run on Standard. A batch job that is processed once every day and requires an expensive setup and third party libraries would better run on Flex.
More on that here
Google App Engine Dataflow Java Project
It's not an App Engine, it says:
Google App Engine Dataflow Java Project
It's a service directed specifically at batch jobs and streaming. More on it here.

Deploy node application to Google App Engine standard environment

Until december 2016, I was able to deploy node applications to Google App Engine standard environment with an app.yaml looking like this:
runtime: nodejs
vm: true
api_version: 1
manual_scaling:
instances: 1
Now, when I do this to deploy to a new project, I get this error message:
ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: Deployments to App Engine
Flexible require 'env: flex' in app.yaml. The 'vm:true' setting has
been deprecated.
But I'm still able to deploy with this configuration for existing projects.
Has something changed recently in Google App Engine for Node.js ? (I don't know when reading the error message if standard environment is deprecated, or if for some reason it considers I chose to deploy to a flexible environment, and so I can't use vm:true because this option is deprecated for flexible environments).
The vm: true indicates you were actually deploying to the flexible environment (an earlier version). The standard environment never supported node.js apps, see https://cloud.google.com/appengine/docs.
Yes, there was a change in the flexible environment (all languages, not only node.js). See Upgrading to the Latest App Engine Flexible Environment Beta Release. From there, explaining why your existing apps still work:
Applications created with vm:true
All applications created in the vm:true environment will continue to
work for at least 6 months after the App Engine flexible environment
becomes generally available. At that point, all customers need to
switch to the env:flex environment.
UPDATE:
Node.JS is currently available in the standard environment as well, see:
Now, you can deploy your Node.js app to App Engine standard environment
Google App Engine Node.js Standard Environment Documentation

Resources