I have the intention to deploy a small react single page app for educational purposes and wanted to test something new. Firebase seems like a good option especially because it offers free tier. However there is something that is bothering me, the free tier's cloud functions only support node.js 8 which is obsolete . I plan to use the NoSQL database and hosting options offered by firebase. Correct me if I am wrong but if the CRUD operations are made by a react hooks there is no node.js involvement and therefore no cloud functions are needed? Basically the CRUD is done by the user's browser because he runs the react app .js files and this means that I can safely use the free tier?
If you are just performing queries directly to Firestore or Realtime database from your web app code, then you don't need Cloud Functions at all, and do not need to enable billing on your project. This is should be easy to try for yourself - simply follow the instructions in the documentation for the database you've chosen.
Related
I am beginner on firebase and need some help with project decision. I am building a react native app for someone and for the database I was thinking of using firebase, but when I was going through the docs I realized that firestore offers Backend Service, does this mean I don't have to use any framework for the backend. I was originally planning to use Django but if firestore provides backend service, it will provide lot more ease to the project. Can anyone give me an explanation on this ?
You can indeed directly connect your ReactJS application to Cloud Firestore, bypassing the need for your own server. To secure the application you'd use Firebase's server-side security rules, which allow you to control who can read and write what data. This is of course extra important, since you're opening up the database for direct access from the client applications, and the rest of the internet.
To access Firebase from React Native, many developers use the react-native-firebase library, which wraps more Firebase services than the JavaScript SDK does.
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
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.
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.
I am building an angular app and the next step is to put it on GAE and I was wondering what backend should I use. I have my html pages ready I just need now to set up a backend so I can store and retrieve data for my little project. An information on this would be great. I don't think I would need to use jinja for this.
Well, as you say, Angular will be used for UI. For the backend, GAE being PaaS, it gives you number of services. One of the services is persistence. It's done using either the Data Store Service (NoSQL) or Google Cloud SQL. You can also make REST API around your persistence and business logic in the backend using Google Cloud Endpoints that you can use in JavaScript client.
To develop the backend and make use of these services you have many options: PHP, Python, Java, Go, ... . You can pick the one you like and more familiar with.
If you decide to use Java, you may want to take a look at Objectify. It makes your persistence code simpler and clearer than using the Data Store API directly. Also Google Plugin for Eclipse will make it much easier for you.
Note that although I used links here for services in Java, there are similar pages for python and other languages too. So you can use the same services in your favorite language.