FRANK VAN PUFFELEN: It's me, Puff.
Hey, everyone.
Welcome to another episode of the Ask Firebase show.
My name is Frank, or for those of you
who follow me on Twitter, Puff.
And I'm going to be your host for today.
The first question is from Stack Overflow, it's from Pankaj.
And it's, how many concurrent reads and writes does
the Firebase database support?
That's actually a very interesting question, Pankaj.
Let's have a look at the answer that I gave,
and I'll explain a bit about it.
In Firebase, it's not really about concurrent writes.
But you always have to consider the number of writes
that you do in a certain time interval,
so say the number of writes in a second.
Because any disk has a maximum number of I/O per seconds
that it can do.
The Iops, as you call them.
The Firebase database is no different,
but you are on a shared infrastructure.
So of course, the numbers are not guaranteed.
You might wonder what happens if you reach your maximum number
of writes per second.
At that moment, the Firebase database
will start to queue up the writes
that it can't write to disk straight away.
So you'll be building a buffer of depending writes.
And then, if the write volume goes down,
it will start catching up with the buffer.
And of course, your next question is going to be,
but how do I know when this happens?
How do I know that I've reached the capacity of my database?
That's actually really easy.
You can attach a completion listener
to your write operation.
So if you're using JavaScript-- and I've
written an example in the answer here--
and you add a completion listener, then you can see.
And if the time between when you start the write operation,
and when it completes, if the time goes up,
then you know that most likely you're being buffered,
you're being queued.
It's a great question and it requires a bit of code.
But you can definitely detect--
you can get a feeling for what performance you can get
and how many write operations you can do at a time.
There's been so many good questions today.
Maybe the next one is yours.
This next question, again, is from Stack Overflow,
and it's from Evangelos, I think.
I'm not sure if I pronounced that correctly.
SPEAKER 2: Evangelos.
Evangelos.
FRANK VAN PUFFELEN: Yeah, that sounds about right, I think.
Evangelos is asking that if I retrieve data
from the database in a certain order,
then the snapshots come back in that same order,
is that actually by design?
That's a great question, Evangelos.
Let's actually dive into my Stack Overflow answer,
so that you can read along as I explain
why this works the way it does.
This is, indeed, the expected behavior.
When you fire a request to the database,
and you fire a bunch of requests,
they actually are sent to the database
over a single connection.
And that's new to a lot of developers.
They're not used to that.
Many of us think that you fire one HTTP request,
then fire another one, then fire another one.
But that's not how the Firebase database works.
We literally have one open connection,
then we simply send your first request, your next request,
your next request.
That's also the order in which the server receives them,
and the order in which the server answers them.
That actually is the reason why you
are guaranteed to get them back in the order in which you
requested them.
Actually, let's follow this link where
I have another answer that is sort of related to how this
works in Firebase, and another consequence that you might not
realize.
This was a question, where it was about,
if I'm requesting 10 items in a row,
why can I not do with Firebase the same thing that I
do with SQL, which to write in SQL, you would say,
SELECT * From table Where id IN 1, 2, 3, 4, 5, up to 10, right?
You would send one query, and get 10 results.
But with the Firebase database, that's not how it works.
With Firebase database, you actually send 10 queries.
It's like, give me item one, give me item two, and then
all the way up to item 10.
Your initial concern is probably that that's going to be slower.
But remember what we just talked about,
where all the requests are going over a single connection.
And that means that we're actually
going to be quite fast at returning these items.
So if you look at the answer that I've given here,
then you can see that I drew some beautiful ASCII art there.
The first one is probably how you think this works.
You ask item one from the database,
the request goes to the database,
the database looks up the item, and it returns it.
Then you request item two, so you send it to the server,
the database looks it up, and it returns item two.
And you continue that one until item 10.
So you're going to be waiting for the response 10 times.
That's actually not how the Firebase database works.
If you scroll down, you can see how our database works.
With Firebase database, we have a single open connection.
So when you request item one, item two, item three,
up to item 10 they are essentially
all sent to the server immediately after each other.
They become a sequence of requests.
And the server retrieves those.
Then it looks up item one, item two, item three,
until item 10 in the database.
And it returns it to the client, which then gets them back
in the same sequence that it requested them.
Here's response one, response two, response three,
up to response 10.
This is a concept that's known as pipelining,
and it's a part of the reason why the Firebase database is
probably going to be faster at retrieving these items
than you sometimes think.
If you ever have a concern about performance in a Firebase
database, my recommendation is to actually run a little test,
because it might be faster than what you realize.
Great question, thank you.
Next question-- next question is from Twitter,
where Daniel tagged a question with #AskFirebase.
Is it possible to use wildcards on Firebase rules?
Like write auth not equal zero auth.email ends
with @company.com.
That's a really great question, Daniel.
I really like it, but what I like even more,
is that Tadeas already answered it for me.
Because indeed, you cannot do a like type match with
the Firebase security rules, but we can do regular expressions.
Those are very powerful.
So what we do here is that we actually
write a regular expression that does the same string
comparison.
I really like your use case, because in this case,
you're essentially only allowing users from your company's email
domain to have access to the Firebase database.
You might actually want to make sure that the email address is
verified, in that case.
For that in the security rule, you
would say auth.email verified equals true.
So you have the same as you have with Tadeas' answer,
where you use a regular expression.
But then you also add auth.email verified equals true.
And with that, you can secure write access
to just users in your company domain.
It's a great question Daniel, and a great answer Tadeas.
I like it.
I have no idea.
Do we actually have any other questions out there?
Maybe one of you.
This next question is from Stack Overflow again,
and it's from Sasank.
Sasank has a question that we get regularly, which is,
can I use Firebase security rules to check
for unique values of a child?
And let's actually have a look at the question
on Stack Overflow, because it's a bit involved, this one.
So you can see that Sasank wants to check
whether URLs are unique in the Firebase database.
And the answer is you sort of can't.
So Firebase cannot check whether a value is unique,
because values are, yeah, they are lower in the tree.
But if you go one level higher in any collection,
the keys in your Firebase collection
are guaranteed to be unique.
If you think of JSON tree, there's
no way you can have the same key twice
under that single collection.
So knowing that, you can sort of flip your collection around.
So what you're now store as values,
how about storing them as your keys?
So if I look at your example, you're trying to store
URL's, which makes it a bit tricky,
because URLs contain characters that you cannot use
in your Firebase collection.
But if you, for example, think of a collection of users,
then you could take the user's email address,
that quite often people want to be unique,
and then instead of storing the email address as the value,
you store it in a separate collection as the email address
as the key.
That means that you're guaranteed
that each email address can only occur once in that collection.
You don't have to write any code, or even
security rules for that.
It just works automatically, because you're
sort of using the Firebase data model to enforce it for you.
So no code to be written.
Like I said, for your use case, using URLs,
that's slightly more difficult because a URL is quite complex
to store.
What I would recommend is that either you
remove a lot of those characters from your URL--
and I included a function in my answer to do that,
because I actually really needed that myself also.
But you could also use the hash code of the URL,
and use that as the key.
And then you know that since your hash codes are pretty much
statistically guaranteed to be unique,
that the URL that you based that hash code on
is also going to be unique.
This is a great way to use the inherent properties
of the Firebase database to implement your use
case, requiring that certain values are unique.
It's a really great question.
I really like it.
Thank you so much.
That's all we have time for this week.
If you like this episode, be sure to like
and subscribe at the bottom here.
Because then we can keep you up-to-date
if new episodes come out.
Be sure to check out the Udacity course, Firebase in a Weekend.
It's actually the most comprehensive way
you can learn about Firebase for iOS and for Android.
Finally, we have a link here that
will point you to the Firebase for SQL Developer series.
I think that's a great introduction for Firebase
for anyone coming from a SQL/relational database
background.
And if you have any questions, post them
on social media of your liking, with the hashtag AskFirebase.
With that, I'm going to leave you for this time around.
Thanks for joining.
I'll see you next time.
Can you do this with a Russian accent?
[INAUDIBLE] Please don't use that.
SPEAKER 3: #AskFirebase.