I've never used Firebase (or Firestore) before and I'm considering using it for my new mobile application. And I'm wondering if using Firebase only, without any additional server is a good idea. Firestore does a lot of things I guess, like authentication, security and scalability. So I really hesitate putting an another server into Architecture. But I have a plan to do many server-side stuffs like searching for text or calculating something.
I think the answer is "it depends", but I want to hear some advices from people who have used Firebase before about this topic. Thank you in advance!
Is it a good idea to use an additional server with Google Firebase?
Firebase will help you build apps fast, without managing infrastructure. So you'll be able to focus on your app development and not on how to maintain servers. Perhaps, if you have requirments that Firebase cannot handle, which I doubt it, you can use an additional server.
I've never used Google Firebase (or Firestore) before and I'm considering using it for my new mobile application.
If you have never used the Firebase suite, I recommend you get started by reading the official documentation. Before starting to use Cloud Firestore, I recommend first get more familiar with NoSQL databases.
And I'm wondering if using Firebase only, without any additional server is a good idea.
There are many apps out there that are not using any other server than Firebase.
Firestore does a lot of things I guess, like authentication, security and scalability.
Firestore is a scalable NoSQL cloud database that allow you to store and sync data for client- and server-side development. It does not authenticate users. For that, there is another product named Firebase Authentication that I encourage you to use it.
But I have a plan to do many server-side stuffs like searching for text or calculating something.
Here you can find more details about Firestore search options. Regarding calculations, you can do pretty much everything you can do in a regular SQL database.
How can I make sure my firebase realtime database data is not accessible (read or download) via REST or any other way ?
I am very concerned about this as it seem to be a common way (not to secure properly your database) to steal data from apps.
My nodes all have the same security for reading : authentification required.
Thank you !
It sounds like you've left the default security rules, which simply require a user to be signed in to be able to read/write all data. While this blocking of unauthenticated users is a good first step, there is probably more you can do.
The Firebase documentation explain how you can use Firebase's server-side security rules to precisely control what data each user can access. I highly recommend also watching the video in there, for a good introduction of what mindset to have while thinking of securing your data in this way.
Ok so I found the exact answer I was looking for : if you want to download data that needs authentification with REST, you need a token.
So to sum up : No, 'simple' users can not download nodes that are protected by security rules, they also need a token that only the admin can generate.
Please feel free to correct me if all the above is wrong
Let's say I'm developing app like Instagram: for iOS, Android and Web. I decided to use Google Firebase as it really seems to simplify the work.
The features user needs in the app are:
Authorization/Registration
Uploading photos
Searching for other people, following them and see their photos
I come from traditional "own-backend" development where I do need to setup a server, create database and finally write the API to let the frontend retrieve the data from the server. That's the reason why it's unclear to me how it all works in Firebase.
So the question is how can I create such app:
Should I create my own API with cloud functions? Or it's ok to work with the database directly from the client-side?
If I work with the database directly why do I need cloud functions? Should I use them?
Sorry for such silly questions, but it is really hard to get from scratch.
The main difference between Firebase and the traditional setup you describe is that with Firebase, as far as the app developer is concerned, the client has direct access to the database, without the need for an intermediate custom API layer. Firebase provides SDKs in various languages that you would typically use to fetch the data you need / commit data updates.
You also have admin SDKs that you can use server-side, but these are meant for you to run some custom business logic - such as analytics, caching in an external service, for exemple - not for you to implement a data fetching API layer.
This has 2 important consequences:
You must define security rules to control who is allowed to read/write at what paths in your database. These security rules are defined at the project level, and rely on the authenticated user (using Firebase Authentication). Typically, if you store the user profile at the path users/$userId, you would define a rule saying that this node can be written to only if the authenticated user has an id of $userId.
You must structure your data in a way that makes it easily readable - without the need for complex database operations such as JOINs that are not supported by Firebase (you do have some limited querying options tough).
These 2 points allow you to skip the 2 main roles of traditional APIs: validating access and fetching/formatting the data.
Cloud functions allow you to react to data changes. Let's say everytime a new user is created, you want to send him a Welcome email: you could define a cloud function sending this email everytime a new node is appended to the users path. They allow you to run the code you would typically run server-side when writes happen, so they can have a very broad range of use-cases: side-effects (such as sending an email), caching data in an external service, caching data within Firebase for easier reads, analytics, etc..
You don't really need a server, you can access the database directly from the client, as long as your users are authenticated and you have defined reasonable security rules on Firebase.
In your use case you could, for example, use cloud functions to create a thumbnail when someone uploads a photo (Firebase Cloud Functions has ImageMagick included for that), or to denormalize your data so your application is faster, or to generate logs. So, basically you can use them whenever you need to do some server side processing when something changes on your database or storage. But I find cloud functions hard to develop and debug, and there are alternatives such as creating a Node application that subscribes to real time changes in your data and processes it. The downside is that you need to host it outside Firebase.
My answer is definitely NOT complete or professional, but here are the reasons why I choose Cloud Functions
Performance
You mentioned that you're writing an instagram-like mobile device app, then I assume that people can comment on others' pictures, as well as view those comments. How would you like to download comments from database and display them on users' devices? I mean, there could be hundreds, maybe thousands of comments on 1 post, you'll need to paginate your results. Why not let the server do all the hard work, free up users' devices and wait for the results? This doesn't seem like a lot better, but let's face it, if your app is incredibly successful, you'll have millions of users, millions of comments that you need to deal with, server will do those hard jobs way better than a mobile phone.
Security
If your project is small, then it's true that you won't worry about performance, but what about security? If you do everything on client side, you're basically allowing every device to connect to your database, meaning that every device can read from/write into your database. Once a malicious user have found out your database url, all he has to do is to
firebase.database().ref(...).remove();
With 1 line of code, you'll lose all your data. Okay, if you say, then I'll just come up with some good security rules like the one below:
This means that for each post, only the owner of that post can make any changes to it or read from it, other people are forbidden to do anything. It's good, but not realistic. People are supposed to be able to comment on the post, that's modifying the post, this rule will not apply to the situation. But again, if you let everybody read/write, it's not safe again. Then, why not just make .read and .write false, like this:
It's 100% safe, because nobody can do anything about anything in your database. Then, you write an API to do all the operations to your database. API limits the operations that can be done to your database. And you have experience in writing APIs, I'm sure you can do something to make your API strong in terms of security, for example, if a user wants to delete a post that he created, in your deletePost API, you're supposed to authenticate the user first. This way, 'nobody' can cause any damage to your database.
It is unclear whether or not to set security rules for database.
Is it enough to just let in just authenticated users? Do I need more complicated things? I have android app, and do all validations and updates inside app.
The video from IO says that there is possibility that someone can get all your data if he knew your app ID. So if user is authenticated and have app ID and somehow build web app he can get data too? I mean if using simple rules.
I`m asking for risks when building just android app and using simple rules (auth is on).
Is it ok for you if any user could edit/create/delete any data in your Firebase database? If this is not ok, you need security rules (you probably need them)
Firebase's security rules are really powerful and easy to use, I suggest you take a look at the documentation.
You need user id or role specific rules, otherwise somebody for example can easily wipe out your all data, or easily manipulate anything.
I want to setup a public form to write to Firebase via the Angular Firebase plugin AngularFire but it feels like there needs to be some security added so that data is only posted from that form, I can't see any interface to Whitelist a Domain/URL. Is there a way to only accept writes from a specific Form/URL without getting the User to login first?
Nope.
But it wouldn't help in your scenario anyway: when you're using Angular, all code is running in the user's browser. It might be served from your domain into that browser first, but just as easily the user might have saved the HTML locally and started running it that way.
It sounds like you're trying to secure things so that only your code can modify them, probably because you think that your code is the only thing that can be trusted to follow some of your application-specific business rules. Instead of trying to limit access to just your code, I'd instead recommend capturing the business rules server-side. Firebase has a very powerful security and data validation model just for that purpose. See https://www.firebase.com/docs/security/guide/
Once you enforce these business rules on the server, it doesn't matter how someone access your data. They could be using your code - or somebody could have taken your code (or an API that you've documented) and written a third-party application. Either way: the (security and validation) rules will be enforced by Firebase, so your data will stay valid and secure.