I am developing a new application that integrates into Firebase.
My question is whether I should have the application connect directly to Firebase Database? Or should I develop my own custom API using Node.js and have my app connect to those API's? Or is it OK for my app to connect directly to Firebase Database?
The Client SDKs (JavaScript, Android, iOS) are especially made for directly connecting your app to Firebase services (Databases, Cloud Storage, etc.).
You normally combine them with some security rules, either to manage access control or to control the data that is written to the database.
If you have specific needs that cannot be implemented through the Client SDKs (and security rules) you could very well use you own APIs using the Node.js SDK: for example, implementing you own authentication/autorisation mechanism, implementing a complex business logic to verify data that is coming from the client app, or a business logic for transforming data that you don't want to expose in the front-end (aka "Secret sauce"), etc.
Here is an article from Doug Stevenson (Firebaser) comparing Client SDKs and Cloud Functions to write to the database that you should definitely read: using Cloud Functions is similar to implementing your own APIs in Node.js (Same language, environment that you manage).
Related
I am currently creating a marketplace mobile application from scratch and I'm using React Native for the front-end part and Firebase for the backend (using Firebase and Firestore).
I am wondering wether :
I should create a RESTful API using cloud functions and express to create API endpoints (that would connect to firebase and firestore) that I'd call from my redux actions in my React Native app (using redux thunk).
or, I should call firebase and firestore directly from redux actions.
I see couple pros and cons for each method.
Restful API pros :
Safer as I can check and manipulate submitted data more easily
Custom API reply (I can manipulate the return data)
Restful API cons :
Probably slower as I would have to call an API endpoint that will then call firebase and/or firestore.
Won't be as easy to set listeners on firestore data
What do you think about it ?
Which option should I choose knowing that I predict that the app will get a few thousand users daily. I want it to be as fast and safe as possible and be able to set listeners for notifications purposes.
In my opinion you should mix them, if you have to manage users, products or etc. Firebase produces client and admin sdk that has different roles. If you haven't need manage any data of products or users or etc. you can simply use client sdk.
My advise is you can use admin sdk on API (server-side) and feel free to use client sdk on your clients.
Use as managements on API, listening data, realtime chat etc. via client sdk.
You can check admin and client sdk. Also npm packages for React Native here.
Mixing will be of help, you can try:
Listen for small amounts of data using the client SDK
Write and sort data using the cloud functions
In my experience, writing to a firebase database that uses ordered ids (in my case) leads to some huge problems in the long run. I lost a good chunk of data when my app accidentally wrote to a root index instead of a child index when the app was resumed from inactivity because the android system cleared the RAM.
Also, for notification, use Firebase Cloud Messaging.
I have to build an API using Firebase, and need some help with design choices. I want to be able to sell the API to users, who can then use it to build/integrate their own applications. Users will have both read and write privileges.
General information:
I'm using Firestore db with email & password authentication.
Only specifically assigned users may use the API
Each user may only access specific documents concerning them.
I've noticed 3 different ways in which an API can be provided to a user of my Firestore db:
https triggered cloud functions (https://firebase.google.com/docs/functions/http-events)
Using the SDK (https://firebase.google.com/docs/firestore/client/libraries)
Using the REST API provided by Firbase (https://firebase.google.com/docs/firestore/use-rest-api)
API requirements:
Used only by users that I specifically grant access to (email & password login)
I want to limit these users to only a couple of read/write tasks that they're able to perform.
It needs to be safe.
My current approach is:
Use the 3rd option - the REST API provided by Firebase (thereby giving users the projectId and API key)
Add authorised users to the list of authorised accounts on Firbase, and limit access using custom claims and database rules.
My questions:
It seems that https functions (option 1) are normally used in API building. Are options 2 and 3 unsafe?
What are the normal use cases of the 3 options? When should each be used and when should each be avoided?
Are there any obvious flaws in my choice of option 3?
Any other useful information about making these design decisions will be much appreciated.
Thank you in advance
TL;DL: It depends on what you want to do with this API and how many and what type of devices/users will be calling it.
Before answering your questions I will list below the advantages of each approach:
Cloud Functions:
Cloud Function is a Functions as a Service Solution, so it's also a hosting service for your API, therefore you won't have to provision, manage, or upgrade servers and the API will automatically scale based on the load. Also this option takes into account the pros of SDKs and client libraries, since your code will have to use it to connect to Firestore anyway.
SDKs and client libraries:
This is the easiest and more optimized way to reach Firestore, however, environments where running a native library is not possible such as IOT devices will be left out of your solution, so consider this while implementing this option.
Cloud Firestore REST API:
Every device properly authorized to access Firestore will be able to do so.
NOTE: For both SDK and REST API you will need to consider hosting of your API, either on Cloud Functions, as mentioned, App Engine Standard, App Engine Flex or a Compute Engine Server Instance.
All that being said, it's up to you and your API's usage and requirements to say which option is best considering the points above.
As per security, I'd say that all option can be secure if firebase rules and firebase auth are set correctly.
I created my flutter application with Laravel passport api for auth, and now i want to use Firebase's Firestore for push notifications and messaging, how am i supposed to move forward?
All Firestore tutorials i find are joined with firebase auth.
Is there any way i can implement to actually let firestore work in parallel with laravel?
Keep your auth concern separated just like you have. What you're looking for is just FCM and there are some great packages for that I believe. I personally have built and implemented multiple back-end scenarios exactly like this.
An example of such would be as follows:
Back-End:
Laravel 7++
passport for auth (sometimes custom grants created for use case, e.g. SaaS)
fcm provider (custom self developed)
uses api routes exclusively, nothing goes through the web guard here (API First)
Front-End/App:
Angular 9+ / React / Vue2+
standard oauth using password grant (you should look into PKCE)
Flutter APP
standard oauth (custom built) with provider state management
Communication / Scenario:
Imagine flutter app and front-end like portal app in Angular, imagine your goal is to keep the data on both in sync? There are many ways to accomplish this, but also imagine that you really do not need any sort of stream, so what do you do?
You follow observer pattern that'll get you exactly where you wanna be. In this case I would simply choose Firebase Cloudmessaging and have my apps and pwa / spa subscribe to a channel.
Logic: (Passive aggressive reactive approach)
App 1 triggers an update of data
Back-end receives request, processes and triggers an update notification to channel
Other apps listening on that same channel (FCM) will go and call the API to get updated data.
So as simple as that you have created a very reactive system, and people won't know the difference that it isn't live streaming information from a -> b
I'm a little bit lost, I was reading the documentation on firebase and they have auth and other functions client side and server, what's the difference? I want to build a serverless web app. Can I do it all (auth, CRUDE) from the client?
Firebase provides SDKs that allow you to interact with its back-end services right from the client. This means that your (web) apps can read and write directly from Cloud Firestore, by using Firebase's JavaScript SDK for that.
You'll then use Firebase's server-side security rules to control what data each user can read and modify in the database. This typically means you'll ask your users to sign in, although this is not technically required.
Whether this is good enough to build your entire app without writing any server-side code, depends on the use-cases that your app covers. Typically I use Cloud Functions to run my server-side code without worrying about server administration, and I use it for:
Operations that require sensitive data (e.g. API keys for a payment gateway), or for which the code itself is sensitive (e.g. cheat detection for games).
Operations that require reliable computing power such as RAM, CPU, bandwidth or battery (e.g. scaling images).
Operations that I only want to implement once, and that can wait until the user is connected to a network (Firestore continues to work on their local device when they're offline).
Yes You can build a serverless app by using client side code only (example: swift + firebase Auth, Firestore, Storage etc).
However some feature or for security purpose you might need to write some cloud function code. Cloud function code are server side code which will never exposed on client side
I am trying to create a REST API for my app using Firebase Cloud Functions. I know how to use Admin SDK in Cloud Functions. It does have API to createUser. My front end app lets users sign in using Google and Facebook but I am not sure how to put it all together.
My app has successfully implemented Sign in with Google and Sign in with Facebook but how and what data do I transfer over to Cloud Functions (or any REST API Server for that matter) so that it could create a user in Firebase with appropriate provider.
Update for more explanation
I am creating an app for iOS and Android with some sort of cloud based backend. Right now I am experimenting with Firebase but I do not intend to tightly couple my apps to Firebase and hence do not want to pull Firebase-iOS and Firebase-Android SDKs into my app code. I want the ability and freedom to switch my backend over to AWS or Azure without changing frontend code.
The one (and only?) way is to create a server that will expose REST API endpoints and do the work on my behalf that usually SDK does. To achieve this, I am using Cloud Functions but that shouldn't matter as long as I have API to talk to actual cloud.
After putting that explanation, now my question is how do I let my users login to app using external providers like Google and Facebook and still achieve what I am trying to do. When I let users sign in with providers, I do not have their password to send to backend to create a new email/password user.
The sample code that best illustrates what you want to do here on GitHub.
It shows how to create an Express app that handles HTTP request pages. Learn more about Express to configure it for wildcards are needed.
It accepts and checks authentication tokens in HTTP requests from Firebase Authentication to validate the end user responsible for the request.