ABE HASKINS: Can you do this one as a hip hop-inspired freestyle
rap?
JEN PERSON: No.
ABE HASKINS: OK.
JEN PERSON: I could do it as like a Cockney accent.
ABE HASKINS: I think that's--
JEN PERSON: Hey, you lots.
[ABE LAUGHS]
Yeah.
But we'll keep it real.
[FUNKY MUSIC]
SPEAKER 1: Take one.
Marks.
[SLATE BOARD CLACKS]
JEN PERSON: Hey, all you Firebase developers.
Welcome to another episode of AskFirebase, the show
where we answer your burning Firebase questions.
I'm Jen Person, developer advocate on the Firebase team.
And today, I welcome, once again, Abe Haskins.
ABE HASKINS: Yep.
I am Abe Haskins.
I'm a developer programs engineer on the Firebase team
as well.
JEN PERSON: Oh, great.
So it's so awesome to have you back.
We've gathered some more burning questions for you to answer.
Are you ready to answer some questions?
ABE HASKINS: I am ready to extinguish some burning
questions.
JEN PERSON: Oh, yeah.
That's a good way to put that.
Here we go.
The first question comes from Bones.
ABE HASKINS: Bones underscore.
JEN PERSON: Or 6ones.
We're not sure.
Bones underscore, 6ones underscore.
Do Firebase processes run in Web Workers?
ABE HASKINS: This is a good question.
If you're not familiar, Web Workers
are a background thread in web browsers that you can program.
And I'm not actually sure if Mr. 6ones meant
do our SDKs run in Web Workers or if you can
use our SDKs in Web Workers.
The answer to the first one is no.
As far as I'm aware, none of the Firebase SDKs
need that extra processing time, that extra background thread
that Web Workers provide.
And Web Workers are a fairly modern standard.
So we don't see it getting used too much in cross browser SDKs
because older browsers don't support them.
In terms of can you use Firebase inside of a Web Worker
as a developer, I don't believe so.
It's not something we officially push to support.
It's possible that it does work.
But, again, because it's kind of one of those standards that
didn't really catch on that much,
like it doesn't have that much adoption,
we don't see a ton of use in that area.
So you can definitely try it, give it a shot,
and see if it works.
And file bugs if it doesn't.
But it's not something that is a huge priority for us
to make work.
JEN PERSON: Now, not coming from a web background myself,
is there a difference between a Web Worker and a Service
Worker?
ABE HASKINS: Yeah.
So that's a great question.
And the answer is that one of those is useful.
JEN PERSON: Oh, snap.
ABE HASKINS: Service Workers are a--
They're based on Web Workers.
They run in the background.
They have some similar traits.
And, obviously, the naming is similar.
But Service Workers are specifically
related to caching.
They act as a proxy between your page and the request
to the server.
So you can influence those cache things, set up online behavior,
and then the other one is general background tasks.
So unlike Web Workers, that I'm not
really sure what our situation is,
Service Workers are required for some parts of Firebase.
And that's a very important split.
JEN PERSON: Like Firebase Cloud Messaging, for instance.
ABE HASKINS: Exactly right.
The way we deliver messages to a client for a Firebase Cloud
Messaging on the web is that that Service Worker
is sitting there in the background constantly
listening.
And when you get a message, the Service Worker
then bubbles up that UI to the browser.
So in that case, that part is definitely supported and works.
And we can use other parts of Firebase
along with Firebase Cloud Messaging,
like when you get a message.
So if you're thinking Service Workers instead of Web Workers,
the answer is definitely yes.
It does work.
JEN PERSON: Cool.
Thanks for that clarification.
ABE HASKINS: Yeah.
Of course.
I always learn something.
ABE HASKINS: Me, too.
JEN PERSON: Ready for your next question?
ABE HASKINS: Absolutely.
JEN PERSON: This one comes from calendee on Twitter.
And they want to know is there any way
to test functions locally and serve the web
page at the same time?
When they attempt this, they get something, which
we'll probably show on screen.
ABE HASKINS: So if you look at the error he was getting,
it's a pretty common one.
But it's also not a very good one.
It's one of those areas that just kind of shows up
when you're programming a lot, which is the port, port
5,000, that Firebase Hosting's local development server runs
on, is already reserved in some way.
So when he's trying to run our CLI,
it gets this really bad error that's
like 127001 point port 4000 eaddruse, which
is short for address in use.
JEN PERSON: I'm going check to make sure that's the exact one,
by the way.
ABE HASKINS: It's probably close.
[LAUGHTER]
JEN PERSON: Nice.
So you've seen this a few times.
ABE HASKINS: Yeah.
It just happens when you're doing web development and web
server stuff.
And you never know, right?
You're like, why--
Is this program doing something wrong
because if that server is accidentally
trying to set itself up twice, it could just be crashing.
In this case, looking at the error
he was getting and not having any other information
about his environment, that error probably
means that he accidentally turned on the Firebase server
in another console as well.
And I think what's happening is he tried to run Firebase
Hosting local server.
And he tried to run functions local server.
But in one of those invocations, he
called it without the only flag.
Now with our CLI, you can pass --only and say functions
to only run the development server for functions,
--only hosting to only run hosting.
And if he forgot on either of those two calls
to Firebase to not say only, one of them is now running two.
And one is running one.
And that one is colliding with one of those other two.
JEN PERSON: Got it.
So if you just called Firebase serve,
even though you had your deployed web site,
it's now going to serve it locally as well?
ABE HASKINS: Yeah.
So you can run the server locally multiple times
accidentally.
So it doesn't have to do much with the deployed site.
Once you deploy it, it's up there.
And it's live.
And that's fine and separate.
But if you try to run Firebase and aren't careful when you're
doing it locally, you can get that collision, which shows up
that weird e address in use error
because two things are trying to setup the same server.
And it all falls apart.
In this case, a pretty specific bug,
but it's worth talking about because that error happens
all the time, all over.
And it's at least worth understanding
what that bug actually means.
JEN PERSON: My favorite error that I've ever heard of is--
One of my colleagues pulled me over to be like, look at this.
Look at this.
It just said, could not.
ABE HASKINS: Could not.
JEN PERSON: Could not.
[ABE LAUGHS]
JEN PERSON: Like, that was the whole thing.
Just could not.
I love when the error messages are just completely useless.
Thank you so much for coming on and answering
these great questions.
ABE HASKINS: Thanks for having me.
I'm so glad people keep asking great questions.
Every time I come back, the questions
are better than last time.
JEN PERSON: So absolutely keep them coming.
Whenever you come across something
that you think would be a great fit for the show,
make sure you hit it with the #AskFirebase.
And who knows?
You may see it on a future episode.
And if you enjoyed the content that you're seeing here,
be sure to subscribe to the Firebase Channel on YouTube
so you can get all the latest shows that are coming out.
ABE HASKINS: And who knows?
You might be the next person whose Twitter handle
we mispronounce on video.
JEN PERSON: It could be you.
[LAUGHTER]
Thanks so much for watching.
And I'll see you on a future episode.
Bye-bye.
ABE HASKINS: That's [INAUDIBLE].
JEN PERSON: That was a lot of questions.
[FUNKY MUSIC]
[LAUGHTER]