►
From YouTube: OpenJS Foundation AMA: Node-RED
Description
Node-RED creators Nick O'Leary and Dave Conway-Jones chat with John Walicki and answer user-submitted questions about Node-RED.
The OpenJS Foundation is a member-supported non-profit organization that provides a neutral home for some of the most important project in the JavaScript ecosystem.
Learn more and join us at https://openjsf.org
B
Welcome
everyone,
thanks
for
joining
our
open,
Jas
foundation
livestream
today
and
I,
am
really
delighted
to
have
with
me
today,
Dave
and
Nick
to
join
us
for
our
chat.
First
I
hope
that
everyone
is
safe
and
healthy
and
staying
appropriately
social
distancing,
a
couple
of
things
that
I
do
want
to
cover
for
logistics.
Reasons.
First,
want
to
remind
everyone
of
our
code
of
conduct
and
I'll,
be
selecting
appropriate
questions
from
the
prepared
remarks
and
our
submitted
questions
and
from
the
live
streams.
B
Every
couple
of
minutes
I'll
be
checking
to
see
if
any
questions
are
coming
in
and
we'll
we'll
turn
to
those
but
I've
prepared
a
whole
set
of
questions.
I
think
that
we
will
have
fun
with
this
really
delighted.
So
so,
let's
get
to
it.
Nick
Dave
co-creators
of
the
node-red
project.
Maintainer,
is
really
delighted
that
you're
here
with
us
today,
please
take
a
moment
to
introduce
yourselves
thanks.
A
A
B
C
Been
going
on
so
Amy
briefly,
you
know:
node-red
came
about
as
as
a
side
project
when
Dave
and
I
worked
together
in
in
our
emerging
technologies
group
wanting
just
to
play
around
some
technologies
wanting
to
create
some
tooling
that
just
made
our
life
easier
doing
our
day,
job
of
creating
Internet
of
Things
type
projects,
but
you
know
typically
very
quick
turnaround
very
experimental.
Just
you
know
don't
want,
spend
huge
amounts
of
time
in
deep
code.
C
You
just
want
to
try
and
build
a
solution,
prove
an
idea
and
move
on
type
of
idea,
so
yeah
yeah
it
it.
It
seems
an
obvious
thing
now,
but
you
know
at
the
time
it
was
you
know
what
would
it
mean
to
have
some
tooling
that
let
you
abstract
away
the
lines
of
code.
You
have
to
write,
you
know
more
than
capable
of
writing
that
code,
but
you
know
the
more
time
you
spend
writing.
Boilerplate
code
is
less
time,
you're,
actually
bringing
value
to
a
to
whatever
you're
doing
so.
C
A
C
Think
it
was
ultimately
just
looking
for
a
way
to
make
our
lives
easier
and
and
wanting
to
play
around
with
new
technologies.
You
know
at
the
time
I
wanted
an
excuse
to
do
a
bit
of
a
deep
dive
into
nodejs
as
a
programming
environment.
So
node-red
is
pretty
much.
The
first
thing
I
built
in
nodejs,
also
wanted
to
play
around
with
its
browser
visualizations
and
seeing
what
you
could
do,
and
you
know
all
these
streams
kind
of
came
together
in
my
mind,
for
for
what
has
turned
into
node-red.
A
And
I
was
working
on
some
projects
where
I
was
actually
out
sitting
in
the
cold
field
somewhere
trying
to
type
cold
code
with
cold
fingers.
Saying
there's
got
to
be
a
better
way.
So
when
showed
me,
the
very
first
prototype
of
this
I
so
grabbed
it
said.
Yeah
absolutely
I
need
that
when
I,
when
styled
hacker,
wear
that
over
the
weekend
and
broke
completely
back
out
of
my
hands
and
said,
let's
do
this
properly,
let's
build
it
into
a
tool
that
can
be
extended
and
be
useful
to,
for
other
things
did.
C
Top
t
topic,
maybe
doing
a
bit
of
changing
the
message
as
it
flowed
between
the
two
and
I
think
it
was
it
was
you
know,
Dave
sat
in
that
field
knew
he
had
to
plug
in
a
I
think
of
a
GPS
or
some
sensor
over
a
serial
connection.
So
you
know,
unlike
day
two,
he
was
saying
it's
great,
but
now
how
do
I
get
my
serial
data
in?
C
And
you
know
that
was
when
I
then
took
it
off
him
and
went
and
worked
out
how
we
could
make
it
a
little
bit
more
extensible
and
the
idea
of
having
these
pluggable
nodes
started.
Yeah
really
early
on
in
the
project,
and
so
the
second
node
that
was
created
after
the
second
set
of
nodes
was
the
serial
nodes
and
because
they've
needed
it
in
a
project
that
day
and
I
think
for
near
for
the
first
month
or
so.
C
Every
every
new
bit
of
function
that
was
added
was
because
we
had
a
project
that
needed
some
new
bit
of
function,
which
meant
which
was
really
good
because
it
meant
we
stayed
focused
on
actual
requirements.
You
know
this,
wasn't
we
weren't
imagining
use
cases?
We
had
real
use
cases
and
real
problems
to
solve,
and
you
know
that
that
sort
of
sustained
the
requirements
for
for
the
first
leg
of
its
existence,
I
know.
B
C
Certainly,
in
our
mind,
the
goal
was
always
that
this
needed
to
be
an
open
source
thing.
You
know
just
the
Bing
Percy
long
long
supporter
of
the
open
source
way
of
developing,
but
also
in
in
the
part
of
the
organization
we
are.
Were
you
know
this.
This
was
a
side
project.
You
knew
this
was
not
a
an
effort
to
build
some
big
product
this.
C
This
was
a
tool
that
was
useful
to
us
and
and
had
immediate
relevance,
but
we
were
not
a
group
there
to
create
new
products
as
such,
and
we
very
quickly
recognized
the
value
as
much
of
value
as
there
is
in
the
core
of
node-red.
The
real
value
is
in
that
pallet
of
gnomes
yeah.
The
nodes
represent
what
you
can
do,
and
you
know
the
rates
that
we
were
having
to
spend
time
writing
nodes
ourselves.
C
We
kind
of
just
knew
instinctively
the
best
way
to
expand
the
platform
was
to
get
other
people
writing
the
nodes
for
us.
So
as
we
went
through
the
process
and
got
the
various
approvals
as
of
course
you
have
to
do
in
in
corporate
environments
to
open-source
it
you
know
there
was.
That
was
a
speedy
process.
I
may
have
spoken
about
that
before
I
mean
people
can
find
like
the
talk
I
did
it
monkey
grow
a
few
years
ago
about
about
that
process.
C
When
we
open
sourced
it,
we
very
consciously
removed
any
barrier.
We
could
imagine
to
other
people
creating
nodes,
and
you
know
I
think
in
anyways
that
has
been
one
of
the
keys
to
our
to
the
success
the
project
has
had
and
that
the
popularity
it's
gained
is
because
people
aren't
constrained
to
the
functionality
that
Dave
and
I
the
core
contributors.
If
you
like
have
time
to
right
so
yeah,
you
know
that
it's
been
a
huge
benefit
to
the
project,
so.
B
C
It
very
much
came
from
an
Internet
of
Things
philosophy,
but
being
event-driven
because
the
sense
of
reads
and
data
you
need
to
do
something
with
it
and
we
very
consciously
when
we
open
sourced
it
led
the
project
under
that
sort
of
banner
that
it's
visual
programming
for
the
Internet
of
Things
and
because
again,
you
know
what
six
and
half
seven
years
ago
when
we
actually
open
sourced
it.
Yeah
the
Internet
of
Things
as
an
idea
and
a
concept
was
very
much
at
its
at
its
peak
of
hype.
C
So
you
know
that
that
helped
get
interest
in
the
project,
but
also
I,
think
it
just
a
lot
of
individuals,
the
fact
we're
doing
it
on
Raspberry
Pi,
the
fact
we
were
doing
it
on
you
know,
being
an
open
project,
made
it
very
accessible
to
a
huge
audience
of
individuals
who
you
know
they're
not
having
to
spend
lots
of
money
on
specialist
kit.
For
this
you
know
it's
a
Raspberry
Pi,
it's
you
know
like
$50,
and
you
know
there.
C
There
are
away
with
it
types
of
things,
so
they're
a
huge
part
of
our
individual
developer
community,
if
you
like,
are
people
doing
interesting
things
in
their
homes,
home
automation.
You
know
it
isn't
you're
not
tied
to
having
to
do
to
industrial
automation,
type
projects
with
it.
It
is
very
flexible,
I.
A
Think
the
other,
the
other
piece
is
because
it
doesn't
abstract
away
some
of
the
boilerplate
stuff
like
HTTP
and
a
wharf
indication
and
some
of
the
other.
You
know
nitty-gritty
things
that
people
would
have
to
write.
Otherwise
it
does
open
it
up
to
more
lower
level.
Programmers
lower
skilled
programmers,
maybe
or
people
willing
to
learn
or
education,
the
areas
and
whatever.
B
B
C
C
You
know,
event-driven
apps,
so
a
space
we
saw
it
very
early
on
and
again
one
of
the
great
things
about
this
being
an
open
source
project.
Is
you
quickly
lose
sight
of
what
people
are
doing
with
it?
You
know
it's
no
longer
your
little
thing
that
people
keep
updating
with
what
they're
doing
so,
just
out
of
the
blue.
We
had
some
people
contact
us
saying
they
were
using
it
that
they
were
developing
a
mobile
banking
application
and
they
were
using
node-red
as
a
development
tool
for
the
backend
of
this
app.
C
They
needed
to
be
developing
their
mobile
app
in
parallel
to
the
backend,
but
that
meant
the
two
teams
were
constantly
sort
of
blocking
each
other,
because
one
needed
the
other
to
make
progress.
Well,
with
node-red,
the
mobile
app
team
managed
to
mock
up
the
entire
back-end
API
in
a
day,
and
then
that
gave
them
a
test
server
that
they
could
then
focus
on
the
mobile
app
and
build
their
app
against
and
yeah.
B
B
Because
there's
quite
a
few
people
come
to
think
of
know
Brad
as
our
prototyping
tool
and
and
because
real
programmers
program
in
you
know
pick
your
favorite
language,
C,
Java,
C++
Ross
go
down
the
list
assembler,
and,
and
so
how
do
you
respond
to
the
question?
Where
is
it
a
prototyping
tool
or
is
it
can
you
use
it
in
production
so.
C
There's
no
doubt
that
again
in
the
very
early
days,
we
did
talk
about
it
as
it's
great
for
that
quick
application,
development
and
prototyping.
But
you
know-
and
it's
absolutely
matured.
You
know
stabilized
you
to
go
interview
very
quickly
and
there
are
tons
of
examples
of
people
using
it
in
production.
C
We've
got
a
huge
list
of
companies
who
are
using
node-red
in
their
own
products
of
services,
whether
it's
services
they
sell
or
products
they
sell
or
they're
using
it
internally.
But
you
know
that's
still
production
because
they're
still
supporting
their
internal
users
through
some
application
developed
in
node-red.
C
You
are
giving
up
some
degree
of
control
some
degree
of
seeing
the
the
individual
lines
of
code.
Now
mythili
was
something
with
with
low
code.
Programming
like
node-red
is
perhaps
a
bigger
step,
because
the
abstraction
is
is
different.
Perhaps
then
going
from
C
to
JavaScript
or
whatever
it
might
be,
but
you
know,
but
the
fact
remains
is
as
a
programmer.
It
does
let
you
focus
on
the
design
of
the
logic
of
your
application
and
there's
no
harm
in
that,
and.
A
B
Let's
explore
that
for
a
minute,
because
popular
right
now
are
these
low
programming
techniques
and
models
and
no
red
is
an
interesting
half
way
in
between
a
low
code
programming
technique.
You
still
can
write
JavaScript
if
you
need
to
with
no
red,
but
so
where
do
you
see
no
red
fitting
in
the
low
code
programming
world
so.
C
I
think
you
know
the
reality.
Is
it
still
takes
a
bit
of
experience
to
get
going
with
no
dread
if
you're,
not
if,
if
you're
an
individual
looking
to
download
it
and
run
it
because
you
know
you
need
to
install
nodejs
and
you
need
to
know
how
to
have
n
install
no
dread.
So
yeah
there
is
still
a
bunch
of
frankly
command-line
things
you
have
to
do
to
get
going
there
dread
so,
but
you're
quite
right
once
once
you've
got
no
dread
going.
C
You
can
do
a
lot
with
it
without
worrying
about
code,
but
it
it
does
give
you
the
hooks
to
get
in
and
write
code.
If
you
need
to
so
yeah,
it
does
sort
of
hit
that
middle
spot
between
completely
isolating
you
from
any
line
of
code
at
all.
To
forcing
you
to
do
everything
in
code-
and
you
know
so,
there
are
plenty
of
low
code
alternatives
out
there.
Lots
are
done
as
hosted
services,
so
people
often
look
at
like
if
this
than
that
is
a
you
know
very
popular
example.
C
Where
you
know
it's,
the
service
they
offer
is
just
a
completely
abstract
out
the
Thiet,
the
code
entirely
so
yeah
no
dread
has
this
middle
ground
and
that
that's
I
think
one
of
its
strengths
in
that
it
can
sort
of
play
across
that
wider
audience
and
the
point
Dave
made
earlier.
You
know
the
fact
that
our
audience
can
be
a
broad
range
of
experience.
You
can
have
a
domain
expert.
You
know
an
engineer
who,
who
knows
far
more
about
their
domain
than
I.
C
Do
they
know
how
to
solve
the
problems
if
they
can
break
it
up
into
the
sort
of
the
logical
flow
chart
of
steps,
so
no
dread.
The
fact
that
no
dread
allows
them
to
express
that
they
can
look
at
a
no
read
flow
and
use
their
domain
knowledge
and
their
domain
expertise
to
intuit
what
that's
doing
and
help
just
helps
them.
Your
rod
and
okuda
screenful
have
coned.
C
Well
so
yet
we
reached
our
the
big
1.0
milestone
in
I
think
it
was
October
last
year
yeah.
That
was
a
major
point
for
us
to
get
to
you
know
big
stake
in
the
ground
of
you
know:
we've
ticked
off
all
the
major
items
we
had
in
our
roadmap
of
saying
you
know
this
is
this
is
good.
This
is
you
know,
absolutely
something
you
can
move
forward
with
confidence
in
that
said,
you
know
we
aren't
done
by
any
means.
C
There's
there's
a
whole
bunch
of
areas
we
want
to
expand
on
one
of
the
one
of
the
areas,
particularly
in
production
usage,
that
our
story
is
weaker
than
it
should
be
at
the
moment,
is
around
testing
and
how
you
can
integrate
testing
into
your
node-red
devant
experience.
So
we've
got
some
start
of
some
interesting
conversations
in
the
community
around.
What
is
what
is
the
node-red
experience
user
experience
for
for
creating
tests
that
sit
alongside
your
main
flows?
C
So
that's
interesting,
and
then
you
know,
we've
always
had
these.
There
are
so
many
different
ways
we
could
go.
You
know
one
of
our
perennial
challenges
is
just
trying
to
prioritize
what
we
do.
We
don't
have
the
resource
we
would
like
to
be
able
to
pursue
every
op
every
opportunity-
that's
out
there,
so
there's
looking
more
at
edge
computing.
For
example.
Looking
at
how
could
you
I
mean
one
of
the
things
I've
spoken
about
before
that
motivates?
C
My
some
of
the
prioritization
I
I
put
forward
is
around
this
idea
of
being
able
to
draw
a
flow
in
node-red.
That
represents
the
logic
from
what
runs
on
a
device.
Maybe
it
runs
on
10,000
devices
all
the
way
through
to
the
logic
that
runs
in
the
cloud
to
manage
the
data
coming
from
those
devices,
but
thinking
about
it
of
in
terms
of
an
event
happens
on
a
device.
What
is
the
life
cycle
of
that
event?
C
C
You
know
what
would
it
look
like
to
then
hit
that
deploy
button
and
have
that
all
broken
up,
packaged
and
then
pushed
out
to
multiple
places
that
yeah?
That's?
That's
been
a
high-level
concept.
I've
talked
about
before
that.
You
know.
Thinking
about
you
know
what
are
the
missing
pieces
in
the
project?
What
we
want
to
do
and
more
immediately,
you
know,
we've
got
the
1.1
release
coming
up
pretty
soon.
C
B
C
One
that
one's
got
the
ability
to
group
nodes
in
the
in
the
workspace
and
by
which
I
mean
like
you
might
be
familiar
in
in
PowerPoint
or
keynote
whatever
it
is.
You
literally,
you
know,
select
some
nodes
group
them.
You
can
then
move
those
nodes
around
as
a
single
entity,
but
then
the
group
can
have
a
border.
It
can
have
a
background.
It
can
have
a
label,
so
you
can
start
visually
documenting
your
flows,
that's
what's
in
1.1,
but
the
the
longer-term
roadmap
for
the
group
feature
is
to
then
allow
those
groups
to
have
properties.
C
So
again
that
speaks
back
to
that
concept.
I've
just
mentioned
about
2.2
different
places.
The
group
could
then
be
the
way
to
say
this
group
of
nodes
deploy
to
my
devices.
This
group
goes
to
my
gateways.
This
group
deploys
to
the
cloud,
for
example,
so
it's
grouping,
there's
some
redesign
work
of
the
sidebar
to
help
try
and
make
it
easier
to
manage.
I
mean
the
bulk
of
our
users
that
we
talk
to
you
regularly
on
the
forum
are
the
Raspberry
Pi
user
and
they
use
it
at
a
rap
raspberry
pie
scale.
C
C
You
know
that
that's
a
scale
of
usage
that
goes
beyond
the
sort
of
day-to-day
experience,
so
looking
at
you
know,
how
can
we
try
make
it
easier
to
manage
those
large
installations
of
node-red
and
then
there's
a
whole
host
of
interesting
bits
and
pieces
that
have
sort
of
crept
along,
so
we
hope
to
have
a
beta
of
1.1
in
the
next
week
or
so
you
know,
we've
got
a
few
more
pull
requests
that
just
need
tidying
up
and
merging
before
we
we
do
that.
But
you
know
it's
on
its
way.
C
A
Of
the
things
I'd
say
is
that
you
know
a
lot
of
the
features
of
get
put
in
there
are,
you
know,
do
come
from
the
users
in
the
community.
They
come
back
with
great
feedback
all
the
time.
High
level
features
I.
Wouldn't
it
be
great
if
we
can
do
this
down
to
the
low
level
things
like
and
I,
don't
understand
why
this
you
know
once
button
does
that
you
know
you
need
better
documentation
and
you
know
all
the
way
down
the
stack.
A
B
C
So
much
so
we
know
there's
some
users
in
the
node-red
Japan
user
group,
who
are
you
know,
a
really
active
user
group
and
get
some
really
interesting
stuff
coming
from
them,
they've
actually,
provided.
We
now
have
a
pool
request
that
allows
node-red
to
draw
the
flows
vertically
rather
than
horizontally
some
of
the
challenges
around.
That,
though,
are
now
sort
of
going
beyond
just
how
do
you
draw
them
vertically,
rather
than
horizontally
its
challenges
around
the
user?
Experience
of
how
does
that
mean,
we
have
to
mix
horizontal
and
vertical.
C
If
someone
creates
a
flow,
that's
vertically
aligned
and
a
horizontal
editor
imports
it.
What
do
we
do
and
so
that
so
we've
sort
of
got
beyond
the
basic
task
of
have?
We
got
the
code
to
draw
things
vertically,
and
you
know
we
have
that
code
now
we're
kind
of
at
the
point
now
well
now,
we've
got
that
we've
got
to
try
and
figure
out.
How
do
we
make
that
part
of
the
node-red
experience
without
compromising
the
node-red
experience
so
yeah.
A
C
That's
not
currently
in
the
1.1
plan.
It's
because
it's
to
us
a
slightly
knit
well,
in
my
mind,
lower
priority
based
on
conversations
but
again,
if
people
in
the
community,
you
feel
strongly
about
that.
We
can
bring
it
back,
but
you
just
know
that
there's
a
bunch
of
bench
of
user
experience
design
still
to
be
done
to
sort
that
out
properly.
B
C
C
So
I
think
they're,
two
slightly
different
ideas
there
around
the
packaging
so
on
the
net
Dave
talked
about
the
electron
side,
but
on
the
encrypted
side,
that's
a
it's
a
hard
problem
to
do
right,
because
any
sort
of
encryption
well
something's
got
to
have
a
key
that
can
decrypt
it.
So
yeah,
there's
in
terms
of
trying
to
create
well
best,
you
can
do
is
obfuscation,
but
ultimately
the
code
is
going
to
be
there,
that
someone
can
examine
I
mean
you
can
decompile
java
or
you
can.
C
We
know
there's
some
interest
around
encrypting
of
sub
flows
in
node-red,
so
allow
sub
flows
to
become
things
that
can
be
more
easily
shared
between
users.
But
perhaps
you
don't
want
to
share
the
inner
workings
with
the
user
because
it
might
contain
proprietary
information
but
again
you're
having
done
a
bit
of
design
work
around
that
it's
a
hard
problem
to
deal
with
the
key
management
of
how
you
encrypt?
C
A
For
the
electron
side
again
that
splits
into
at
least
two
versions
as
well,
there's
a
there's,
a
thought
about:
do
you
just
have
a
no
great
electron
that
way,
it's
basically
just
the
IDE
for
doing
editing
flows
and
you
pointed
out
a
flow,
or
you
pointed
a
different
machine
or
whatever
it
is
and
created.
Basically
a
note
of
an
editor.
A
One
yet
show
application
running,
and
we
already
have
there's
also
there's
a
electron,
no
Grid
project
out
on
github
that
I
run,
which
is
they've,
got
a
basic
skeleton
for
that
people
want
to
use
that
and
try
that
and
that
works
in
that
mode.
They
basically
have
it
gives
you
a
dashboard.
You
run
your
dashboard,
but
don't
expose
the
editor.
If
you
want
to
explore.
B
That
for
a
minute,
because
then
in
production,
you
really
want
to
separate
the
editor
from
the
runtime,
and
so
so,
just
being
able
to
run
sort
of
a
headless.
Node-Red
flows
becomes
a
really
important
part
of
that
12
factor
make
it
repeatable
and
controlled.
Do
you
see
NORAD's
scaling
up
in
a
in
a
production
set
of
environments
where
you
you've
got
pretty
heavy
workloads?
You
don't
really
want
to
bring
the
editor
along.
You
just
want
to
bring
the
runtime
forward
yeah.
C
So
we
already
have
all
the
bits
and
bits
to
do
that
today,
and
that
is
a
pattern
you
can
do.
I
think,
what's
distinct
about
the
electron
side,
is
it's
the
user
experience
of
how
you
install
it?
Frankly,
you
know
it's
it's
a
a
operating
system
native
installer,
whether
it's
your
own
Mac,
Linux
Windows.
You
know
it.
You
get
a.
C
C
Then
then,
that
electron
model
is
an
interesting
one
on
that
on
the
12
factor.
Side.
Absolutely
you
know
you,
you
want
to
have
version
control
you
want
to
have
repeatable
builds
and
yeah
I
and
I've
gone
blank
on
most
of
the
other
12
factors,
but
yeah.
They
are
they're
they're
well,
and
we
have
good
patterns
for
how
you
do
12
factor
4
with
no
dread
without
the
editor,
whether
it's
doing
it
with
containers.
C
Whether
it's
doing
you
know,
we've
seen
people
doing
interesting
things
around
Kubb
cuban
eighties,
around
managing
node-red
applications
and
again
that's
the
space.
I
would
like
the
node-red
project
to
have
more
content
on
and
more
patterns
within
the
project,
but
just
in
terms
of
where
our
resource
and
effort
has
so
far
been
applied,
that
that
isn't
something
we've
we've
produced
a
content
around.
But
but
we
know,
people
in
the
community
are
doing
it
quite
successfully.
B
B
C
C
One
of
you
know:
people
talk
about
spaghetti
code,
you
know
code,
that's
sprawling
and
just
a
real
mess.
One
of
the
downsides
of
the
visual
programming
like
no
dread
is
you
literally
draw
spaghetti
on
the
screen,
rather
than
metaphorically.
So,
just
thinking
about
how
you
lay
out
the
flows,
you
we
have
things
like
the
link,
node
that
allow
you
to
break
a
wire,
and
so
you
don't
see
the
wire
on-screen,
so
the
flow
can
jump
from
one
point
to
another.
A
C
C
So
a
good
example
is
the
runtime.
The
node-red
runtime
is
single
tenant.
It's
running
one
set
of
flows,
it's
not
a
multi-user
runtime,
but
it
does
allow
you
to
have
multiple
editors
connected
to
it.
At
the
same
time,
with
people
working
on
different,
you
know
working
on
the
flows
at
the
same
time,
and
if
one
user
deploys
changes,
it
notifies
all
the
other
users
and
interrupts
them
and
they
have
to
merge
the
changes
in
there
and
then
so
it's
better
than
it
used
to
be
because
it
used
to
be.we.
C
You
could
very
easily
over
right
someone's
changes
because
you
didn't
know
they're
deployed
and
update
it.
So
that's
good
that
we
don't
know
that
doesn't
happen.
The
downside
is,
it
can
be
quite
a
disruptive
experience
when
you
have
two
people
where
to
sing
at
the
same
time.
So
again,
that's
an
area.
I
would
like
us
to
improve
and
do
some
more
sort
of
automatic,
merging
and
more
real-time
editing
between
multiple
users
so
like
in
Google
Docs,
where
you
can
see
people's
edits
at
the
same
time.
C
You
know
what
would
one
of
one
of
my
many
side
projects
that
I've
started,
but
not
done
much
on
is
what
is
that?
How
would
we
work
so
that
if
two
users
have
the
editor
open
at
the
same
time,
they
can
see
what
the
other
person
is
doing
and
it
doesn't
matter
who
hits
deploy?
It's
it's
less
disruptive.
So,
but
it's
it's
the
user
feedback.
You
know
Dave
and
I
use
no
dread
in
the
way
we
use
it.
C
B
The
conversation
to
node
read
node
programmers,
so
my
typical
approach,
when
I
want
to
experiment
with
a
new
API
is
to
you
know,
poke
it
with
an
HTTP
request.
Node
I
build
a
table.
I
build
a
chart.
I
dropped
some
data
on
a
map,
I'm
certain
that
node-red
programmers
do
similar
things.
Well,
would
you
say
to
a
developer
who's
it
sort
of
at
that
cusp
of
he.
I
should
really
turn
that
API
into
a
node
red
node.
Where
would
they
go
for
for
guidance
and
help
for
that.
C
So
it's
an
area
where,
as
as
with
so
much
you
know,
we
want
more
documentation.
We
want
more
education
material
around
how
to
do
some
of
this
stuff
when
it
comes
to
creating
new
nodes
for
the
pallet.
There's
again,
one
of
the
great
things
of
having
you
know
what
two
and
a
half
thousand
third-party
nodes
publish
to
the
community
is.
There
are
a
lot
of
examples
out
there
lots
of
examples
you
can
learn
from
cribbed
from,
but
you
know,
I
will
fully
acknowledge.
C
A
All
those
above
yeah
absolutely
honest
and
documentation
translations
we
can
go
like
two
translations
or
three
translations
at
the
moment.
You
know
we
are
definitely
not
language
expert,
so
yeah.
Anyone
who
wants
to
help
do
some.
The
translations
that'd
be
great,
but
we
kind
of
need
like
more
than
one
person
per
language,
because
if
you
need
some
work,
we
just
take
somebody's
word
for
it
without
checking
it
and
nodes.
Obviously
improving
nodes
feedback
on
those
is
always
good.
A
Indeed,
there
are
some
other
projects
out
there,
but
there's
a
no
gen
project
we
have
which
actually
helped
generate
nodes
from
function.
Notes.
If
you
got
a
function,
though,
you
convert
it
into
a
real
node.
If
one
and
didn't
because
I
mentioned
you
know,
take
some
phones
and
make
those
into
nodes
a
bomb,
some
point
in
the
future.
A
Those
are
things
that
are
around
helping
some
we're
developing
some
of
the
other
bigger
features
that
mentioned,
and
we
like
that,
you
know
we
do-
need
help
with
designing
and
discussing
them
as
well,
because
you
know
some
of
these
are
great
ideas
that
somebody's
proposed
and
there's
a
quick
arguing.
If
a
quick
discussion
about
it,
they
will
goes
quiet
and
then
nothing
happens,
and
so
so
time.
So
why
wasn't
happen?
A
Because
it
needs
much
bigger,
in-depth
discussion
and
we
need
people
to
actually
engage
and
help
help
with
those
discussions
and
extra
feedback
force
on
these
bigger
topics,
because
we
can't
no,
you
can't
get
it
all
by
ourselves
all
the
time
and
if
we
just
if
we
sort
of
leave,
you
didn't
think
about
it,
we'll
just
be
sitting
there.
Thinking
about
it
for
a
long
time.
So.
B
B
C
C
You
know
they
don't
know
us,
we
don't
know
them.
So
you
know
it's.
It's
there's
a
there's,
certainly
a
skill
to
manage
in
the
community
that
you
know
you
need
to
recognize.
Whenever
someone
asks
a
question,
you
don't
know
who
they
are.
You
don't
know
what
mood
they're
in
you
don't
know
how
much
they
know
and
you
you
can't
assume
anything
about
them,
so
it
does
take.
You
know
it
does
take
effort
to
to
matter
to
work
in
the
community
and
keep
it
a
positive,
healthy
environment.
I
think
you
know
I
think
based
on
feedback.
C
We
have.
You
know
we
do
a
fairly
good
job
in
the
neighborhood
community
to
keep
it
a
welcoming
environment.
There's
a
great
group
of
people
on
the
forum
who
you
know
who
now
you
know
there's
it's.
It's
gone
from
the
case
where
Dave
and
I
have
to
answer
every
question
to
you
know
Dave
and
I
chip
in
when
there's
something
useful
for
us
to
chip
in,
but
but
the
community
really
does
get
involved
and
support
each
other,
which
is
positive
and.
B
Be
engaged
in
the
community
in
their
forums
as
well.
There
there's
a
question
that
I
wanted
to
bring
up
just
came
through
on
the
on
the
YouTube,
but
it
was
it's
about
no
read
on
constrained
devices
and
and
that
sort
of
leads
into
edge,
so
edge
devices,
sort
of
yester
constrained
by
memory
and
CPU.
We
we
want
to
be
able
to
run
node-red
at
the
edge
but
running
in
a
constrained
environment.
A
To
be
honest,
I
spend
a
lot
of
time
playing
with
things
at
the
edge
on
the
small
devices,
and
the
answer
is
only
owned
by
you
know,
trying
and,
and
things
like
that,
really
do
again.
This
goes
back
to
summer
tuning,
and
it
was
talking
about.
We
don't
have.
You
know
some
expertise
in
profiling
and
things
like
that,
and
we
do.
A
A
A
So
it's
some
of
its
down
to
the
underlying
no
chess
and
can
that
run
on
the
device
is
that
supported
on
the
device
as
well?
Most
certainly,
some
of
the
smaller
devices
now
know
chess
and
now
starting
to
abandon
32-bit
for
some
of
the
older
devices,
and
things
like
that.
So
we
are
kind
of
sitting
on
top
on
no
GS.
A
C
C
Now
the
node-red
runtime
is
designed
for
no
js',
you
unashamedly,
so
you
can't
just
drop
it
onto
one
of
those
of
the
runtimes,
but
I'd
certainly
think
that
there's
an
interesting
project
to
be
done
around
being
able
to
for
a
subset
of
nodes
being
able
to
do
code
generation
the
targets,
one
of
those
lighter
white
JavaScript
runtimes,
so
whether
it's
a
cut-down
node-red
runtime
or
it's
actually
doing
code
generation,
I,
don't
know
but
yeah,
we
again,
we've
long
talked
around.
That
would
be
really
interesting
idea.
C
Get
to
the
point
where
you
can
deploy
a
flow
to
a
tiny
device.
Yeah
you're
not
going
to
be
able
to
do
install
arbitrary
nodes.
It
would
have
to
be
a
custom
palette
of
nodes
for
that
device,
therefore
being
implemented
for
that
device.
But
but
again
you
know
the
programming
model.
Is
there
and
there's
no
reason
why
it
couldn't
be
the
node-red
user
experience
couldn't
be
extended
to
target
other
platforms
so.
B
One
step
above
those
really
constrained
devices
are
the
newer
raspberry
pi
for
the
Jetson
Nano
they're.
Actually
pretty
substantial
small
board,
Linux
computers
I
want
the
question
about
edge
and
maybe
starting
to
drift
towards
doing
AI
inferencing
an
AI
prediction.
Do
you
see
no
dread
plus
AI
becoming
an
important
pattern
in
the
future.
A
Absolutely
yeah
I
mean
we're,
certainly
playing
around
with
tensorflow
chess
I
know
this
mother
colleagues
of
ours
met
from
that
forum
as
well,
and
that
is
certainly
a
lot
of
interest
and
traction
again,
though
some
of
it
need
does
need
to
run
on
top
of
the
runtimes
underneath.
So
we
kind
of
rely
on
some
of
you
have
already
done
the
binaries
for
in
this
case,
that
case
tends
to
flow,
but
also
moving
over
things
like
can
you
run
optimizing
nodejs
honor,
my
folks
have
those
devices
in
quite
a
lot
of
the
problem.
A
B
Seen
some
really
interesting,
tensorflow
jas
node
starting
to
bubble
up
in
from
the
community
and
be
it's
going
to
be
a
fun
ride
to
see
where
edge
and
node
red
can
go
together.
But
but
so
let's
do.
The
next
thing
about
edge
is
managing
them
with
containerized
workloads.
So
I'm
really
would
love
to
hear
your
perspectives
on
containerization
and,
where
you
think,
node
red,
with
kubernetes,
with
openshift
with
operators,
could
be
going.
C
So
from
a
abstract,
no
dry
perspective
yeah,
we
we
focus
on
being
a
node.js
application,
and
you
know
that
beings
with
the
lowest
common
denominator
of
of
what
node
red
is
then
looking
at
okay.
Well,
how
do
you
then
take
that
application?
And
how
do
you
run
it?
Where
have
you
made
use
to
run
it
so
yep
containerization,
it's
important
one.
We
do
have
our
docker
images,
we've
kicked
around
ideas,
and
but
they
are
yeah
at
this
stage.
Just
I
do
over
a
cup
of
coffee,
rather
than
anything
in
the
actual
backlog
around
what?
C
If,
in
the
node-red
editor,
there
was
a
build
site
bar
that
gave
you
a
almost
a
one-click
experience
to
building
a
custom
docker
image
from
your
flows.
For
example,
you
know
lots
of
interesting
concepts
there
that
yeah,
when
you
look
at
whether
it's
Cuban
eighties,
whether
it's
OpenShift,
whether
it's
even
sort
of
service
environments
where,
whatever
it
might
be,
you
know
our
projects
focus
is
being
a
node.js
runtime
that
we
can
run,
and
this
is
what
we
say
we
run
wherever
you
can
run
no
js'.
C
You
know
we
talked
a
bit
about
the
electron
stuff,
creating
a
standalone
and
storable
version
of
node-red
again.
That
would
just
be
a
an
alternative
way
of
consuming
node-red.
It
wouldn't
replace
what
you
can
do
today.
You
know
you
would
still.
We
would
still
be
in
npm
module
that
can
be
installed
and
and
run
as
a
completely
embedded
runtime
in
a
bigger
node.js
application,
whatever
it
might
be,
but
the
electron
wrapping
would
make
it
more
consumable
to
a
different
class
of
user.
C
Perhaps
someone
who
doesn't
have
internet
access,
so
they
can't
run
an
NPM
install,
but
they
can
copy
a
zip
file
on
a
thumb
drive
to
get
a
native
installer
that
installs
the
application
onto
a
disconnected
device,
for
example.
So,
yes,
you
know
containerization
is
important
when
we
have
our
docker
images,
but
you
know
in
my
mind
it's
just
one
of
the
many
different
avenues
of
how
we
look
to
deliver
node-red
into
different
environments.
B
So
I
wanted
to
ask
Dave
a
question
about
node
Brad
dashboards.
There
was
a
question
from
our
submitted
comments
asking
about
refreshing,
no
read
dashboard
to
adopt
a
more
modern
framework
like
reactor
vous,
angular,
1.0,
sort
of
archaic
at
this
point,
but
really
a
amazing
things
are
being
done
with
no
red
dashboard.
We
see
some
great
notes
just
in
the
last
year,
the
red,
node
uik
ball
and
level
and
LED
there's
lots
of
interesting
things.
But
what's
your
thoughts
on
replacing
the
their
framework
yeah.
A
Okay,
so
to
be
honest,
the
dashboard
was
always
like
a
side
project
in
Sofia
we
we
adopted
because
it
was
providing
a
great
visualization
give
provided
by
the
guy
in
the
community.
We
then
actually
had
to
go
off
and
do
some
real
work
and
he
couldn't
maintain
it
for
a
while.
So
we
adopted
it,
it's
not
the
core.
The
product
project,
that
cool
project
is
obviously
the
main
node-red.
A
The
dashboard
is
is,
however,
in
our
first
class
citizen,
and
we
try
and
maintain
it
and
enhance
it
and
by
added
allowing
other
people
to
now
add
extra
widgets
to
it.
That
should
enhance
it.
Some
more
but
yeah.
We
internally
don't
have
any
desire
to
rewrite
the
whole
thing
again
from
scratch.
We're
quite
happy
to
let
other
people
do
that.
If
someone
else
wants
to
propose
a
project
to
bring
forward
a
project,
there
is
a
lower-level
project
called
UI
builder,
from
from
Julien
in
the
in
the
community.
A
You've
done
a
great
job,
they're,
providing
which
is
basically
a
bare-bones
framework,
hooks
hooks
into
node-red
and
all
of
them.
So
you
need
to
bring
your
own
frameworks
with
no
great
to
build
your
own
dashboards,
so
the
other
problem
with
dashboards
in
state.
Now
they
all
start
to
look
the
same,
so
everyone's
got
their
own
opinion
on
which
way
it
should
look
different.
So
you
know
we're
not
going
to
go
and
preach
as
that
and
bring
out
a
new
dashboard
any
time
soon.
C
The
other
interesting
point:
when
we
talk
about
modernizing
frameworks,
feedback
we
sometimes
or
questions
we
sometimes
get.
You
talk
about
this
of
the
sorts
of
questions
we
get
in
the
community.
You
know
we
get
the
questions
of
when
you're
going
to
rewrite
it
in
typescript
or
when
are
you
gonna
change?
The
editor
UI
toolkit
to
be
something
more
modern
than
jQuery
and
and
jobs?
It's
like
well.
In
my
mind,
I
purposely
chose
not
to
adopt
any
of
the
frameworks.
You
know
if
seven
years
ago
we'd
picked
the
latest
angular.
C
We
would
have
had
to
have
expended
a
huge
amount
of
resource
between
then
and
now
just
keeping
current
with
the
toolkits
as
they've
done.
However,
many
major
version
bumps
over
time,
so
it
does
mean
you
to
create
the
node
you
eyes.
Yes,
it's
it's
jQuery
and
JavaScript.
You
know
there's
nothing
wrong
with
that.
You
can
do
a
heck
of
a
lot
with
it.
Yes,
so
it
means
it's
a
it's.
Not
the
programming
experience
you
get
with
like
vue.js
framework
or
react,
but
you
know
we've.
C
It
was
a
conscious
choice
to
try
and
keep
it
relatively
vanilla
so
that
we
wouldn't
be
tied
to
upstream
projects
that
decide
to
you
know
deprecated
and
make
into
a
major
version
that
completely
breaks
previous
things.
So,
but
that
said,
you
know
if
people
wanted
to
explore
how
what
would
it
mean
to
create
a
node?
You
are
using
react
or
whatever
it
might
be.
C
B
Are
coming
close
to
at
our
time,
I've
got
two
more
questions
here
that
I
wanted
to
very
quickly
as
I
look
down
through
this
emitted
questions
I'm,
you
guys
got
a
couple
of
really
nice
love
letters
here,
justice
in
thanking
you
and
Dave
for
your
work
in
the
community
and
work
on
node,
rad
and
I
just
want
to
reflect
that
I.
Think
many
of
us
building
really
fun
amazing
apps.
On
top
of
your
work
and
I,
think
that's
a
great
testament
to
to
your
commitment
over
many
years.
So
thank
you
for
that.
Well,.
B
So
what
do
you
guys
think
about
doing
more
of
this,
this
discussion
format
and
they
asked
me
any
things:
have
you
thought
about
doing
a
node,
read,
conference,
someday
or
or
more
regulars
know:
Brad
meetup
we're
all
working
from
home
in
this
new
virtual
world.
Youtube
live
in
zoom
sessions,
and
why
not?
What
are
you
guys
about
doing
something
on
a
more
yeah?
Well,
absolutely.
C
So
I
mentioned
the
node-red
Japan
user
group,
your
very
consciousness,
the
time
we
have
remaining
so
the
new
pan
user
group
have
been
really
active
for
a
number
of
years.
Now
they
do
have
regular
meetups
and
they
last
year
held
a
conference
in
Tokyo
and
they
are
currently
planning
a
conference
for
fourth
quarter
this
year.
C
But
obviously
you
know
given
given
the
world
situation,
who
knows
where,
whether
that
what
whether
that's
going
to
be
able
to
go
ahead
or
not
I've,
always
yeah
I'd
love
to
be
able
to
do
some
sort
of
node-red
event
again,
the
fact
we're
kind
of
stuck
to
doing
things
virtually.
You
actually
works
in
our
favor,
so
yeah.
B
B
Well,
I
think
I
want
to
wrap
up
here
with
a
huge
shout
out
and
thank
you
Nick.
Thank
you.
Dave
I
wanted
to
thank
the
community
for
joining
us
today
and
you
know
continued
conversations
in
the
in
the
channels
really
delighted
that
the
open
jazz
foundation
brought
us
all
together
are
for
this
ask
me
anything
and
so
Wow
any
last
thoughts
and
we'll
close
ourselves
up
yeah.
A
C
No,
absolutely
you
know
thank
you
to
everyone.
You
know
those
those
who
know
us
who
have
long-standing
members,
the
community,
those
who
are
joining
this
for
the
first
time,
trying
to
find
out
more
about
node-red
yeah.
Thank
you
to
the
community.
It's
the
community
that
makes
open-source
and
you
know
yes,
Dave
and
I-
spend
our
time
writing
code.
But,
frankly,
you
know
the
code
would
be
meaningless
without
without
the
community
behind
it.
So
you
know
thank
you
to
ever.