I recently found out about Google Firebase and how it can be used to help streamline back-end development. I would normally use PHP and MySQL for my back-end development. I have a few different apps that I'll be starting within the next few months, but I would like to develop my back-end a little faster and be able to manage it a little easier. Is Firebase a good alternative if I don't have super complex back-end needs?
Yes
because it's a cloud-hosted database.
Usually, the Data is stored as JSON and synchronized in realtime to every connected client which is good for your back-end development . Imagine you are building a cross-platform apps for Android, and JavaScript SDKs, all of your clients share one Realtime Database instance and automatically receive updates with the newest data.
You have everything explained here
Cloud Functions for Firebase
Related
I'm trying to build an offline first web application using couchdb and pouchdb as the backend/frontend databases, AngularJS as the frontend framework and expressjs/nodejs as the backend server. The problem is that what I'm used to is the backend-MVC mindset of building web apps, and not to SPAs, offline-first design, or having only json apis on the application server.
The problem I see with the design I'm considering is that I don't see any role of the nodejs server except serving static files. The frontend would get data from the pouchdb database which would sync with the couchdb database backend. I need an offline-first application capable of working locally when there's no connectivity and syncing when connectivity is available, so this is important.
But where do I implement the important bits of application logic that I need in the backend, like form input validation or user access control? I found some ways to embed logic in couchdb databases (like using filters as shown here) but somehow writing application logic in the database doesn't feel right.
What part of the big picture am I missing here?
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 am developing a web app (HTML/CSS/JS) destined to be used as is and also compiled with phonegap for iOS/Android/and others. I am loging my users using OpenId Connect.
I am looking for a database hosting service. It should be NoSQL, readable/writable by jquery and scalable.
I need to store the user's contact info and other user choices from my app.
I am thinking about using Cloudant with a CouchDb database, but I am really new to this.
Can you help me ?
Thanks
If you would like to use Amazon Web Services, take a look at Dynamo DB. It is infinitely scalable. You can start for almost free and pay more as and when your data-size and request load increases. It can guarantee you the same low response time even with huge data.
You can use this from JS as well
I have discussed some other options in this other SO thread - Parse, Firebase, Dropbox DataStore etc. Have a look: Storing and retrieving data in the cloud and retrieving via webservices:
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.
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.