How to use wildcard char in path name

Hi,

I’m new to Algolia. I’m an iOS developer using Swift on the client side and Firebase for my backend. I’m using Node.js for my Algolia implementation.

How do I set a wild card inside my Algolia root path?

The path is: root/users/userID/post

The ‘userID’ is set by using Firebase’s ‘childByAutoID’ which will give each user a different id number. I tried using an asterisk as a wildcard in my code but it doesn’t work:

var rootRef = firebase.database().ref(‘users/*/post’);

The cli is unresponsive and the Firebase data won’t get indexed.

However if I use:

var rootRef = firebase.database().ref(‘users/A178928/post’);

wherein A178928 is a user’s id then the Firebase data does get indexed.

This isn’t practical because I will have many users and I need to have a wildcard to use in the path.

Any ideas on how I should approach this?

var rootRef = firebase.database().ref(‘users/wildcard_needs_to_go_here/post’);

1 Like

Hi @lsamaria, thanks for asking your question. @chris_algolia has done a lot of work with Firebase and Algolia, Chris do you have any insights here?

@ismaria,

Firebase doesn’t support wildcard paths. You’ll want to listen to

var usersRef = firebase.database().ref(‘users’).

The trick is to listen to the usersRef’s child_added, child_changed, and child_removed events. Then, every time anything happens to a child, you can update the index.

I got sick of writing and rewriting this logic, so I put it all together in a package that will sync any Firebase ref to Algolia. You can find the repo here:

It’s called quiver-firebase-search on NPM. Hopefully the GitHub README is enough, but I’m happy to answer questions and improve the README if it’s confusing.

I’ve used quiver-firebase-search in three different apps. It’s currently working great, but three is a pretty small deployment, so it’s always possible that you’ll find a bug.

Another Firebase tip is that it’s nice to copy data into flat structures to sync out to Algolia. For instance, I might duplicate some user data at /search/users/{uid}… in order to more tightly control which data I send to Algolia. If you don’t need a separate data structure then you win! If you find yourself needing to save a different object to Algolia than you have in your Firebase DB, duplicating data to a new collection and using firebase-search is a quick workaround.

1 Like

@dzello hello sir, how’s it going. Seems like a very friendly community you have here, and thanks for the help! @chris_algolia yes that * is a headache, I asked several people and no one knew the answer. I’m a solo dev and this is my first time ever doing something like this so it’s all new to me. I went to a Meetup and someone said the way I was setting up search paths ‘root/users/uid/post’ wasn’t the way it’s done. He said I need to make a diff path specifically for search ‘root/post’ and I’d avoid the wildcard and I can query directly on that ‘post’ node. Of course I’m duplicating every single post but then again I’m also avoiding the ‘users/uid’ nodes. I’m not really sure what’s the right or wrong way. Anyway I will download your github and try to work with it this week. I’ll let you know how it goes.

If anyone has any opinions on the way the meetup dev suggested I’m all ears.

Cheers :blush::blush:

1 Like

@chris_algolia Are you the same guy from YouTube? I’ve watched your videos. Nice stuff man :+1:t6::clap:t6::+1:t6:

I’m glad you found my YouTube videos! It’s always exciting to find out that someone has seen them :slight_smile:

My recommendation is to not nest your Firebase objects any more than you have to. For instance, you have /users/{uid}/posts/{postId}. This is a problem, because Firebase cannot make shallow queries. So if you want to loop through your users to pull off their email addresses, you can’t just query /users/{uid}/email, because there’s no wildcard—as you discovered :slight_smile:

The problem with the model above is that you have to loop through /users, which retrieves all of the user objects, including all of the user posts. This data model does not scale. Imagine having 1 millions users. You’d effectively have to retrieve your entire data set just to get the emails.

What you want to do is save your posts separately. I like to save them under /posts/{uid}/{postId}.

Notice that I have the user’s uid in the path to the post. That means that I can still query all of the user’s posts by querying /posts/{uid}, and I can also query the much-smaller user object at /users/{uid}.

I have a Medium post on this subject:

HowToFirebase.com is a brain dump of everything that I know about Firebase. I’m almost done with it, so if you give it a quick read you should know everything you need to take Firebase to production.

1 Like

@chris_algolia

Chris,

Thanks for the info. I’ve been working over the past few days and I haven’t had a chance to even open my cpu and try what you suggested. I’m going to try it starting tomorrow. If I have any questions I’ll post. Thanks again :blush:

@chris_algolia

Hi Chris. I tried your way and it worked although I did have to week it a bit. I initially asked about searching on ‘user/userID/post/postID’ and you said I should instead search on ‘post/userID/postID’. The problem I ran into was that I couldn’t retrieve ‘postID’ because it was 2 levels away from the ‘post’ node and I also still ran into the problem of still needing a wildcard for the ‘userID’. I instead searched directly on ‘post/postID’ and kept the userID as a key/val pair inside the postID node. Thanks!

Good! That method obviously works better for searching by posts.

Thanks for the update :slight_smile: