I'm developing an app to help on events how much sales a single event has done and some other features that doesn't matter directly to the problem.
So, I've done an attempt to use Firestore to save my data, but something is saying to me that I was using the wrong way. Every event has something around 2k ~ (20k ~40k) entries of sales entries. Firebase Realtime Database doesn't seem a good idea because of data duplication needed for the relations I need to create.
The most important part of the Techstack I'm using:
React Native
React Native Firebase (native solution for react native on firebase)
Redux
The problem is that whenever I try to retrieve those documents for, let's say a custom report for my clients, the app just crashes or freezes entirely. Talking to other developers, they said to me that maybe Firestore is not a good solution for my case because of this 'sort of' big data retrieving.
Structure
Organizations/organization_id
Org_name
members (Array of userIds)
Events/event_id/
Event Name
Event sales data (Array)
Event product list (Array)
Event Date
Event attendees (Array of Attendees (name, pin (int))
Organization name
I've checked also that Firestore has a limit of 20k registries or entries per document (something like this). A friend of mine who have more experience told me that an SQL database an a normal API would probably solve the problem, but maybe require more work as I am a single developer.
Do you think that Firestore is a good solution and I was probably using the wrong way?
Or would say that Firestore is not the case for this problem where I would have to save and retrieve data with such relationships?
Related
I need help understanding the best approach to structure my firestore data.
I come from traditional SQL background and have a little bit of nosql mongodb background as well. I am building a small football prediction app and here is the user flow:
User:
User registers/signs in
They can pick a contest to join
Enter their predictions every week
Admin:
Create contests and add/edit games to contest every week (an api will fetch all the data like fixtures and results)
Set a deadline for when users can enter their last prediction for the game week
Other:
Leaderboard
Now I did create a diagram on how I would traditionally structure this data but it would be nice if someone can exaplain to me the simplest approach to structuring such an app in Firestore
It looks reasonable but I would be concerned about storing the passwords in Firestore DB. Firestore should not ideally be concerned with authentication. Check Firebase Authentication for different auth options with Firebase. You'll probably end up only having to store the user ID as other information is in the User object.
Also check out Supported data types. You probably want to change varchar(x) to (UTF-8) string or byte types. Moreover, there is a reference type so you could reference the actual user document from the other tables.
One main design will be whether to use nested collections (Hierarchical Data).
You might be able to nest score under competitions.
I'm trying to make a simple React app that uses Cloud Firestore for user auth and storing data; something that I could serve using heroku or something like that.
I'm running into trouble with enabling a user to delete their account (and associated data), as Firestore tells me that it's a bad idea to delete collections from the client side. Here's what they say:
Deleting a collection requires coordinating an unbounded number of individual delete requests. If you need to delete entire collections, do so only from a trusted server environment. While it is possible to delete a collection from a mobile/web client, doing so has negative security and performance implications.https://firebase.google.com/docs/firestore/manage-data/delete-data
While I might be able to delete the document connected with the user's account, this suggests that I can't really delete the sub-collections under that document.
So what would be a good way of automatically removing both the user document and user sub-collections? Can I achieve this through my react code? If not, is there a relatively easy way to do it without building a fancy back end?
Well, the documentation never says that this is not possible, just not recommended.
This makes sense if you consider that if you want to delete everything, including documents from subcollection, you would have to create a logic that will do this one by one, which is a very read intensive process and all of this data processing happening in your webapp is not a good practice, it might slow your app down or even block functionality while this process is occuring, etc.
What I would recommend for you is to follow the recommendations of Firestore itself, which is to create a Callable Function that will perform this actions for you, all processing will be done by that function and this will not degrade your app performance, you can find more details in this documentation.
Okay so I’m need guidance on where to start.
What I want to do is upon clicking a button in my web app which will be labelled “search” the web app will connect to my realism database and search the data base for the “search criteria” and the once found all matching cases it will create div blocks with the information inside it, in a list view and assign the ID of the div to the UID it gets back from the database.
database:
Users
--> Country
---->State
----->City
------>Post/ZipCode
------->UID
--------> Users informantion
Welcome to StackOverflow!
A great place to get started is the Firebase Realtime Database doocumentation or searching for Firecasts on YouTube (linked below).
As requested, here are some questions to ask yourself to get started and help scope out and define your new Firebase project.
What language are you going to use?
Are you planning on using any frameworks/libraries? e.g. For Javascript, these would include things like jQuery, Polymer, and React
What information are you storing in your database? e.g. user profiles, private user data/settings, public indexes, username lists, etc.
How is your database structured?
What data is being searched? The entire database? Values in a certain location?
What data needs to be displayed in your view?
Is the data accessible for just the current user or is it a public database that anyone can use?
What search criteria will be used? Is it just one filter at a time or many?
The answers to these questions aren't set in stone, but are to help you start thinking about the future of your project. They can be changed at any time as this isn't SQL where everything has to have its own schema.
If you intend on using "advanced searches" where you'll filter by multiple parameters at the same time, consider using Cloud Firestore instead.
I recommend looking at some Firecasts to help guide you through these questions. Here are some links to them:
Firebase YouTube Channel
Video: Getting Started with the Firebase Realtime Database on the Web
Playlist: Firebase on the Web
To practice using Firebase for large-scale applications, I'm making a Firebase app that has multiple chat rooms, similar to Firechat.
Theoretically there could be millions of chat rooms, each of which has millions of messages.
I would like to be able to display a list of chat room names, including some metadata about each chat room such as its number of participants.
The simplest way from a coding perspective would be to load all chat rooms, but that could be a tremendous amount of data.
My solution is to have an array of Chats and an array of ChatInfos. The former will contain all the chat messages, and the latter the metadata about each chat.
My question is: How can I update an item in one array and be sure the corresponding item in the other array is also updated without relying so much on the client?
My current solution is this:
var chatData = {room_name: "Test Room"}
var chat = Chat.ref.push(chatData);
var chatMeta = ChatMeta.ref.push(chatData);
chat.update({chat_meta_id: chatMeta.key});
chatMeta.update({chat_id: chat.key});
This works. However, it feels to me like it relies too much on the client.
For instance: What if the client's Firebase connection dies after the Chat has been created but before the ChatMeta has been created? Of course Firebase is near-instantly fast, but relying on front-end code to sync things up on the back-end feels like bad practice.
One solution would be to have all "write" requests go through a back-end server I control, and then go to Firebase. But the whole "no back end!" thing is such a big selling point for Firebase that I wonder whether that can be avoided.
To my mind, there should either be some way of doing a "shallow" query of all the different Chat items so that keeping a running list of ChatMeta data is unnecessary, or some kind of rule set up on Firebase's end that updates ChatMeta whenever Chat is updated. However, neither of those seem to exist.
Thank you!
You can avoid both relying on the client too much and having a controlled back-end server by using Cloud Functions.
In this case, you'd create an HTTP TRIGGER function and you'd push your room_name to it from the client. The cloud function would perform your requirements and return the ChatMeta object.
Im using Parse to save data from my social network. So far I have three class: Users, Posts, and Relationships. I want the user to be able to like a post.
Should I create a new table for Likes. If so, then on my storyboard page I would have to query through Relationships to get the user followers, then Posts to get the posts from the followers, and then Likes to get the likes from those posts?
Is it efficient to have three API requests to parse on one page. I feel like this will slow down performance but I'm not sure how else to save likes.
Another thing is, I would like to display a notifications tableView. So all likes and requested follows. So Im guessing I would save likes in Relationships and just query through it twice on the storyboard to first get followers, then likes. And on the notification page, have one class to query though once to get all recent notifications.
What are your suggestions?
Thanks.
This is sort of a broad question so there is no way that I could say for sure, but I do have a couple suggestion that you can do with parse.com.
Use the local datastore: You can save all of the likes that the user has in the local datastore as well as in the cloud of your application. So, for instance, you create the like when the user likes something, save it to the cloud, and then pin it to the local datastore. That way, you can efficiently query all of the likes that your user has created without using an API request. But in the event the user logs into the app somewhere else, you also have the likes in the cloud to retrieve. So, I would create a new table for likes.
You could use a join table to implement the followers, so, you could also pin the followers of the user to the local datastore like you would for a like. This is like is done in the Parse.com anypic tutorial.
I would also have another table for notifications. In cloud code, you could even update how many notifications the user has with an afterSave method, and then get all the notifications through a query when requested by the user.