I have a Flutter app (still in development) that currently uses Firebase for the backend. More specifically, I use Firebase Authentication, Storage, Cloud Functions, Firestore and in the future I am willing to use Remote Config, Dynamic Links, Cloud Messaging and more of Firebase's features.
I got to a point where Firestore is not enough anymore for my purposes: Full-text search, geographical querying and advanced queries in general. I know that I can use 3rd party services like Algolia for this but It's too expensive and I wanted something already integrated with my database.
I was thinking of start using MongoDB as my database (while keeping all other Firebase services) but before I do that I need to understand what is the best way to do it.
Can I host MongoDB on Firebase Hosting (I don't know if this possible at all?) or just use MongoDB Atlas and access it directly (See my next question) from my application?
What is the best way to connect my application to MongoDB? From the app directly (using Rest API) or using Firebase Cloud Functions (so I won't expose my database)?
Can I use Firebase Authentication tokens to access MongoDB or do I have to use MongoDB's authentication service?
If there is more things I need to consider before I start switching to MongoDB please point it to me.
Firebase Hosting is a CDN for hosting static websites. So it is not possible to host an application like MongoDB server. You can't host MongoDB on any Firebase services. You have to deploy it somewhere else. There are several options. You can either get a VPS and install MongoDB server on it. But you will have to manage your own DB which can be difficult and can take quite some time. Another option is to use a Cloud Database like MongoDB Atlas. This is a faster and more secure solution. However, pricing can be high. So you have to decide depending on your needs.
Once you have a running MongoDB server, you need to write an API for client apps to communicate securely. Client apps should never talk with a DB instance directly. In this case you can use Firebase Cloud Functions to create an api.
You can use Firebase Auth service with Firebase Cloud Functions. You should have a look at the Firebase Callable Functions which can pass auth context to the function body. Here you can just ensure the user is authenticated or perform some access control logic depending on your authorization needs.
Overall, you are going to add an another layer to your architecture. It is possible but will take your time to set things up and you will loose some firestore benefits like offline persistency.
Related
This question already has an answer here:
Why is it okay to allow writes into Firebase from the client side?
(1 answer)
Closed 3 years ago.
If I use the prod environment variables in my App and set the server side rules for Firestore, would my app be completely secure to perform CRUD and authentication? I am asking this because I have been seeing Angular tutorials by pretty famous YouTube content creators (Fireship) and they do not touch server side code and still show how to make a production applications. All the tutorials use only Angular and some libraries to produce the apps and features but then the console on Google says not to expose the API keys. Using only client side Angular even in production environment variables exposes the private keys right?
So in short, should I be using Node to CRUD and Auth with Firestore, or server-side rules on the console works safe?
The configuration that you use on the client to get it to communicate directly with Firebase services is does not include a private API key. Much has been said about this in various forums over the past few years. The thing you see that might be labeled an API key is actually public information. It helps the client library locate the project it's working against. The API keys you want to hide are those that exposed direct access to other billed services, including Google Cloud service accounts.
You limit access to Firebase backend services (Cloud Firestore, Realtime Database, Cloud Storage) using security rules to determine what a user can or can not do with the data stored in it. If you don't do this correctly, you could have problems.
Whether or not you want to let the client access the services directly or make the client go through some middleware you write should be decided by other reasons, as discussed in this article.
I am considering using Firebase/Firestore and Mongodb together for data storage. The idea is to use Firebase to store data that users will interact with on mobile and use MongoDB for more backend stuff or web content that won't be accessible on the app.
I've found a lot of people switching between the two, but very few topics discuss using both. Is there any reasons why this isn't done more often?
Currently I need to create admin ui, using google cloud datastore as user storage, and google functions as controllers.
I found the Keystone JS CMS platform, which uses mongoDB for storing user data, so I am looking for the chance to use it with google cloud datastore.
Is it possible to create some driver that will redirect all the keystone db requests not to mongodb, but in Google Datastore?
The core of Keystone is built on top of Mongo (and Mongoose) functions and code. At the moment, there isn't another way to use Keystone with another database type or provider. See this GitHub issue for some more information that may be of use.
I have an Ionic app which is configured in parse.com backend. How can I change it to work with Firebase backend or is there any alternative for parse.com backend? I tried back4app.com but it can't read my cloud code.
Firebase is totally different from Parse.com so if you want to move to firebase you will need to refactor all your client business logic which interact with Parse.com services. A very good alternative is to use parse-server which is the Parse.com open source. parse-server can be deployed to any cloud which support NodeJS runtime.
Please note if you decided to go with parse-server or with back4app you need to do some modifications to your cloud code and your client side code. The best is to follow the documentation which available under the parse-server github page that i mentioned above. Another good resource is this one which collect all the stuff related to parse-server and how to use parse-server in development or production
I'm trying to create a back-end in which I can have many users communicate with each other amongst an iPhone app I'm creating. I've tried working with Core Data, Google App Engine, Google Cloud Storage, and Amazon Web Services (RDS & Elastic Beanstalk). Unfortunately, after weeks of trying to get any of this working, none of it will!
I've been trying to get in touch with someone who would know how startups (when they were little) like Instagram, Path, and Pinterest have managed to do this. But everyone out there seems to despise this stuff as much as I'm growing to...
I would love for someone to simply map out EXACTLY how I need to create a back-end database that I can save and query data to and from that many users can see. That means that just SQLite, Core Data, or Parse by itself isn't going to work here!
A tutorial of some kind would be incredible.
First off, technologies like CoreData and sqlite are typically local device storage. Local device storage is not going to get you shared cloud storage.
Parse.com is a fast way for devices to access cloud storage and get going fast. Especially useful for games and other mobile apps to access cloud data via an app id and app key. It's simple storage to avoid creating your own backend if it fills all your needs and requirements.
When you get to a multi-tenant cloud backend where you roll your own services and multiple devices accessing your cloud application you need to look into exposing your web API. Exposing RESTful API over http is great for devices and web clients. Exposing the data as JSON is especially conventient for the web and easily consumed by devices.
Those web service end points in the cloud access some sort of backend storage which is optimized for concurrent access by mutliple clients. This is typically a SQL backend like MySQL, SQLServer etc... or a NoSQL solution like mongodb, couchDB, etc...
Some front end web api technologies to look into:
ASP.net web api
Ruby on Rails
Node.js
etc...
Some back end storage technologies to look into:
SQL: MySQL, SQLServer/Azure SQL, Oracle
NoSQL: MongoDb, CouchDb, Amazon S3 simple storage, etc...
If the data is used by many many multi-tenant clients, the backends can scaled up (larger and larger) or get sharded. Sharding is where the data for multiple users is split into many databases or datastores with some sort of lookup algorithm for requests to find where that users data is stored. The front end web api servers abstract the backend storage.
Finally, you'll end up needing some sort of caching/fast lookup technology (if you're successful :):
Redis: fast in memory storage over sockets
memcached: facebook uses - simple key value in memory caching across many front end servers.
Your question is an open ended up broad question so start by googling many of these terms and technologies.
Each of these links will have resources and tutorials. Get a cloud VM, play with each and decide which fits your needs best. There is no one size fits all solution.