Can I use GAE(Google App Engine) for developing a server for mobile clients? Mobile clients will send data to server every 10 seconds.
I am planning to develop the prototype using GAE and then depending on the results, will decide where to locate the prod server.
And are there any best practices to follow in developing code so that it will have very minimal dependancy with GAE (Can easily port to another environment with minimal code change when required)
thanks.
Ofcourse you can, GAE provides a good way to create a great backend for a mobile app.
about dependencies, you can use a project like django-nonrel, it creates an interface between your code and the API of GAE.
Related
You have a Google Cloud project Project1 with App Engine enabled and serving your legacy application.
You want to rebuild your application using a different programming language and hence need a separate project (Project2) with its own separate App Engine.
You want to install some kind of reverse proxy appliance in front of your Project1 App Engine, so that you can gradually route more and more traffic to Project2's App Engine.
What's the best way to achieve this?
Google Cloud Load Balancer doesn't appear to work with App Engine (only Google Compute Engine), so I'm thinking establishing a reverse proxy server (e.g. NginX) container would be the best bet.
Depending on how you want to organize, you can duplicate your entire application within the same project by just deploying as a different service or as new versions of your existing service. For example, say you have two services frontend and backend for a simple web app. (Let's say they're both written in Python)
For deploying as a separate service, you can create a new version of your application in a different language, say Node.js. You can deploy the new services as frontend-node and backend-node.
If you don't want to do that, you can rewrite your application in a different language and then deploy as a new version of your existing services. In the "Versions" section, you can see your versions of the same service and they can be different language runtimes.
Either way, you can then use the "split-traffic" feature to customize and test implementations of your application.
Generally speaking, you should avoid using projects to isolate different variants and/or components of your application unless you really need too. App Engine services can each be a different runtime from each other so there's almost no point in provisioning a whole new project even though you're redeploying in a different language.
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.
I was trying to start to learn about programming on Firefox OS, and I heard that it is programmed with JavaScript and HTML5, and it uses the same structures of web apps.
Said that, I'm doing a course on Udacity ( I'm a beginner) that is about web development, and it talked about how to use the Google App Engine(we just made our own websites online, using python and some structures of the GAE), and I tryied to make some relationship with what I was seeing in the Firefox website, and I just coundn't figure out nothing.
Google App Engine is a "platform as a service model" of webapps. What you don't need is the key. You don't need :
a Database Administrator
Network technician
a Backup Admin (you still need to make backups of your app and data but not your network config files ect...)
the hardware at your company
the ISP service level agreements
there is more that Google specifically puts in over other platform as a service businesses.
Google takes care of this for you. You just write the webapp (and back it up for a rainy day)
As for Firefox OS, you build application, as you wrote, with HTML5, CSS3, and JavaScript: only web technology. Those are web applications that you build to run on Firefox OS devices, and even in the browser, depending on the API you used. The application you build https://developer.mozilla.org/en-US/Apps, can be either hosted on your own server, or if you packaged it, on the Firefox OS marketplace https://marketplace.firefox.com/.
I would also like to add that Google App Engine is a PaaS at the end of the day. So while technically, one can say that any web application should run, that is not always the case.
If you are using a PaaS, whether it is a Google App Engine or any others like Heroku, CloudFoundry, etc - you must understand the various Services and APIs that it provides in the different platforms that it supports. For e.g. using Google App Engine, you can choose either Java, Python or PHP to write and host your web applications. However, you have to use some of its services like Datastore, etc.
Moving any web application that you have written to a PaaS is not always straightforward. Except for the most simplistic apps that print a "Hello World", there are chances that you atleast have to do the following things:
Migrate parts of your application to utilize the Platform Services/APIs
Rearchitect parts of your application to take maximum advantage of the Cloud i.e. multi-tenancy, Scaling, etc.
You could treat Google App Engine(GAE) as web server hosting with specific web framework (python or java), which can host any normal webapps.
Firefox OS webapps are written with normal web skills. So you can use GAE to 'host' Firefox webapps.
(GAE is also mentioned as one of hosting place in Mozilla Developer Network
https://developer.mozilla.org/en-US/docs/Trash/Publishing_the_app )
The evil detail is Firefox webapp need an extra 'manifest.webapp' file that need extra MIME host settings
self.response.headers['Content-Type'] = 'application/x-web-app-manifest+json'
https://developer.mozilla.org/en-US/Apps/Developing/Manifest#Serving_manifests
Then you are ready to host Firefox Webapp on GAE :)
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.
I am interested to build a platform on Google App Engine where one Master App provides common functionality to several child Apps (Web portals).
Master App:
Offers Common Social Networking features
Common user database
Interacts using Web services API
Child Apps (Web Portals):
Connects to Master App for user database and social networking features
Uses Local business logic for local features
My Design plan is:
Master and Child Apps will be
individual Apps on GAE Appspot (for
easy management)
All will communicate via REST/JSON?
I will enable billing for all Apps so
nothing is against Google's usage
policy.
Will use SSL for login into Master App, later use a token
(cookie) for further interactions
Could anyone kindly spot risks and suggest any improvements?
Your "Master/Child" concept will be hard to maintain, introduce issues with cross-site-scripting and most importantly be completely against Google App Engine's terms of service for combining multiple apps into one.
4.4. You may not develop multiple Applications to simulate or act as a single Application or otherwise access the Service in a manner intended to avoid incurring fees.
You could use multiple app versions (defined on app.yaml) to deploy different codebases to the same appspot.com subdomain, and access them like http://app1.myapp.appspot.com, http://app2.myapp.appspot.com for "versions" app1 and app2. You could even have one version running on Java and another one on Python.
They'll all share the same datastore, although you'd be able to use namespaces to separate them if necessary.
For the distributed nature of the architecture you proposed, I'd suggest having a deep look at Facebook's graph API and Twitter's API. They both use oAuth for authentication/authorization and already have a proven implementation of what you're trying to accomplish.