My app was built using Parse as a backend. My understanding is that the plug-and-play architecture of Parse is limiting - that the services layer that should be used for business logic doesn't exist or is limited. Now I'm debating whether to build a custom backend or to use Amazon Mobile Hub. My concern though is that if I chose Amazon Mobile Hub I will run into the same services layer issues I experienced with Parse.
I'm wondering if my assumption is correct: does Amazon Mobile Hub have a non-existent or limited services layer?
I would suggest you to try AWS Amplify https://aws-amplify.github.io/
Related
I am building a mobile application targeting iOS, Android and WP with Ionic/Cordova. And using ASP.NET Web API 2 REST APIs backend.
I have the requirement that the mobile application can collect data and synchronise it with the APIs and if the mobile is offline, the sync will happen when it is online. The data size is small and any light DB would do including the localStorage one. The required sync is only needed one way, mobile to APIs. Also, once a record is synchronised, it can be deleted from the mobile.
I was looking at Couchbase mobile, but I found it is a Mobile DB to DB sort of a solution.
Can you recommend a mobile DB to REST/Web API sync solution?
With the native Couchbase Mobile solution for Android/iOS coupled with the REST APIs you are able to get data from Mobile device to your backend. Then delete any documents off your device once you get back a 200 status.
For Windows Phone, you can explore using PouchDB or going with the javascript browser based solution across all platforms since WP is not currently supported.
For the replication or sync to occur when your device is online again, you would require your backend to use Couchbase Server and implement the replication class methods in your native mobile app to have the push feature. Or you can use the REST API with logic detection when you are online again to POST to your backend.
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.
to all
as we all know, Appscript tipicaly for Google Spreadsheet now have a UI builder, though you can compose UI with the script itself the builder is a big factor. now
GAS application is hosted in google drive and can be either share or publish as Webapp. which is great but this type of app is very limited to storing your data in a spreadsheet well, designing a good DB spreadsheet would be enough for small application but is NOT scalable for SME to Enterprise apps.
now having google app engine which have a very good and scalable platform for a webapp.
is there anyway to port the UI library capability and use it for app engine application. having GAS UI as a javascript base (client side) it could be integrated with any serverside language in GAE.
do any one have any example on this or is it now posible?
the way I see it this might be the future for GAE having a GAS as a client side library would be great?
Well, I think you should be looking the other way round. All of Apps Script's UI widgets are borrowed from GWT in GAE. In fact, the Apps Script documentation, at places suggests that we should lookup GWT documentation when this is found inadequate.
Coming to the point of the UI bilder, I'm no GAE expert, but since you get a GWT toolkit for Eclipse, you should be able to use any of Eclipse's UI creating tools ( I may be wrong here).
GWT is compiled to javascript. It doesn't care what the backend is. You can use json to communicate to your python AE instance just fine I would think. I do GWT on java AE so don't have an example of my own but here is an example of using python on AE to use App Scripts https://developers.google.com/apps-script/articles/appengine
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.
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.