I managed to get Google Cloud Messaging working on an embedded device using libcurl using http requests and a 'BrowserKey' for authentication.
Now i would like to move to Google Cloud Datastore for saving settings of the embedded device into the cloud. There seems to be support for Java, Ruby, Python, NodeJS but so far I found nothing that could help me further using things i know.
Can I get access to the Cloud Datastore from my existing application written in plain C ?
While we don't have client libraries for C, we do have a RESTful API (documentation) that you can call, so it should be possible to write your own simple library in C to talk to Cloud Datastore from an embedded device.
If you are concerned about security (since someone could possibly impersonate your embedded device and get direct access to your Cloud Datastore instance, I recommend you take a look at Cloud Endpoints (documentation). It gives you an easy way to generate a RESTful API on top of App Engine. You could then use your custom API in the embedded device and use App Engine as a proxy/data validation layer that controls access to the database.
Related
How do they differ? and what is the use case for each?
Is it possible for me to use one exclusively, such as if I'm more familiar with .NET I could do everything using the Client Library (for .NET) that I could with python and the SDK?
Google Cloud SDK https://cloud.google.com/sdk/docs/
Google Cloud Client Libraries https://cloud.google.com/apis/docs/cloud-client-libraries
The Cloud SDK is a set of command line tools (gcloud, gsutil, and bq). The use of the term 'SDK' here seems to be misleading and they should probably be called Google Cloud Tools or Google Cloud CLI.
The Cloud Client Libraries are the latest set of libraries available in various languages that you can program against.
There's also an older set of client libraries called the Google API Client Libraries. They're autogenerated from Google service interfaces and are simple wrappers to REST calls. You should probably use the newer Cloud Client Libraries if you can as they are more idiomatic and provide better abstraction.
Jarmod's answer is excellent.
Could I do everything using the Client Library (for .NET) that I could
with python and the SDK?
Almost everything. Exceptions I know:
.NET code can't run on good ole Google App Engine Standard. You can still run your .NET code in Google Compute Engine (on Windows) or Google App Engine Flexible Environment (.NET core code on Linux.)
Tensorflow only has a Python API.
Bigtable doesn't have a .NET API.
https://github.com/GoogleCloudPlatform/dotnet-docs-samples shows how to call many, but not all of the Google Cloud APIs.
I have previously used
#app.route('/mypage/<int:myvariable>/')
to create rules for what should happen when users land on different urls on my website. I have done this on local machines that have been running on my own virtual servers.
Now I am learning to publish my first web app to Google App Engine. I have heard that I should be using Google Cloud Endpoints instead of the route decorator.
#endpoints...
I've read a few articles about endpoints and some of the benefits of endpoints that they list are:
Endpoints makes it easier to create a web backend for web clients and mobile clients
Endpoints free you from having to write wrappers to handle communication with App Engine
Even if I have read this I can't wrap my head around what this means. I don't understand it. Can you explain in non-technical terms with examples what the advantages of using #endpoints is compared to alternatives? The alternative that I am familiar with is #app.route.
Google Cloud Endpoints can be thought of as a subset of #app.route. They are intended to solve the API backend problem for mobile and javascript clients. They are not intended to serve web pages and other hypermedia. You can use the normal routing methods of your framework of choice to create a web service for your application but Google Cloud Endpoints takes care of a lot of boilerplate for you.
There are a lot of limitations with Google Cloud Endpointsso be sure to familiarize yourself with them before committing. For one, you cannot host Google Cloud Endpoints on a custom domain name. They are only accessible via <app_id>.appspot.com/_ah/api/*
Endpoints makes it easier to create a web backend for web clients and
mobile clients
What this means is that you can create one backend and then iOS, Android and Web-apps (via Javascript for example), can execute your API methods with specific client generated libraries.
This is convenient if you are building a backend that you want to be easily accessed via smartphones or through a web browser.
Endpoints free you from having to write wrappers to handle
communication with App Engine
With Endpoints you can generate client libraries (e.g. Android, iOS, Javascript) that you can then execute your API methods. You don't have to worry about writing a bunch of additional code to do that.
My Opinion:
I have never used Cloud Endpoints to make a web-app but it is very convenient if you are making a mobile app for iOS and Android because you can access your backend with both platforms.
One reason you might want to use Cloud Endpoints for a web-app instead of something else is because of Datastore. Datastore is the way Cloud Endpoints stores data. It is a NoSQL storage method which is kinda tricky to wrap your head around at first if you come from a relational database background, but once you get it, it makes a lot of sense.
We are currently running a combined AppEngine / GCE app and thus far have kept all of our datastore access on the AppEngine side of things. Now we are exploring also allowing our GCE instance to make some queries into the (shared) datastore. To start, I'm trying to figure out how to run things locally. What we have so far:
A Go devappserver running
A Go standalone binary that wants to issues queries to the devappserver datastore.
We installed ('go get') google-api-go-client/datastore/v1beta2 so that we can use an API instead of issuing direct HTTP calls. However we are definitely willing to issue direct HTTP calls if this API library won't work in development.
We have service accounts set up (we already access GCS from GCE) but I doubt that's relevant for running locally...
I've seen some docs but they (a) only talk about Python & Java, and (b) discuss connecting to the (standalone) development datastore server, as opposed to the datastore embedded in AppEngine's devappserver (if those are even different?). There is also the following answer here on StackOverflow, but again it discusses connecting to the standalone development datastore server:
How to connect to the local google cloud Datastore db?
Any pointers would be much appreciated!
Ian
Currently this is not possible in the development environment for several reasons. The Google Cloud Datastore tool (gcd.sh) uses the java development server. However when developing go for App Engine you use the python development server, which has different underlying storage. There is a bug to track this issue on the github page.
You can still develop a Google Cloud Datastore application in go however there are many bugs in the current go client library. Unfortunately, the development server does not currently support the JSON API, which the go library uses (see the note at the top of the page).
Update: I wanted to make sure proppy's comment was seen as part of the answer. His suggestion does provide a way to use the protocol version of the API, which is probably more stable than the go client library above. It could also let you use the gcd.sh tool to test this in the development server. You will have to craft the HTTP requests yourself though, and you won't be able to share the data in the datastore between your application and the Cloud Datastore in development. However it is definitely a good workaround and lets you use the Cloud Datastore API, which as it develops will be easier to work with than other workarounds.
From proppy:
Note that you can still use Cloud Datastore Protobuf HTTP API with Go. The protobuf definition is available on GitHub, you can compile it to Go code using the Go protobuf compiler plugin and then send POST HTTP requests to /datastore/{version}/datasets/{datasetId}/{method}.
If the use case from your "GO" app server is straight forward enough, you may want to implement access by using an API call to your GAE service (perhaps extending the service to receive the API calls).
This has the added benefit of only having to make changes in one place if your datastore definitions or functions change.
I want to write a desktop application that interacts with a GAE-based web service. For Android and Web clients there is the possibility to generate client libraries automatically. Is there a way to generate client libraries for C or C++? I would settle for Python as well.
Theoretically all the Google APIs Client libraries allow accessing any Discovery-based API as long as the discovery document is available (which is the case for cloud endpoints) even though the functionality isn't very well documented in most cases.
See https://developers.google.com/discovery/libraries for a list of currently available client libraries.
As example of how you can use the python client library with cloud endpoints:
service = build("your_api", "your_api_version", http=http,
discoveryServiceUrl=("https://yourapp.appspot.com/_ah/api/discovery/v1/"
"apis/{api}/{apiVersion}/rest"))
result = service.resource().method([parameters]).execute()
Currently, Google App Engine Cloud Endpoints only supports generating client libraries for Android (Java), iOS (Objective-C) and JavaScript. See https://developers.google.com/appengine/docs/java/endpoints/overview.
Of course you may still develop your application using GAE for your web service and write the web service interface libraries yourself in any language you choose.
I have a question surrounding the REST service. I have an application written in C# , i want to put this application onto the cloud. I have a small problem, My Application has a built in C# API. I want to interact with my application and Google app engine. I want to develop a JAVA PROXY on top of GAE so that it can interact with my application using REST protocol and performs CRUD operations on Cloud and returns back data to my application.
Is it possible to do this ? to what i know is that SANDBOX feature doesn't allow us to directly interact with the App Engine.
Any suggestion on this.........
Thanks Heaps
Suraj
You don't need Java Proxy API in order to make http requests to another server (I guess you did not have java's Proxy class in mind?).
Yes, AppEngine can make HTTP/REST requests to other servers via URL Fetch java API.