►
From YouTube: OpenJS Foundation AMA Series: Node.js on HTTP, Streams
Description
AMA on HTTP, Streams with Anatoli Papirovsk and Stephen Belanger
A
Go
hello:
my
name
is
Eva
ho
and
I
work
on
community
relations
for
the
Linux,
Foundation
and
I
want
to
welcome
you
to
our
first
ask
me
anything
on
HTTP
in
streams.
Today
we
have
Anatoly
and
Steven
to
answer
your
questions,
a
really
good
conversation
about
this
I
hope,
and
so
you
guys
everybody
who
has
contributed
a
question,
we're
gonna.
A
C
Oh,
hey
I'm,
Anatole,
I
work
at
those
mates
and
as
a
staff
software
engineer,
I'm.
Also
a
member
on
the
node.js
technical
steering
committee
I've
been
involved
with
node
for
quite
a
few
years
now,
but
started
contributing
to
chorus
initially
working
on
HTTP,
2
and
then
kind
of
branched
out.
So
a
few
other
things.
B
C
A
C
I
mean
I've
I
personally,
when
I
was
starting
out
with
node
awhile
ago,
I
used
sub
stats
stream,
handbook
and
I
found
it
quite
helpful
and
pretty
concise
and
easy
to
understand.
So,
if
somebody's
trying
to
learn
HTTP
in
streams,
I
think
that's
kind
of
a
good
good
starting
point.
From
my
perspective,
if
you're
just
trying
to
use
HTTP
I
think
something
like
festivai
or
Express
our
code,
libraries
to
just
use
HTTP,
you
know
need
to
know
it's
not
about
the
actual
underlying
I'm
transport
layer.
A
B
A
A
A
B
So,
a
month
most
of
that
is
just
like
tweaking
the
high
watermark
stuff
in
it
like
making
sure
your
views
have
like
a
good
balance
for
the
buffer
size.
Also,
some
things
to
think
about.
Like
I've,
often
times
seeing
people
who,
like
chained
together
like
ten
different
like
transforms
dreams,
there's
a
lot
of
machinery
in
streams.
So
it
can
be
a
lot
faster
to
just
have
like
one
stream.
That
does
all
the
things.
Okay,
an
example
might
be
like.
B
C
Yeah
I
agree
there
I
think
the
other
thing
that
I've
seen
often
is
a
people
get
button
like
not
on
the
stream
functionality
itself,
but
in
the
amount
of
processing,
video
and
the
code
that
they
write
so
I
mean
the
fact
that
you
know
no
there's,
obviously
single
threaded.
You
have
to
keep
in
mind
that
you
know
CPU
have
the
operations
are
gonna
be
blocking.
So
if
you're
processing
the
data
you
have
to
be
mindful
about
how
how
good
your
code
is
and
kind
of
make
sure
that
you're
writing
efficient
JavaScript.
B
You
know,
there's
there's
lots
of
cases
where
I've
seen
streams
like
they
don't
really
like.
Take
advantage
of
the
buffering
features
very
well.
A
lot
of
I've
seen
a
lot
of
things.
Fela
contradict
streams
that
have
no
reason
to
the
optic
streams
and
the
convict
stream
doesn't
really
have
the
offering.
A
A
Okay,
then
next
question
I'd,
love,
I'd,
love
an
explanation:
I'm
not
like
at
5
or
high
low
or
just
high
level
understanding
of
HTTP
and
streams,
and
why
it's
good
to
know
about
it?
What's
the
strengths
and
the
example
of
when
it's
not
a
good
idea
to
do
streams
that
will
really
help
and
I
am
sure
the
other
developers
are
in
the
same
boat,
so
a
little
bit
Jarboe
question,
but
it
sounds
like.
B
And
so
streams
they're
their
main
function
really
is
to
just
get
stuff
like
both
into
and
out
of
memory
quickly.
It's
like
the
getting
it
out
of
memory
that
I
think
it's
the
important
part
of
that
I
get
it
if
you're
processing,
like
a
giant
like
a
couple
gigabyte
file,
or
something
like
that,
you
probably
don't
want
to.
Let
all
that
into
memory
like
if
you're,
just
processing
like
a
couple
of
kilobytes
or
something
and
may
or
may
not
matter
that
much.
B
C
That
covered
it
honestly
from
the
kind
of
you
know
if
you're
it's
it's
I
mean
for
me,
streams
are
awaits.
You
just
take
a
big
chunk
of
work
and
break
a
bit
up
right,
so
its
main
use
is
like,
if
you're
trying
to
avoid,
if
you're
working
with
big
files
working
with
anything,
that's
it's
using
significant
memory,
kind
of
the
main
application
or
anything.
That's
you
know
kind
of
broken
up
over
time.
So,
like
that's,
why
you
know
HTTP
obviously,
is
naturally
a
streaming
kind
of
interface.
B
B
They're
like
loop
example,
you're
doing
all
bunch
of
stuff
event
arrives
like
if
you're
doing
something
synchronous,
the
inside
of
the
route.
That
means
the
the
server
can't
handle
other
requests.
At
the
same
time,
yeah
like
breaking
that
up
into
chunks
makes
it
easier
for
the
system
to
do
multiple
things.
At
the
same
time,
it
does
mean
the
extra
machinery
of
streams
that
it's
gonna
technically
take
longer,
but
it's
it's
a
trade-off.
B
A
B
A
B
A
C
A
C
C
A
About
HTTP
when
client
requests
when
client
requests
listens
to
events,
there
is
no
event
where
we
can
be
sure
that
it
will
be
called
at
the
end
in
node.
Eight
error
event
can
be
called
after
closed
event
in
request
and
no
twelve,
that's
not
possible
anymore,
but
you
can
have
a
closed
event
in
response
called
after
closed
event
for
requests.
What
are
you
possible
to
have
one
kind
of
flow
event
order?
I
think
it
would
be
simpler
and
client
won't
mean
to
list
multiple
events
for
those
cases.
B
B
If
you
try
and
look
at
the
code
on
github,
which
is
a
bunch
of
stuff,
it
does
and
there's
like
a
bunch
of
different
events,
complete
and
abort
sum
of
all
these
different
things
that
exist
on
like
certain
types
of
streams
you
just
like
close
and
finish
event
and
all
those
sort
of
things
which
like
tries
to
catch
everything
eventually
be
like
yeah,
something
happened.
It's
done.
C
C
A
C
B
If
anyone
uses
that
and
doesn't
know
how
it
works,
like
the
body
parser,
it's
basically
just
going
to
read
the
request
stream,
like
it,
the
like
next
function
that,
like
triggers
the
next
thing
in
the
middleware
chain,
it's
just
not
gonna
call
that
until
the
request
string,
those
done
doing
it,
the
body
not
actually
too
complicated
internally
I'll
do
the
same
thing.
Yep.
C
You
know
and
I
would
I
would
also
add
that
HTTP
in
general
and
note
is
obviously
basically
a
implementation
of
the
of
the
spec
with
you
know,
kind
of
a
state
machine.
There's
not
there's
not
a
ton
day.
That's
like
it's
not
really
ready
for
use,
as
is
unless
you're
doing
a
very
basic
server,
which
is
why
Express
and
festa
Phi
and
everything
else
exists
to
make
it
actually
easy
to
write
a
server.
A
C
C
C
There
are
benchmarks
for
the
note
kind
of
side
of
things.
I
don't
know
if
there
are
benchmarks
that
compare
ACP
to
with
in
node
with
other
implementations
out
there.
I
also
don't
know
how
I
carried
those
would
be
anyway,
but
it's
definitely
like
performance
is
something
that
was
definitely
considered
and
something
that
people
carried
about
during
the
development
of
the
HTTP
to
HTTPS
you
and
node
I.
C
Do
wonder
thing
I,
sorry,
I
would
call
out,
is
so
HTTP
to
and
note
has
two
different
modes
so
there's
the
kind
of
a
fully-featured
core
module,
which
is
the
full
HTTP
to
implementation,
including
our
streams
and
all
of
the
other
stuff
that
you
kind
of
might
want
that
and
there's
a
compatibility
mode,
which
is
basically
just
a
wrapper
around
HTTP
2
to
make
it
compatible
with
the
HTTP
1
API.
That's
what
allows
it
to
work
with
festa,
Phi
and
other
frameworks.
Out-Of-The-Box.
C
Yeah
so
I
think
I
think
also
note,
it's
I
mean
it's
worth
calling
out
the
must.
You
know
you're
doing
your
connection
terminations
yourself
or
your
I.
Don't
know
using
push
streams,
I
guess,
there's
not
necessarily
a
heavy
use
case,
for
it,
I
mean
if
you
have
most
most
server-to-server
communication
will
still
be
not
HTTP.
In
my
experience,
yeah.
C
C
I
would
recommend
the
guides
that
we
that
we
kind
of
suggested
earlier.
Those
are
good
good,
starting
points
and
also
I
would
say.
The
no
documentation
itself
is
now
pretty
good
stuff.
Another
come
a
long
way
over
the
years.
I
think
it's
just
like
the
strange
documentation
is
not
allowed
the
worst
place
to
start
actually
where,
whereas
it
used
to
be
completely
confusing,
I.
Think
okay,.
A
B
B
B
C
Like
the
you
know,
the
TCP
socket
is
obviously
at
some
point,
wrapped
around
a
TCB
handle,
which
is
a
beauty
stream,
but
you
know
some
of
the
higher
level
ups
or
abstractions,
but
some
of
the
high
level
stuff
and
note
is
not
necessarily
using
the
lib
beauty
stuff.
It
just
depends
on
it
as
a
like
every
every
io
resource
and
node.
So
what
is
H
CP
or
FS
or
anything
else
depends
on
the
concept
with
handles,
where
the
handles
are
the
lip
UV
streams
and
there's
a
bunch
of
different
ones.
A
C
A
C
C
C
There's
never
enough
contributors
to
to
do
all
the
work.
That's
required,
there's
a
variety
of
tasks,
no
matter
what
your
experience
level
is
with
node
or
with
programming
or
with
anything
else,
ranges
anywhere
from
maintaining
build
infrastructure
to
writing,
documentation
to
fixing
bugs
and
writing
test
cases
through.
So
you
know,
there's
a
ton
of
different
things
that
you
can
contributes
you
there's
a
good
amount
of
mentorship,
available
lots
of
people
regularly
involved
who
are
available
to
assist
and
help
out
with
with
PRS
and
documentation
updates
and
other
things
there's
also
good.
C
There
are
issues
in
the
nodejs
repo
at
our
tag.
There's
good
first
issues,
they
can
kind
of
you
know
start
with
if
you're
there
first
time,
there's
also
the
issues
that
have
the
dock
label
if
you're
interested
in
writing
some
documentation
or
helping
out
in
that
way,
there's
also
so
rich
or,
as
you
might
know,
him
trot
maintains
a
note
to
do
org,
it's
a
great
resource
if
you're
trying
to
get
started
with
node
email
rich,
and
he
sends
you
a
task
and
walks
you
through
thinking
it
an
actual
PR
and
getting
it
ready.
C
A
That's
really
cool.
Okay,
you
didn't
do
anything
dad
nope!
Okay,
then
well,
thank
you
to
in
Italy
and
Steven
for
looking
at
the
questions
ahead
of
time
and
being
able
to
answer
them
and
for
being
here
and
chatting
about
them
and
thanks
everybody
who's
on
the
call,
I
hope
this
was
useful
and
we'll
see
you
next
month
for
our
next
one
thanks.
So
much
thanks.