JEN PERSON: Long hair has a lot of drawbacks.
ABE HASKINS: Mm-hm.
JEN PERSON: And then, there's always just
like, one stray hair, and it'll get stuck to your arm,
and you're like, I can't find it.
Like It's like, itchy.
SPEAKER: That's take one.
Mark.
JEN PERSON: How's it going, Firebase developers?
Welcome to another episode of AskFirebase, the show
where we answer your burning Firebase question.
I'm your host, Jen Person.
And for my co-host today, I am welcoming back Abe Haskins.
ABE HASKINS: Hi, thanks.
JEN PERSON: You're welcome.
[LAUGHING]
Thanks for coming on.
Are you ready to educate me.
ABE HASKINS: I'm so ready.
JEN PERSON: The first question comes from yoyoyousei.
[LAUGHING]
He says, does exporting multiple cloud functions in one index.js
file affect a book time functions?
ABE HASKINS: Yeah.
This is a great question.
We get asked this all the time.
And it's hard to give an answer about.
And the reason that is is because I
talk to a lot of developers.
You talk to a lot of developers.
A lot of them do really crazy things.
They do absolutely ridiculous things.
And they do end up impacting things like this.
In theory, the answer should be no.
When you are coming from a cold start in Cloud Functions,
it does have to re-evaluate all your JavaScript.
So in theory, if your application
was hundreds of thousands of lines,
when it does that initial evaluation,
you could see some noticeable lag to the user.
Like, in theory, you could.
It is very unlikely, though.
However, I am not inclined to say you won't see this,
because I've seen ridiculous things that people do,
and they do get into situations where, for example, they
are parsing something, like templates, way in advance.
So they have hundreds of templates,
and they pass those, and then do something in their JavaScript.
And until then, it's blocking, and so they can't actually
run that JavaScript until this other unrelated operation is
done, or they're connecting to a database, or something
external every time the function gets ready to be ran.
So in those cases, it definitely can.
I don't think the size of that JavaScript file is
going to really impact it.
But other things you're doing in that boot, that initial start,
connections to external things, those definitely can.
And in theory, if you had a huge, huge application,
it could just by the size of the JavaScript,
make a few second difference.
But it is quite unlikely that you'll get to that.
JEN PERSON: So it's less about the number of Cloud Functions
and more about what you're doing?
ABE HASKINS: Yeah.
Yup.
And it's the same thing as like building any other application.
The slow things are, like, network I/O,
waiting on external services.
Those things will slow you down much more
than the speed of evaluating JavaScript well.
JEN PERSON: Great question.
Ready for another?
ABE HASKINS: Yep.
JEN PERSON: All right.
So this next question comes from carlossubs,
who wants to know, what's the correct way to split index.ts
into a number of different files?
Looks like everyone has a different hack
to make such a trivial thing.
ABE HASKINS: Yup.
And so, this is a great follow-up
from that last question.
JEN PERSON: Yeah.
ABE HASKINS: Because in theory, the technical performance
of a big JavaScript app doesn't make that much difference
in terms of evaluating it, or running it.
However, logically, in terms of maintenance and building things
that you can actually keep working on
for a number of years, this type of stuff really matters.
So here, he's talking about how do we
split up an index.ts file?
What can we do to make that more manageable--
not so much from a technical side,
but from the just, like, I'm editing this.
I want this to be sane and reasonable.
And sadly, unlike the last question,
which kind of had an answer, this one
does not have an answer.
If you've been in the JavaScript ecosystem for very long,
you probably know that we only kind of recently
agreed on the technical implementation of modules,
yet alone how to use them or what the patterns are.
Like, you will get a million views about how to do this.
So sadly, there isn't really an answer here.
But I can give you some general advice about TypeScript,
which is that it is cheap to split things
into multiple files.
It's pretty rare that you'll find
much of any disadvantage between splitting things up more.
It doesn't make any impact in cloud functions,
because it is always compiled into JavaScript,
and it does its own optimizations in there.
So even if you were trying to be really fancy about how
your modules existed, if you end up rolling them up
into a single JavaScript file, it's
not going to make any difference.
And depending on how your TypeScript is set up,
you may or may not be doing that.
And so, it's just really, really hard to say.
JEN PERSON: So maybe the correct way to split it
is the way that is most intuitive to you
as the developer, so that you can
access the different information you need quickly?
ABE HASKINS: Yeah.
I would think that's really it.
It's just, what feels right in your application?
It doesn't matter that much.
And one really cool hack in TypeScript,
which is a little bit of an aid that's really cool,
is that if you have a main, like, index.ts file,
and you have a bunch of modules that are around-- you
know, maybe you have signup.ts, and you have email.ts,
whatever-- anytime you call import something from one
of those files, you can change that to export something
from one of those files.
And what that does is just immediately
passes whatever you're importing out as an export.
So like Cloud Functions, where you're
required to export the function that you're setting up,
you can put on one of those files
and have your index.ts just be, like,
the thinnest shim that exports my function from another ts
file.
And that lets you keep everything separated out
from that index.
Right?
So the only thing that index actually does
is pull everything together for that final bit.
But all of your actual functions, your code,
is all separated out into nice different files.
JEN PERSON: I love that idea.
You could have a different file for each
of your Cloud Functions.
ABE HASKINS: Yep, yep.
And just keep it nice and isolated and clean.
JEN PERSON: Beautiful.
Well, thank you.
ABE HASKINS: Yeah.
Yo, I have a question for you.
I heard we did some announcements about ML Kit
for Firebase, but I haven't really
been able to keep up on that.
Are you working on anything related to that?
JEN PERSON: Yeah.
Yeah, so I've been playing with the great code lab
that we have put together.
We actually gave it at the Firebase Summit as well.
They're checking out the new features of ML Kit,
and then we have an example on iOS and Android,
which enables you to check out our face contour,
which is one of our latest APIs, so you
can find the different points on the face.
It's great for adding filters, and it also
has text recognition in it, and landmark recognition.
So it's really--
ABE HASKINS: Facial landmark?
JEN PERSON: Facial landmark.
ABE HASKINS: Right there is the Eiffel Tower.
JEN PERSON: Yes, actually, that is one of the things.
The landmark is the term that you use for,
like, describing the nose, mouth.
These are considered landmarks of the face.
ABE HASKINS: That's not a joke, then.
Never mind.
[LAUGHING]
JEN PERSON: I definitely thought about,
like, Eiffel Tower the first time I read that.
I was like, hm.
I feel like that's an example we always
use for, like, full landmarks.
ABE HASKINS: It's the only landmark anyone cares about.
JEN PERSON: It's like, the easiest one to detect too.
I want something that's really hard.
Show me, like, one rock, and like tell me.
ABE HASKINS: That's an important rock from Nevada.
You know the one.
JEN PERSON: That's Jimmy, Jimmy the Rock.
Thank you so much for coming on and answering
these great questions.
ABE HASKINS: Yeah, 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: Yeah.
And that's why your questions are so important,
because the questions that we get through AskFirebase
really do lead us to come play with the code
and discover new things, and it helps us make cool demos
and solve problems.
So make sure that if you have queries for us,
you're tagging them on social media with the hashtag
#AskFirebase.
Thanks so much for watching, and I'll
see you on a future episode.
Bye, Bye.
I'm so excited to hear what you have to teach me--
ABE HASKINS: That's great.
I'm glad you learned something [INAUDIBLE]..
Because I've been here several times.
You got nothing to learn from me.
JEN PERSON: I have nothing to learn.