I am currently creating an App with a firebase backend. When creating a new User it gets automatically assigned to an Id in an Format that looks like this: v4xpr8hLrLR3W5VUTN2zZ3XXKrF3.
Has this format a name? Like the 00000000-0000-0000-0000-000000000000 is called a Guid?
A UUID/GUID (RFC 4122) is a 128-bit number written as 32 hexadecimal characters.
A Firebase RTDB Push ID is 20 Base64 characters (a 120-bit number) and a Firebase user ID is (currently) 28 Base62 characters (a 166-bit number). This particular ID format doesn't appear to have an official name at the moment, as they are simply referred to as Push IDs and User UIDs.
However, inspired by the Firebase Push IDs, there is a new term that could be applied here: ULID - a Universally Unique Lexicographic Sortable IDentifier. The Firebase implementation of these IDs is not compatible with the proposed ULID spec (as the spec is Base32 and designed to be UUID compatible) but is similar enough that the name could be used here.
Related
I am using Firebase FireStore database for the first time and I have the following question.
I have created a calendar collection. This collection will contains document representing events that have to be shown into a Calendar implemented by an Angular application.
So I am defining the following fields for these documents:
id: int. It is a unique identifier of the specific document\event.
title: string. It is the event title.
start_date_time: string. It specifies the date and the time at which the event starts.
end_date_time: string. It specifies the date and the time at which the event ends.
And here I have some doubts:
Is the id field required? From what I know I will have the document UID that will ensure the uniqueness of the document. If not strongly required adopt an id field can be convenient have something like an auto increment field? (I know that I have to handle in some other way the auto increment because FireStore is not a relational DB and doesn't automatically handle it). For example I was thinking that can be useful to order my document from the first inserted one to the last inserted one.
It seems to me that FireStore doesn't handle DateTime field (as done for example by a traditional relational database). Is this assumption correct? How can I correctly handle my start_date_time and end_date_time fields? These field have to contains the date time used by my Angular application? So for example I was thinking that I can define it as string field and put into these fields values as 2020-07-20T07:00:00 representing a specific date and a specific time. It could be considered a valid approach to the problem or not?
Is the id field required?
No fields are required. Firestore is schema-less. The only thing a document requires is a string ID that is unique to the collection where it lives.
There is no autoincrement of IDs. That doesn't scale massively the way Firestore requires. If you need ordering, you will have to define that for yourself according to your needs.
In general, you are supposed to accept the randomly generated IDs that the Firebase client APIs will generate for you. Ordering is typically defined using a field in the document.
It seems to me that FireStore doesn't handle DateTime field
Firestore has a timestamp field type that stores moments in time to nanosecond precision. There is no need to store a formatted string, unless that's something you require for other reasons.
Assuming I have a list of data I would like to store with Firebase realtime database, and search it later.
What would be the best way to store the data and query it to get the best performance?
My data is a list of names (containing a lot of names).
["Bob", "Rob", ...]
Note that I have multiple clients searching in a given time.
If the names are supposed to be unique and order doesn't matter, you'll want to store them as a mathematical set. In the Firebase Realtime Database you'll model this as:
"usernames": {
"Bob": true,
"Rob": true
}
A few things of note about this model:
We use the names as keys, which means that each name is by definition unique (since each key can exist only once in its containing node).
The true values have no specific meaning. They are just needed, since Firebase can't store a key without a value.
Certain characters (such as . and /) cannot be used in keys. If a name contains such characters, you will have to filter them out (or encode them) in the key. For example someone named Jes.sie will have to be stored as Jes.sie (lossy) or e.g. Jes%2Esie (with URL encoding).
In such cases you could store the original unfiltered/unencoded name as the value. So: "Jes%2Esie": "Jes.sie".
A few more general notes about (text) searching in the Firebase Realtime Database:
Firebase can only do prefix matches, it has no support for searching strings that contain or end with a certain substrings. This means that in the original data it can search for everything starting with an B (with orderByKey().startAt("R").endAt("R\uF7FF")), but it can't search for everything ending with ob.
Searches are case-sensitive. If you want to be able to search case-insensitive, consider storing the keys as all-lowercase:
"usernames": {
"bob": "Bob",
"rob": "Rob",
"jes%2esie": "Jes.sie"
}
If you need better support for text-search, consider integrating a third-party search engine. Common recommendations are Elastic-search (self-hosted) or Algolia (cloud-based).
For more information on many of these topics, see:
this article on NoSQL data modeling
the video series Firebase for SQL developers
Cloud Firestore Case Insensitive Sorting Using Query (while written for Firestore, the same applies here)
Assuming I have a list of data I would like to store with Firebase realtime database, and search it later.
What would be the best way to store the data and query it to get the best performance?
My data is a list of names (containing a lot of names).
["Bob", "Rob", ...]
Note that I have multiple clients searching in a given time.
If the names are supposed to be unique and order doesn't matter, you'll want to store them as a mathematical set. In the Firebase Realtime Database you'll model this as:
"usernames": {
"Bob": true,
"Rob": true
}
A few things of note about this model:
We use the names as keys, which means that each name is by definition unique (since each key can exist only once in its containing node).
The true values have no specific meaning. They are just needed, since Firebase can't store a key without a value.
Certain characters (such as . and /) cannot be used in keys. If a name contains such characters, you will have to filter them out (or encode them) in the key. For example someone named Jes.sie will have to be stored as Jes.sie (lossy) or e.g. Jes%2Esie (with URL encoding).
In such cases you could store the original unfiltered/unencoded name as the value. So: "Jes%2Esie": "Jes.sie".
A few more general notes about (text) searching in the Firebase Realtime Database:
Firebase can only do prefix matches, it has no support for searching strings that contain or end with a certain substrings. This means that in the original data it can search for everything starting with an B (with orderByKey().startAt("R").endAt("R\uF7FF")), but it can't search for everything ending with ob.
Searches are case-sensitive. If you want to be able to search case-insensitive, consider storing the keys as all-lowercase:
"usernames": {
"bob": "Bob",
"rob": "Rob",
"jes%2esie": "Jes.sie"
}
If you need better support for text-search, consider integrating a third-party search engine. Common recommendations are Elastic-search (self-hosted) or Algolia (cloud-based).
For more information on many of these topics, see:
this article on NoSQL data modeling
the video series Firebase for SQL developers
Cloud Firestore Case Insensitive Sorting Using Query (while written for Firestore, the same applies here)
We make use of Sign in with LinkedIn for a pre-existing app. The app uses the id field returned as part of the user's profile, however the app has restrictions on what character values can be present in the id.
What are the legal characters that LinkedIn will put in the id?
The description for id says
A unique identifying value for the member.
This value is linked to your specific application. Any attempts to use it with a different application will result in a "404 - Invalid member id" error.
Testing a small sample size, shows things like zHjkl_t-4D, _IcF7_r2b1 and -1ZM8mwCKM, which caused an issue with the field being restricted to starting with alphanumeric characters. I'd like to know the legal values so we can access if LinkedIn signups are suitable for future applications.
Member IDs are presented in Base64 encoded format. Any characters that show up in the Base64 index table are valid.
For an app I build, I want to use the ID generated by Firebase push as an email address local part. Since the dash (-) is not allowed as first character, I would like to replace it with another character.
This has to be reversible though. Therefore I want to know, which characters does the Firebase push ID consist of?
So far I have seen:
alpha (a-z and A-Z and 0-9)
underscore (_)
dash (-)
Sample: -KD3rcGMuucRDjKOTK3O
Are there any other characters which might be contained in the ID?
Do firebase IDs always start with a dash?
There are probably a lot of better ways to generate a unique email address than by using Firebase's push ids and then mangling them. That said, if you want to learn more about how Firebase generates its push ids, read this blog post: The 2^120 Ways to Ensure Unique Identifiers. It also explains why you should not rely on push ids to be unguessable/secure.
An important thing to realize from that post is that the first 8 characters of a push id contain an encoded timestamp, which is also the reason they always start with the same characters if you generate them close to each other.
The post also contains a link to a gist of the JavaScript code to generate a push id.
The set of characters that Firebase selects from is:
-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz;
As you can see the - is just the first character in this dictionary, which is the only reason the push ids (currently) all start with a -. At some point in the future they will start with a 0, then a 1, etc. If you take the code in the gist, you could calculate when each of those roll-overs happen.
Finally: I once wrote an answer on how to get the timestamp back from a push id. Doing so is not recommended, but it can be a fun experiment: Can you get the timestamp from a Firebase realtime database key?
Not strictly a response to the question asked but related: based on #Frank's answer above it seems like a regex that will always match a Firebase push ID will look something like this:
const regex = /[a-zA-Z0-9-_;]*/gm;
This regex assumes that the ID in the string will be delimited by /. The - and ; added to cover the remaining character set. Remove the gm pattern flags if you are only after the first match.
I had a problem where I needed to extract the push ID from an URL. The push ID appeared after another known ID. The regex for such a situation can look like this:
let regex = new RegExp(`(?<=${known_ID}\/)[a-zA-Z0-9-_;]*`);