What is the benefit of using luceneappengine over the search api provided by google app engine?
The luceneappengine project was born first of all to make easier the migration of an existing application to google app engine, and next to allow you to deploy a standard lucene application in google app engine environment.
The search api must be your first choice if you are developing a new google app engine application, unless if you think to move your application into another servlet container that will lack of search api.
Other considerations can be done on costs: luceneappengine uses the default datastore to save index (it means that will use datastore read and write), search api has a dedicated cost definition. You can find the cost details here. Unfortunately it's hard to predict the cost/operations of a luceneappengine application because it depends on indexed files (quantity, size, indexed fields etc..).
Related
After reading available answers/comments on similar questions on this forum, it is now evident that GAE app is not straight-forward ready to be deployed on Compute engine. I fully understand that what all the managed services(mostly as APIs be it, datastore, document/index Search, memcache, cloud storage, task queues, cron jobs etc.), App Engine offered being a platform, won't be the same-fashioned accessible/integration-ready if available on Compute engine at all.
We have a 5 years old fully-grown App engine app now.
I am considering a scenario to support high-level of customization/control and adding third party softwares/middlewares to our server environment which is not possible with App engine. So if we have all solutions(Compute Engines, Container Engines etc.) other than App engine, to migrate our application to meet such requirements, what is the cost of such migration?
Need of server provisioning and configuration at Compute engines with different pricing model[Understood, should not be a problem :)]
Full or partial code rewrite to continue using the same APIs esp. Datastore, Cloud Storage, Task Queues, Cron jobs, Document Search, Memcache etc.[Need confirmation here and any reference/link to migration guide would be help!!]
Does this lead to risk of losing any managed service/API offered from App Engine? Document Search, Memcache, Task Queues, Cron jobs seem the possible candidates. Please confirm.
As per my reading, Big Query, Cloud storage, Pub-Sub APIs integration should not be much affected with such migration(Client-libraries or Rest APIs should still help!). Please confirm.
In nut-shell, We wanted it fully managed in the beginning so PaaS seemed the right choice 5 years ago. Now we want App minus platform-managed plus customized/flexible to our choice. How complicated this transition is going to be?
Full or partial code rewrite to continue using the same APIs esp. Datastore, Cloud Storage, Task Queues, Cron jobs, Document Search, Memcache etc.[Need confirmation here and any reference/link to migration guide would be help!!]
Unfortunately, some of those service only be provided on GAE, such as Document Search. But most of service can be use directly for GCP, such as Datastore, Cloud Storage. GAE Flexible Environment is much like GCP environment, so you can read this article first Migration to GAE Flexible Environment
In following articles also have some answer：
How to migrate Google App Engine Project to Compute Engine completely
Google App Engine Blobstore to Google Cloud Storage Migration Tool
Does this lead to risk of losing any managed service/API offered from App Engine? Document Search, Memcache, Task Queues, Cron jobs seem the possible candidates. Please confirm.
Yes, Document Search only available on GAE.
As per my reading, Big Query, Cloud storage, Pub-Sub APIs integration should not be much affected with such migration(Client-libraries or Rest APIs should still help!). Please confirm.
Yes, but you may need to change SDK or library. It dependency on your language and how to call those service by Rest API directly or SDK.
I've been wanting to use the "Documents and Indexes" feature of the Google Cloud platform, but due to the terribly constraints on AppEngine (e.g. I use gRPC, Cloud Endpoints etc etc). So instead I'm using GKE with Golang and it's all working good. My datastore is "Datastore" and I want to index some documents as I'm creating too many indexes that could result in exploding indexes.
How do we use the appengine search API from GKE? I get this error from Google Cloud Platform "not an App Engine context".. so does this mean that AppEngine standard gets the good stuff while users like me are left without these managed services and wondering if we will ever get these services?
So Google, will GKE/GCE users get:
Documents and Indexes (Search API)
Memcache service
Or do we have to roll up our own solution?
At this point you'll have to roll your own solution as App Engine search isn't available as a standalone product outside of App Engine Standard.
For caching you could follow the same advice given to App Engine Flexible users: https://cloud.google.com/appengine/docs/flexible/python/using-redislabs-memcache
Essentially use either Redis Labs Memcache/Redis Cloud offerings.
Google Custom Search (GCS) has replaced Google Search API.
And all of the GCS docs are heavily weighted toward Website integration -- for adding google to your domain.
But I want to use it in a mobile app for image searches.
They offer a list API:
https://developers.google.com/custom-search/json-api/v1/reference/cse/list
But to use it requires an API key. (see docs)
To create an API key, you need to go to your cloud console and add a project. Then you can "turn on" Google Custom Search API and get a key to use.
https://cloud.google.com/console
But before enabling, a popup forces you to agree to both the Google APIs Terms of Service and the Custom Search API Terms of Service.
Google API Terms of Service https://developers.google.com/terms/
Custom Search Terms of Service:
https://cloud.google.com/console/tos?id=customsearch
In the Custom Search API it clearly states,
"The Custom Search API may be provided to you without any free usage quota at all. You may be charged for each successful request you make through the Custom Search API." And then links a broken link to pricing.
This is confusing to me, since Google Custom Search offers a free tier.
Perhaps this is because they don't have a way of delivering ads through the API?
QUESTION: How do you integrate Google Custom Search into a mobile App via the API at the free usage tier?
If not possible, the pricing doesn't seem to line up, as it's geared towards website searches, not searches within mobile applications (where search could be a primary tool, not a secondary option). Alternatives besides Bing?
MySQL has this Sample Sakila DB where we can start playing around with bunch of data already for our application, how about for Google App Engine/GAEJ is there something like this for the datastore?
I started recently to experiment with the Google App Engine and I was confronted with the same question. I was interested in a REST based app engine backbone which I could easily load/unload with data but couldn't find something to play around.
So I started to build up two projects on github which supports me in such kind of work.
clb-appEngineTemplate is a skeleton application for a Google App Engine Jave REST backend. It provides some sample code for a standardized REST API based persistency layer on Business Object level and can be easily extended (using Objectify and GSON).
clb-test which is a utility class which allows to load Test Data from Excel CSV file into your Google App Engine REST backend.
Both projects are maven based and allow me easily to define data objects which I can upload into the App Engine. Mainly I'm run them against the local test server, which serves me for initial testing.
I just released a first version and will incrementally extend over the next weeks.
AFAIK, there is no sample DB for GAE, probably because datastore write operations are expensive. There are demos bundled with GAE SDK. If you are using Eclipse you can import the samples to your workspace. Some of them involve datastore so you can run the application and add data yourself.
Another way is to use bulkloader to upload data at once using CSV files. But you can quickly run out of free quota for datastore writes.
I was having a look at the new Google Cloud Datastore and looks great. But there is something I could not understand... is it supposed to substitute Google App Engine Datastore? How can I use it inside GAE? What are the differences between both of them?
I have a GAE app in Java that uses 3 entities with thousands of rows each one, and I need to do joins quite often...
The cloud datastore is the App Engine datastore, for use outside App Engine. You won't get any benefit trying to use it with your App Engine app, unless you need other external apps to also have access to the data.
You certainly won't get more efficient joins. If you really need that, perhaps you should look into Cloud SQL, which is basically a version of MySQL you can use from App Engine.
They both are the same, in fact Google App Engine can use Google Cloud DataStore as one of its way to store data, the other options include Google Cloud SQL, Google Cloud Storage. You may select among these three according to the type of data you want to store and the way you want to access them.
From your question its clear that Google Cloud SQL would be right choice as no other options provide joins for retrieving results.
Cloud SQL is nothing but MySQL(the popular open source database) running on google platform. So you can perform your regular SQL-like queries to get your results.