Im new to Firebase, I have Structure my Data on firebase using Indices for maintaining relationshi as described in below articles
https://www.firebase.com/docs/web/guide/structuring-data.html
https://www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html
I just want to clear my retrieval concept on firebase.
as mention in above links
{
links:{
link1:{
title:"Example",
href:"http://example.org",
submitted:"user1",
comments:{
comment1:true
}
}
}
}
when I access link1, response contains link1 data as well as comments: {comment1:true}. Instead of comment1 actual text, accessing link1 gives comment's ID i.e, comment1. its mean when I access link1, it gives me the Ids of comments belongs to that link. so I have to retrieve comments mannually requesting firebase again based on comments ids received in link1 response? Please clear my concept : )
Yes, your concept is correct, you will flatten out the data in firebase and then retrieve comments by using the id from the previous read
Related
Just trying to fetch the creativename for creativeTypes = SPONSORED_INMAILS AND SPONSORED_VIDEO out of the LinkedIn API but I'm only able to receive creative names of SPONSORED_STATUS_UPDATE type.
In the doc I can only read fetching data for SPONSORED_STATUS_UPDATE by using the projection variable.
https://learn.microsoft.com/en-us/linkedin/marketing/integrations/ads/account-structure/create-and-manage-creatives#sponsoredvideocreativevariables
Does anyone have an idea how to get the creativename (subject) for SPONSORED_INMAILS AND SPONSORED_VIDEO?
I know It's a little bit late but with this endpoint, you can retrieve info on a video add
https://api.linkedin.com/v2/adDirectSponsoredContents/{{videoAddReffrence Urn}}
You can find the video Add reference Urn under the endpoint
https://api.linkedin.com/v2/adCreativesV2/{{add Id}}
under the key 'reference'
My application use keywords extensively, everything is tagged with keywords, so whenever use wants to search data or add data I have to show keywords in auto complete box.
As of now I am storing keywords in another collection as below
export interface IKeyword {
Id:string;
Name:string;
CreatedBy:IUserMin;
CreatedOn:firestore.Timestamp;
}
export interface IUserMin {
UserId:string;
DisplayName:string;
}
export interface IKeywordMin {
Id:string;
Name:string;
}
My main document holds array of Keywords
export interface MainDocument{
Field1:string;
Field2:string;
........
other fields
........
Keywords:IKeywordMin[];
}
But problem is auto complete reads data frequently and my document reads quota increases very fast.
Is there a way to implement this without increasing reads for keyword ? Because keyword is not the real data we need to get.
Below is my query to get main documents
query = query.where("Keywords", "array-contains-any", keywords)
I use below query to get keywords in auto complete text box
query = query.orderBy("Name").startAt(searchTerm).endAt(searchTerm+ '\uf8ff').limit(20)
this query run many times when user types auto complete search which is causing more document reads
Does this answer your question
https://fireship.io/lessons/typeahead-autocomplete-with-firestore/
Though the receommended solution is to use 3rd party tool
https://firebase.google.com/docs/firestore/solutions/search
To reduce documents read:
A solution that come to my mind however I'm not sure if it's suitable for your use case is using Firestore caching feature. By default, firestore client will always try to reach the server to get the new changes on your documents and if it cannot reach the server, it will reach to the cached data on the client device. you can take advantage of this feature by using the cache first and reach the server only when you want. For web application, this feature is disabled by default and you can enable it like in
https://firebase.google.com/docs/firestore/manage-data/enable-offline
to help you understand this feature more check this article:
https://firebase.google.com/docs/firestore/manage-data/enable-offline
I found a solution, thought I would share here
Create a new collection named typeaheads in below format
export interface ITypeAHead {
Prefix:string;
CollectionName:string;
FieldName:string;
MatchingValues:ILookupItem[]
}
export interface ILookupItem {
Key:string;
Value:string;
}
depending on the minimum letters add either 2 or 3 letters to Prefix, and search based on the prefix, collection and field. so most probably you will end up with 2 or 3 document reads for on search.
Hope this helps someone else.
I have a Firebase project where I'd like for users to be able to see when other users created their profiles. My initial hope was that I could use "user.metadata.creationTime" on the frontend to pass the date into the user's extra info document and verify that it is correct by having "request.resource.data.datecreated == request.auth.metadata.creationTime" as a Database Rule, but it looks like it is not possible according to the documentation.
Is there any way I can verify that the creation date is correct on the backend?
More info edit: Below is the code that is being triggered when a user creates a new account on my profile. The three values are displayed publicly. I'm creating a niche gear for sale page so being able to see when a user first created their account could be helpful when deciding if a seller is sketchy. I don't want someone to be able to make it seem like they have been around for longer than they have been.
db.collection('users').doc(user.uid).set({
username: "Username-156135",
bio: "Add a bio",
created: user.metadata.creationTime
});
Firestore rules:
match /users/{id} {
allow get;
allow create, update: if request.resource.data.username is string &&
request.resource.data.bio is string &&
request.resource.data.created == request.auth.metadata.creationTime;
}
user.metadata.creationTime, according to the API documentation is a string with no documented format. I suggest not using it. In fact, what you're trying to do seems impossible since that value isn't available in the API documentation for request.auth.
What I suggest you do instead is use a Firebase Auth onCreate trigger with Cloud Functions to automatically create that document with the current time as a proper timestamp. Then, in security rules, I wouldn't even give the user the ability to change that field, so you can be sure it was only ever set accurately by the trigger. You might be interested in this solution overall.
I'm building an app with a social network component using Firebase, currently if a user likes a post I create a node in the user document called likes and I add the post id, example:
users: {
k9EdVpyRJ2R2: {
likes: {
E36F50C: true
}
}
}
I'm wondering if the post gets deleted should I just handle the deleted post-id on client side when I get the likes ids? or is there a better way to trim the data (or even restructuring it since the app is not live yet)
You'd typically remove the likes at the same time as you remove the post. To efficiently determine what likes to remove, you should keep a link from each post to its likes (in addition to the user-to-likes mapping you already have).
With that you can use a single multi-location update to remove the post and all likes. See this blog post for examples: https://firebase.googleblog.com/2015/10/client-side-fan-out-for-data-consistency_73.html
Whenever I encounter code snippets on the web, I see something like
Meteor.subscribe('posts', 'bob-smith');
The client can then display all posts of "bob-smith".
The subscription returns several documents.
What I need, in contrast, is a single-document subscription in order to show an article's body field. I would like to filter by (article) id:
Meteor.subscribe('articles', articleId);
But I got suspicious when I searched the web for similar examples: I cannot find even one single-document subscription example.
What is the reason for that? Why does nobody use single-document subscriptions?
Oh but people do!
This is not against any best practice that I know of.
For example, here is a code sample from the github repository of Telescope where you can see a publication for retrieving a single user based on his or her id.
Here is another one for retrieving a single post, and here is the subscription for it.
It is actually sane to subscribe only to the data that you need at a given moment in your app. If you are writing a single post page, you should make a single post publication/subscription for it, such as:
Meteor.publish('singleArticle', function (articleId) {
return Articles.find({_id: articleId});
});
// Then, from an iron-router route for example:
Meteor.subscribe('singleArticle', this.params.articleId);
A common pattern that uses a single document subscription is a parameterized route, ex: /posts/:_id - you'll see these in many iron:router answers here.