In the second part of my post, I’m going to concentrate on the backend and write about some services that are available in the Firebase.
In my application I’m using Firestore API directly. NoSQL database differs from the relational database, and if we are trying to apply SQL way of thinking, some of us could be disgusted. The important thing to remember about NoSQL databases is, that it has to be design based on queries that we want to make. There are also a few query limitations that we need to know about :
- No support for range filters in different fields. You can add two range filters but in the same fields only.
- Each query can be run only against a single collection of documents. because shallow by default when we make query for collection, we only get back collection.
- Not allowed to query individual members
- No logical “or” queries. We have to create separate queries and merge
- No queries with a !=clause needs to be split into > and < query
- “Where”, ”oderBy”, “Limit” can be combined. “orderBy” needs to match the “Where” clause that we are applying to.
- Indexes are required for queries. If the index is required Firestore returns an error that contains link to create index, so all documents fields are automatically indexed.
- In order to create a join query we have to query a different collection, then loop over the results of that query and then get all documents from that query in different collections. It is quite quick due to indexing.
- We are storing duplicate data and there is more disk space needed. “Consider that disk space is cheap, but a user’s time is not” – Firebase team
Firestore data consistency is important. What helps in achieving that is transactions. Transactions are a set of read and write operations on one or more documents for the max writes of 500 docs. The advantage of it that we have fast reads and fast queries, but the disadvantage is that writes can take longer because we have to write into more than one place. But in some cases reading data might be happening more often than writing.
Client Side security does not give us security at all, so to secure application on the backend Firestore offers security rules that allow us to control access to documents and collections in database. We can grant read and/or write access to individual nodes of the database. We define how secure our application going to be. To test our rules we can use simulator. There is good documentation available and provides more detailed information. The only small issue is with fields. The document is treated as the smallest building block of collection, so If we need to get into the specific field we are not able to test it on simulator.
I built the chat system using a Firebase. It is a real-time database. Stores data in the JSON tree. Uses key/value pairs. It’s generating id that is a timestamp. Data is life and all changes are reflected in real-time. The price for using it is based on GB downloaded not by reads/writes/deletes. It could be used when we want to client side lock on some part of the application. It Runs code in the cloud. There is no need for servers. It’s highly available and fault-tolerant. Google offers first 2 million invocations free. Cloud functions can write to any part of the app with full permissions. We have many possible ways to use it. We can use the Firestore triggers when specific function is called
- onCreate
- onUpdate
- onDelete
- onWrite
When any of these events happen we can trigger a cloud function to invoke. In my app I’ve used it for :
- Add an activity whenever a job post is created
- Add an activity whenever a job post is canceled
Google’s servers will listen for events and run the function when users create or post the job. That particular activity is going to be locked out and user is not going be able to modify anything there. In simple language cloud functions provide the opportunity to give server like functionality, that could be set up on the client side, pushed to Firestore, and then the action specified by us can take place.
Conclusion
In psychology, there is a term called decision fatigue that can occur when people feel exhausted from making too many choices. We generally like to have choices, but what psychologists discovered that when we must make too many choices in a short span of time, we may experience a type of mental fatigue. When we look at diversity technology that is available for developers, a huge amount of time can be spent to research what is an appropriate solution. Every application has a trade-off. We gain in one area and we can lose in another. Cloud Firestore even despite the limitation in comparison to SQL database is still powerful. Cloud Firestore was designed for automatic scaling, high performance, and could be right choice for some types of applications.
GitHub repository for my application :
https://github.com/Eric-WebDev/HandymanHire-App
Application available under the link :
References:
https://firebase.google.com/docs/firestore/
https://firebase.google.com/docs/firestore/security/rules-structure