I'm trying to use the "orderByChild" functionality provided by Firebase, but I stumbled upon a roadblock. The structure of my database is very simple, it looks a bit like this:
Root
Users
${UID}
ID
Name
Birthday
...
Now, I'd like to search other user's names without knowing their UID.
Does anyone have an idea on how to solve this problem?
I could just download the users file completely but that does not seem like a good idea.
this about the question before posting it on stack overflow : you have to make a strategy to get this issue solved , I propose to you two possible solutions :
1)(very bad solution):
you parse the data from firebase and you put them in [<String , anyObject>] and you loop over this array in order to get the username that you want to get.
**
Ps: in term of performance and usability the worst thing that you
could do is to invoke the database to get unuseful data, so don't use
this solution in production.
**
2) you make a strategy for this:
look over what should be the relationship between a user and another and add new field for example friends and store on it the uids that you want to get.
Related
this is sort of a weird/complicated question but I thought id ask.
So during the sign up process for my app (I am using flutter and firebase for backend), people have to submit certain documents such as a resume and other official documents. My question was assuming the documents have a standard layout, is there any way to verify that it is the correct type of document automatically? So someone couldn't fake a document and sign up for the app.
I wanted to make it in a way so I wouldn't personally have to go through each document and make sure its the right one.
If anyone has any ideas please ping me and let me know.
Thanks!
I'm writing an app with a database of users. I want to show these to people on the app, and as such, in order to limit the download of data, I'm using the standard Firebase pagination concept:
.startAtDocument(lastDocumentSeen)
The problem is, I have no idea what actually happens when the 'read head' gets to the end of the database? Does Firebase/Flutter loop back and start to look at the top of the database again? If not, how does it signal to me that I've reached the end?
I've done quite extensive googling about this, and searched StackOverflow too, but can't seem to find any clear answers - does anyone know?
Assuming you have a query like this:
collectionRef.orderBy("something").startAfter(cursor).limit(10)
If there are not enough documents to return 10 results, Firestore will simply return however many documents are left. It does not perform any tricks beyond that.
You can use fetch_more package for pagination, it’s easy to use. You can see an example in the Example tab.
https://pub.dev/packages/fetch_more
I'm making a firebase app where there's the concept of posts and authors.
I need to have a field called postedBy to give information about the post author. I'm currently confused on how to best implement this. Here's what I've thought about...
Store a postedBy field with the post author's ID as value. My issue with this is that I have to further send single requests for the user information, like name, profile picture etc.
I store a postedBy field with the exact clone of the author's data (name, profile URL, etc). My issue with this is what if the user changes their profile information? Do I have to loop through all the posts data to also ensure the changes?
What is the best way to solve an issue like this?
For your case, I would say that the best option would be probably to use only the ID as a value. This way, you can perform queries to return values using only the ID.
Using this approach should be the simplest and easiest way for you to create your application. Since the ID will be the point to connect your tables and to perform the queries, it should make your work easier.
In the below article, there is an example of a Blog application, that you can take a look and get some insights on how to configure your application as well - mainly about this part about author and post. :)
Learning Firebase: Creating a blog article object
Let me know if the information helped you!
I am pretty new to meteor and I am trying to make my first app which should have a profile page, later also with picture upload depending on user group.
As I understand I do not need a extra collection and subscription.
I am using useraccounts:bootstrap package with accounts-password. I added some custom fields to the profile (firstName, lastName, country).
Now I want to create a update or edit page. I could not find any resources which could been helpful.
Do I need to write all the logic for example testing the email address by my self? Or is this included by the package.
Or is it better to create a new collection for users with meteor-collection2?
Thanks
Witali
Collection2 will just attach its schema to the original user collection (if you proceed like suggested in collection2 readme).
As far as I know, I'm afraid that you will have to create some publications. Since editing user should be considered as "must-be secure", I would advise you to take a look at the existing packages. I'm quite a newbie to so I didn't look into the code of alanning roles package (which is, I've been told, excellent).
I used https://github.com/perak/user-roles. I think the code is good and clear.
The same guy, perak, made a meteor code generator which is still a work in progress, but looks very promising to me. Get one of his examples with user account and look at the client folder. You will have, when considering his user-roles package, all the code to do what you want.
ps: for email testing, look at his files in the client/lib folder but it is just a regex
I am designing a system that uses asp.net webapi to serve data that is used by a number of jquery grid controls. The grids call back for the data after the page has loaded. I have a User table and a Project table. In between these is a Membership table that stores the many to many relationships.
User
userID
Username
Email
Project
projectID
name
code
Membership
membershipID
projectID
userID
My question is what is best way to describe this data and relationships as a webapi?
I have the following routes
GET: user // gets all users
GET: user/{id} // gets a single user
GET: project
GET: project/{id}
I think one way to do it would be to have:
GET: user/{id}/projects // gets all the projects for a given user
GET: project/{id}/users // gets all the users for a given project
I'm not sure what the configuration of the routes and the controllers should look like for this, or even if this is the correct way to do it.
Modern standard for that is a very simple approach called REST Just read carefully and implement it.
Like Ph0en1x said, REST is the new trend for web services. It looks like you're on the right track already with some of your proposed routes. I've been doing some REST design at my job and here are some things to think about:
Be consistent with your routes. You're already doing that, but watch out for when/if another developer starts writing routes. A user wants consistent routes for using your API.
Keep it simple. A major goal should be discoverability. What I mean is that if I'm a regular user of your system, and I know there are users and projects and maybe another entity called "goal" ... I want to guess at /goal and get a list of goals. That makes a user very happy. The less they have to reference the documentation, the better.
Avoid appending a ton of junk to the query string. We suffer from this currently at my job. Once the API gets some traction, users might want more fine grained control. Be careful not to turn the URL into something messy. Something like /user?sort=asc&limit=5&filter=...&projectid=...
Keep the URL nice and simple. Again I love this in a well design API. I can easily remember something like http://api.twitter.com. Something like http://www.mylongdomainnamethatishardtospell.com/api/v1/api/user_entity/user ... is much harder to remember and is frustrating.
Just because a REST API is on the web doesn't mean it's all that different than a normal method in client side only code. I've read arguments that any method should have no more than 3 parameters. This idea is similar to (3). If you find yourself wanting to expand, consider adding more methods/routes, not more parameters.
I know what I want in a REST API these days and that is intuition, discoverability, simplicity and to avoid having to constantly dig through complex documentation.