I want to build an app with a Google App Engine Backend, where do I start?

Google App is an alternative to Parse, but you will need to re write the API and frontend code in the event you decide to go for this option. If you are looking for a more straightforward option, plug & play and to be done is less than 5 minutes please refer to www.back4app.com.

At this moment the best alternative to Parse users is to migrate his database and application service to a server running the Parse solution (Server + DB). This is the best plug and play option. It's not so simple when you have contracted a service to eliminate your effort setting up servers or to worry about your data

Google App is an alternative to Parse, but you will need to re write the API and frontend code in the event you decide to go for this option. If you are looking for a more straightforward option, plug & play and to be done is less than 5 minutes please refer to www.back4app.com.

At this moment the best alternative to Parse users is to migrate his database and application service to a server running the Parse solution (Server + DB). This is the best plug and play option. It's not so simple when you have contracted a service to eliminate your effort setting up servers or to worry about your data is being stored or migrated.

After the parse shutdown the new trend to BAAS providers is to offer a migration that will require a big effort developing the backend on its solution and recoding the front-end/mobile app connection with the API.

On the other side the PAAS/Cloud providers can offer a machine ready(with all the Parse environment ready) to upload your Parse service. That will require effort migrating the service and if you need to change something on your model/application you will still need Parse dashboard. So this is gonna work until the parse shutdown.

back4app(https://www.back4app.com/en/) is an open-source backend generator with a BAAS integrated. Currently we are working on a solution to migrate automatically the Parse solution to back4app without any effort from Parse users https://parse.back4app.com/). After that we will adapt our Model driven development Tool to generate Parse code and continue to improve the Parse framework, always open source.

Show the below courses from lyndan.com . I think it will help you.

http://www.lynda.com/Developer-Cloud-Computing-tutorials/Google-App-Engine-Essential-Training/194134-2.html

Learn how to deploy scalable web and mobile applications on Google's cloud infrastructure.

Think of writing a backend like managing a bank. The database is the bank vault, the app server is the customer service personnel, and the app clients are, of course, the bank clients.

Obviously, clients should never have direct access to the bank vault! That would be a massive security breach. Everything they do is via requests to the bank personnel. Similarly, your iOS/Web/Android clients should never have direct access to the database. They should only make requests to your app server.

Like managing a bank, there is no one exact Right Way (TM) to write a backend. But there are certainly commo

Think of writing a backend like managing a bank. The database is the bank vault, the app server is the customer service personnel, and the app clients are, of course, the bank clients.

Obviously, clients should never have direct access to the bank vault! That would be a massive security breach. Everything they do is via requests to the bank personnel. Similarly, your iOS/Web/Android clients should never have direct access to the database. They should only make requests to your app server.

Like managing a bank, there is no one exact Right Way (TM) to write a backend. But there are certainly common themes which you'll see pretty much everywhere.

Popular vaults include MySQL, Postgres, MongoDB, and Redis. There are pluses and minuses to each one, and people will zealously defend their preferred choice with the same zeal smartphone users defend Android or iOS. Databases like MySQL and Postgres require you to arrange your data into pre-specified tables, while something like Redis gives you a bit more freedom (and responsibility!)

The most common "language" by far for communicating between iOS/Web/Android clients and the app server is JSON over HTTP. Everything from Facebook, to Twitter, to Github speaks this dialect, so unlike your choice of database, there's really not much contention here. Just learn how to handle HTTP requests and make JSON replies--you can't really go wrong here.

The most difficult part is writing the "brain" of your app server. It needs to accept requests from clients, talk to the database, and give back a response to the clients. How exactly you do this is, again, controversial: popular choices of programming languages include NodeJS, C#, and Ruby. Each language community will have its own frameworks, like Express for NodeJS or Ruby on Rails for Ruby.

Despite the apparent explosive variety of choice, most of these languages and frameworks are actually quite similar: Sinatra/Ruby, Express/NodeJS, Martini/Go, Flask/Python, etc., are largely the same thing; it will take a while to learn your first framework and language, but after you've done it once, learning others in the same family is pretty straightforward.

For your first time, I'd recommend MySQL and Express/NodeJS. Both are well-documented and widely used, and even if you refine your tastes later, much of what you learned will still be applicable.

Good luck!

Juri, CTO at Ramotion Digital Design Agency

Nope. Nope. Nope.

(Note that I moved away from GAE 10 months back, my information could be wrong in some cases, but the point is more or less same, also note that I am only talking about App Engine here and not Compute Engine)

Many of "advantages" of GAE evaporate very quickly as soon as you start to scale. Unless you are not serious about potential scalability of the project you should not host it on GAE.

First of all from commercial perspective bill for using GAE goes insanely higher as you scale, you are not only paying for maintaining data, you are also paying for every read and w

Nope. Nope. Nope.

(Note that I moved away from GAE 10 months back, my information could be wrong in some cases, but the point is more or less same, also note that I am only talking about App Engine here and not Compute Engine)

Many of "advantages" of GAE evaporate very quickly as soon as you start to scale. Unless you are not serious about potential scalability of the project you should not host it on GAE.

First of all from commercial perspective bill for using GAE goes insanely higher as you scale, you are not only paying for maintaining data, you are also paying for every read and write that occurs on your datastore database. Even though on paper it looks fair, reality is very different. No matter how hard you try reduce number of queries, once your service starts getting popular, your bill amount would increase exponentially.

Second from developer perspective, I find Google to be very slow, to provide support for new stuff, at the time I left GAE, web sockets were not supported. Imagine some interesting new tech comes along, that can widely benefit your customers, would you prefer to wait for GAE to implement support for that tech or would you want to build it asap? (to enable push messaging you need to contact third party supporters who can make push calls for you). Besides some of the rules are very restrictive, you can't run a query that gives 1000 rows, you can't run a task for more than 10 minutes. On GAE we were spending disproportionate amount of time hacking around these restrictions to do trivial things.

Third, GAE being platform as a service the lock in is very dangerous, you are not only writing custom queries that suit their needs you are also designing your application in a way that suits architecture of GAE. At the time of moving (And believe me, looking at the bill you would want to move one day) you will be redesigning not only your codebase but rewriting all your custom queries.

Some of the web tools provided are hilariously weak, for example search results on logs go only 10 pages by default, billing portal doesn't let you change maximum billable amount more than twice (That caused a downtime on our servers once).

Typical recommendation is to use GAE on side projects and use something else for production, I would contend that one should not use GAE for any purpose, not even for side projects. Most side projects are done for the purpose of learning, if you want to learn you are better off learning on platform that you are going to use in production.


Note: I still keep on getting mails on downtime for GAE, look at the timestamps, surely not looking very bright there. (To be fair, things were better on stability front when I was using it on production)

I think you should be asking them that. If they are forced to use it and are using it, you could also just listen. When they randomly swear and get someone to "come here and look at this ***" or "I cannot believe this thing ...." listen. They should tell you pretty readily.

It is a truly amazing platform. I have built some amazing stuff on it. It is not for everybody. The sandbox is currently pretty restrictive. On a positive note, if you can build with their architecture in mind, you can scale many services to billions of users.

Google Compute Engine is also an excellent outlet. The round trip

I think you should be asking them that. If they are forced to use it and are using it, you could also just listen. When they randomly swear and get someone to "come here and look at this ***" or "I cannot believe this thing ...." listen. They should tell you pretty readily.

It is a truly amazing platform. I have built some amazing stuff on it. It is not for everybody. The sandbox is currently pretty restrictive. On a positive note, if you can build with their architecture in mind, you can scale many services to billions of users.

Google Compute Engine is also an excellent outlet. The round trip times between GCE and GAE are really low. Google also has a great network connection to any other cloud service.

The biggest complaint that I have heard is for smaller systems it is easier to build yourself, can run on one or only a few machines, and will perform better. If you truly don't need to scale, these are pretty compelling arguments. If you want to scale to millions of users without having massive downtime while you try and forklift your implementation onto a new stack, build on something that easily scales. In one of my companies, smaller customers mentioned how they could do this on one box. As a vendor, you need to handle a lot of smaller companies all going in different directions. We had one customer grow by 4,000 times in a few months. Their servers had trouble keeping up, ours did not.

Jacob

First of all, it takes lots of practice and understanding to build productive web applications. Well, that doesn't mean to scare you.

I would suggest you to start with front-end development part - writing HTML, CSS templates. And then make a basic model of what your site should look like, i.e without any functionality.

Now, for the backend part (server side), you can start with whatever language you want to. If you are good with Java, you could very well try Apache Tomcat. If you want to learn some other language, say, you want to cope up with the present trend in terms of frameworks that are us

First of all, it takes lots of practice and understanding to build productive web applications. Well, that doesn't mean to scare you.

I would suggest you to start with front-end development part - writing HTML, CSS templates. And then make a basic model of what your site should look like, i.e without any functionality.

Now, for the backend part (server side), you can start with whatever language you want to. If you are good with Java, you could very well try Apache Tomcat. If you want to learn some other language, say, you want to cope up with the present trend in terms of frameworks that are used extensively, then you might wanna try RoR, Django, nodejs, etc... PHP is one option too, but, it is believed that ppl end up writing shitty code when they start with PHP.

Well, one more point that needs to be mentioned is - no framework can be considered as inappropriate / NOT good. It depends only on the code that you write. Certainly, in a contradiction, the frameworks do provide a platform for you to structure your code.

Once you're done with the server part, test your application for efficiency and bugs. Learn about preventing few of the common threats and implement it.

Next comes the JavaScript part. It is the second most important thing after the business logic you implement at the server side. Now, it's the time to learn JavaScript. Kindly note, don't start with JavaScript immediately after writing your template. Once you have everything working, it's time to fiddle around, and, disturb the whole setup. In this way, your learning experience would be pretty good. After some experience with JavaScript, you can start implementing AJAX in your site. Once that is understood properly, you can try HTML5 - websockets, web workers etc... and come up with a pretty good productive web application :). THE END ;).

Having a ‘website’ or not has nothing to do with building the backend for a mobile application.

You will need to figure out the following (not exhaustive):

  1. Setting up a database and schema modelling
  2. Backend APIs (Data, Auth, Business Logic)
  3. Deploying your backend on a cloud provider and iterating on it
  4. Security and Access control

I would strongly urge you to check out the following:

  1. Becoming a full stack developer - a free online course that will teach you the fundamentals of building a modern backend.
  2. hasura.io - A backend development platform with built in backend components like Data and Auth APIs

Having a ‘website’ or not has nothing to do with building the backend for a mobile application.

You will need to figure out the following (not exhaustive):

  1. Setting up a database and schema modelling
  2. Backend APIs (Data, Auth, Business Logic)
  3. Deploying your backend on a cloud provider and iterating on it
  4. Security and Access control

I would strongly urge you to check out the following:

  1. Becoming a full stack developer - a free online course that will teach you the fundamentals of building a modern backend.
  2. hasura.io - A backend development platform with built in backend components like Data and Auth APIs and convenient deployment options that work across any cloud provider like AWS, Google Cloud, Azure etc. You can even start developing on your laptop and, once you are done, migrate the backend to a public cloud. See this video

Disclosure: I work at Hasura.

App Engine can work in Ruby too, http://code.google.com/p/appengine-jruby/

The main choice you have is between infrastructure as a service, iaas (like AWS) or platform as a service, paas (App Engine, Heroku, Joyent, Azure).

iaas will give you total flexibility on the architecture, language and technical components you use for your app, but you still have to assemble and manage your infrastructure yourself.

With paas, the platform puts constraints on your code (specific languages supported, time limit to execute a request, datastore type), but if you can respect these constraints the benefits are

App Engine can work in Ruby too, http://code.google.com/p/appengine-jruby/

The main choice you have is between infrastructure as a service, iaas (like AWS) or platform as a service, paas (App Engine, Heroku, Joyent, Azure).

iaas will give you total flexibility on the architecture, language and technical components you use for your app, but you still have to assemble and manage your infrastructure yourself.

With paas, the platform puts constraints on your code (specific languages supported, time limit to execute a request, datastore type), but if you can respect these constraints the benefits are huge: you just write your code, push it to the platform and don't have to manage anything.

Working for Google, I am biased, and would recommend App Engine, which works for Python and Java, but also for languages that run on top of the Java VM, like Ruby, Closure, Scala, Groovy.

But there are other great paas offerings from other vendors:
- if you do .NET, Azure
- javascript, Joyent, who created node.js
- Ruby or javascript: Heroku

One of the restrictions that the platform often enforces is the choice of database. For app engine, you have to use BigTable, which is a non relational database. However, if you build an Enterprise App for a company's intranet, you might want to look at App Engine for Business, with which you can use SQL. It is in trusted testers for now, let me know if you are interested in trying it out.

If you want to build a web apps,you must master first HTML and CSS.You can learn them from w3schools.com

Javascript is also important for web development because it will make the processes of your web application.For example,if you want a password with 8 characters,changing images,and many more.You can also learn it from w3schools.com

PHP is also very important for web development.Like Facebook,PHP is used to make processes too.For example,login validation.PHP detects if you have already registered to a website so your login will be validated and successfully log in to a website.

My recommendatio

If you want to build a web apps,you must master first HTML and CSS.You can learn them from w3schools.com

Javascript is also important for web development because it will make the processes of your web application.For example,if you want a password with 8 characters,changing images,and many more.You can also learn it from w3schools.com

PHP is also very important for web development.Like Facebook,PHP is used to make processes too.For example,login validation.PHP detects if you have already registered to a website so your login will be validated and successfully log in to a website.

My recommendations for building a web apps is using Bootstrap.Bootstrap is a framework that make web developers easier to develop a website.It is an responsive,mobile-first framework.It is amazing instead of creating media queries yourself.
Get the bootstrap tutorial from w3schools.com

But if you want to create media queries,that's no problem.You can learn media queries from google

Other frameworks like Pure,Skeleton,Foundation will help you too

It depends on how you architect your backend. If you're just a mobile app developer and know nothing about coding web backends, then Parse is the way to go, but of course you'll suffer from occasional downtime of Parse for whatever reason.

Wouldn't recommend Google App Engine because of cost factor.

AWS and DigitalOcean gives you total control of your server environment, which requires you to code a web backend and manage your dependencies all by yourself. Cost factor forAWS is decent. Linux knowledge required to manage all these. DigitalOcean is really cheap to start off with.

Heroku and Open

It depends on how you architect your backend. If you're just a mobile app developer and know nothing about coding web backends, then Parse is the way to go, but of course you'll suffer from occasional downtime of Parse for whatever reason.

Wouldn't recommend Google App Engine because of cost factor.

AWS and DigitalOcean gives you total control of your server environment, which requires you to code a web backend and manage your dependencies all by yourself. Cost factor forAWS is decent. Linux knowledge required to manage all these. DigitalOcean is really cheap to start off with.

Heroku and Openshift has a nice touch of pushing your web component to their servers using git push. Pricing is decent. Haven't experienced the downtime for these two services before, but it's nice to have it as a dev server.

It's not 100% clear what problem you're referring to, but if it's the lag time a user sees as a new instance is loaded up, you can add a few Idle Instances (documentation here: https://developers.google.com/appengine/docs/adminconsole/performancesettings) to your app to better handle spikes in traffic by having pre-loaded instances on the ready.

Might be easier just to:

- Expose a REST endpoint
- Use standard HTTP client libraries

There are benefits to using things like Cloud Endpoints, but without knowing what it is you are trying to do, it is hard to recommend a solution.