I'm creating an events app with react native. I just wanted some advice on which would be the better more performant and scalable way to structure my data model in firestore.
I have 2 collections Events and Users.
A user creates an event which goes into the Event collection, In my app users can then go onto the main page and view a list of events from the events collection.
I also want to have a second page in the app a "users profile" page where users can view a list of their own events, update and delete them.
My question is which would be better:
to store the event's key in an array in users/user1
store basically a duplicate event in a subcollection called events in users/user1
I feel that option 1, might be better just to store a reference to the doc in an array, So I don't have duplicates of the event and if the user has to update the event, only 1 write has to be made to the actual event in the events collections.
the event is likely to have more fields come onto it in the future, like a comments field etc, so I feel by just going with option 1 I dont have to keep doing double work, although I might have to read twice i.e read users/user1- > (then array) events:[event:{dockey}], then use that key to get the actual event doc in the events collection.
Thank you for any feedback and advice
There is no simple right or wrong answer when you need to choose between these two options. Data duplication is the key to faster reads, not just in Firebase Realtime Database or Cloud Firestore, but in general. Any time you add the same data to a different location, you're duplicating data in favor of faster read performance. Unfortunately in return, you have a more complex update and higher storage/memory usage. But you need to note that extra calls in the Firebase Realtime Database are not expensive, in Firestore are. How much duplication data versus extra database calls is optimal for you, depends on your needs and your willingness to let go of the "Single Point of Definition mindset", which can be also called very subjective.
After finishing a few Firebase projects, I find that my reading code gets drastically simpler if I duplicate data. But of course the writing code gets more complex at the same time. It's a trade-off between these two and your needs that determines the optimal solution for your app.
Please also take a look at my answer from this post where I have explained more about collections, maps and arrays in Firestore.
Related
I'm working on a vue app that uses vuex and gets objects from an api. The tables have paging and fetch batches of objects from the api, sometimes including related entities as nested objects. The UI allows some editing via inputs in a table, and adds via modals.
When the user wants to save all changes, I have a problem: how do I know what to patch via the api?
Idea 1: capture every change on every input and mark the object being edited as dirty
Idea 2: make a deep copy of the data after the fetch, and do a deep comparison to find out what's dirty
Idea 3: this is my question: please tell me that idea 3 exists and it's better than 1 or 2!
If the answer isn't idea 3, I'm really hoping it's not idea 1. There are so many inputs to attach change handlers to, and if the user edits something, then re-edits back to its original value, I'll have marked something dirty that really isn't.
The deep copy / deep compare at least isolates the problem to two places in code, but my sense is that there must be a better way. If this is the answer (also hoping not), do I build the deep copy / deep compare myself, or is there a package for it?
It looks like you have the final state on the UI and want to persist it on the server. Instead of sending over the delta - I would just send over the full final state and overwrite whatever there was on server side
So if you have user settings - instead of sending what settings were toggled - just send over the "this is what the new set of settings is"
Heavy stuff needs to be done on the server rather than the client most of the time. So I'll follow the answer given by Asad. You're not supposed to make huge objects diffs, it's 2022 so we need to think about performance.
Of course, it also depends of your app, what this is all about. Maybe your API guy is opposed to it for a specific reason (not only related to performance). Setup a meeting with your team/PO and check what is feasible.
You can always make something on your side too, looping on all inputs should be feasible without manually doing that yourself.
TLDR: this needs to be a discussion in your company with your very specific constrains/limitations. All "reasonable solutions" are already listed and you will probably not be able to go further because those kind of "opinion based" questions are not allowed anyway on SO.
I created an App for projects and To Do lists. It consists of one HTML page, which only has an "add To Do list"-button.
The user can click on that button and create a To Do list, in this list he can create tasks.
The lists and tasks are dynamically generated HTML Elements.
Is there a way to just store everything, the dynamically generated DOM and all its elements and their functions? I searched for an answer for hours and all I found was a method to store data locally with localStorage: http://docs.phonegap.com/en/1.2.0/phonegap_storage_storage.md.html#localStorage
Since my elements contain a lot of js functions, it would be very complicated to store everything with this method...
Is there no way of storing "the whole thing"?
Thanks in advance!
Your question require a very large explanation, anyway I would tell you some tips you can use to step forward since I worked on a similar app last year.
Think about a database structure for your app. I got a table "Tasks" in which I stored both tasks and subtasks (task inside other tasks). I also stored alarms (if a task need an alarm), texts, checked/unchecked, archived flag, deleted flag, and so on. Everything you can associate to a task, you need a column for it.
Think about your data amount globally. If you plan to store a large amount of data (more or less 5MB) you better choose SQLite approach. If you think your data will not reach this edge, think about LocalStorage. You can google both to manage their use.
When the user fill the DOM to create a task and click on "create" (or something similar), you have to "scan" the DOM, acquire all info for the task created and put them into your DB
When the user want to update/modify a task, you have to find it in the DB, fetch related data, create the DOM's structures you need to show data, fill the structures with data
These are more or less few tips I can give you on your long way. Good luck
I have yet to find a relatively good solution for this. Maybe the community can help?
I'm pulling data into my meteor app from some restful end points. One builds on the other. For example..I hit one end point and get a collection of authors. then I need to hit a second endpoint to pull the books each of the authors have written.
Right now I have two separate publish functions on the server side to get the sets of data, however the second one relies on the data from the first. (My initial foray in my app was simply to do it all in one publish, but this felt like not the best architecture)
Is there any way to subscribe to another publish from within another publish server side? Or, some other method of checking that i can do?
So far the internet and stack overflow have yielded little results. I am aware of the publishComposite packages available.. but they seem relatively heavy handed and don't necessarily seem applicable to what I'm trying to do. Any advice would be greatly appreciated
i suggest a divide and conquer strategy. you have basically 2 questions to answer:
for the collections, am i going to do a client-side or server-side join?
what drives calling the remote service to get the new data?
i think you can build these pieces separately and tie them together with the db and Meteor's reactivity.
e.g. you can start by writing the code that hits the remote REST APIs. i think the strategy there is to make the authors call, get the data, then make the books calls. i would do that in one function, tied together with promises. when the book data returns, write it and the authors data to their respective collections (if you don't already have that data), ensuring the foreign keys are intact. now you can tie that function to a button press, and that part is done for now.
next you can move on to the collections and publishing that data. you'll have to decide, as i mentioned, where to do that join. but do the publish(es) in such a way that, per standard Meteor practice, when the collections update in the db, your client gets the updated data.
at this point, you can test everything is storing correctly and updating reactively when you push the button.
the last piece is to decide what drives the API call, to replace the button push. as i'd mentioned in the comments, perhaps a cron job, but maybe there's something else going on in your app that makes it more natural. the danger of putting in the publish, as i think you already know, is that you could get 50 simultaneous subscribes, and you don't want to hit that REST API 50x.
I've been writing a Component Entity System in javascript for a while now but I keep returning to a root issue.
How do you handle entity specific - that is to say a single instance or single type - functionality?
Here's the current situation:
The way I have structured things, when an item entity is stored in inventory by another entity it isn't destroyed, merely stripped of most of its components. This is so that if it is dropped, or perhaps retrieved for use, it can be reactivated with its old state. The components that are stripped are stored in an InstanceDataComponent attached to the entity (this is just a JSON object).
There is a small system for managing the internals of whether an item can be picked up and adding an inventory record with a hash, quantity, and id for the thing being stored but something needs to manage the transformation of that entity from its "item" state to its "stored" state. What should do this? It seems to me that the details of which component to remove and what data to alter will need to be nearly unique for each item.
Suppose that in the future I want an entity to switch between two behaviors on the fly. For example, to pace to and fro until it is disturbed then pathfind to the player. What will handle that transition?
I get the feeling I've got a fundamental misunderstanding of the issues and typical architecture here. What would be a clean way to handle this? Should I perhaps add a component for each set of behavior transitions? Wouldn't that end up with far too many components that are glorified callback wrappers? Or am I missing something about how an entity should be altered when it is stored in inventory?
Some thoughts for others who might be going through this situation.
My current solution (after several iterations) is to fire a global event e.g. itemPickupSystem:storedItem and an entity can attach handlers for any events inside its factory method. This isn't scalable, for a number of reasons. I've been considering moving those events into a queue to be executed later.
My factory methods have turned into a hodgepodge of callback definitions and things are degrading into callback hell. In addition, this events system has to go, it is the only part of the entire system that breaks the serial nature of the game loop. Until now each system fired in a defined order and all logic resided inside those systems. Now I can't guarantee that an entity will be in a specific state because those callbacks could have been fired at different points. Finally, because execution is being turned over carte blanche to code that isn't part of the core functionality there is no way to know how large that call stack will get when an event is fired.
Sometimes it's easiest to think of this problem in terms of pragmatic network replication, and the boundaries between components come naturally.
Let's say that your actor can both wield, and store, a sword.
I would not anticipate a 'transform' from an inventorySword into a presentationSword, but rather that there's a natural delineation between an 'inventoryItem' and a 'swordPresentation'.
On the server, each player would be assigned a list of items in their inventory. Each item would have a unique id for the world. The inventory item might be derived as 'SwordItem' and have properties for SwordType and Condition%
On the client, a 'swordPresentation' component might handle the job of which mesh to display, which socket to attach animation data to when displayed via a 1st person camera, and how to smooth animation transitions. But none of that matters to the actual state of the game, it's simply how our client is seeing the world.
Potentially, if you were distributing the state of the game to each client all that you would pass over the network would be the current player's inventory, and for the other players, which item each player has currently equipped and where they are (assuming they're in eyesight)
So, consider creating a factory that creates a 'swordPresentation' based off of an inventory item, finding the bare minimum you can pass in as parameters to create a representation of the component (maybe it's sword type, sword % condition, etc).
Whatever that bare minimum is what you want to serialize as your inventory item.
Establishing a clear delineation between replicated data means better performance, fewer vulnerabilities when you're writing a multiplayer game. When you're writing a single-player game, it'll help you understand what goes into a save file.
I am trying to create a car make/model form using Javascript or AJAX, problem is that I don't have a lot of experience with either, but here it goes. . .
I need to create a form that has a car make and model drop down list in it, and when a user chooses a specific make, the model drop down will be populated with all of the models for that make, now I have a few ideas on how to accomplish that, but I would like some input on what the best way would be to approach this, to cut down on dev time.
I was thinking of creating an array within an array, one with the makes, and within each "make" array have the models array in there, so when the user clicks on a make, a AJAX/Javascript function will fire which will take the value of the current field and use that to get the location of the make in the array, which will then traverse through the inner models array and generate the drop down menu for that specific make.
Now I am not sure if this is a sound idea, or if there is a better way of doing it, but I have very little time to test, so process of elimination is out of the question, so could someone please point me in the general direction I need to go in, or maybe point me to a ready made script? as my understanding of Javascript syntax is little to none at the moment!
Thanx in advance!
The key decision is whether you want to load all of the information at the beginning (in which case the user may experience a delay while you load all of the models for the makes that they don't care about) or whether you want to retrieve the models as they choose a make. The answer will depend on
how much data there's likely to be
how fast you need the page to be
how much load will be on the server
etc.
Basically, can you afford the performance impact of loading all of the models at the beginning?
If you decide that you can afford to load everything at the beginning, I think the approach you describe is reasonable, although I wouldn't actually use an array for the outer container. I'd do this:
var models = {
Audi: ["Quattro","A4", ...],
BMW: ["M3", "M6", ...],
...
};
The thing stored in the "models" variable is actually a javascript object, although people do sometimes call it an "associative array".
Note that in this scenario you aren't really doing "AJAX", as you aren't retrieving data from the server on-the-fly.
The alternative scenario is that you set up a URL where you can query it with a model, and it will respond with a list of makes. Then you fire off the query when the user selects a model. That's AJAX.