►
From YouTube: Low Code for the Node.js Developer - Nick O Leary, IBM
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi,
my
name's
Nick
O'leary
I'm
an
open
source
developer
at
IBM
and
the
project
lead
of
node-red
in
this
talk,
I'm
going
to
cover
loco
development
and
why
it's
interesting
for
JavaScript
and
node
developers
alike,
I'm,
going
to
use
node-red
as
an
example
of
a
loco
development
tool
and
show
how
it
can
be
easily
extended
by
adding
new
nodes
to
its
palette
of
capabilities.
I'll
also
talk
about
what
lessons
developing
modules
for
a
loco
development
environment
can
be
applied
when
creating
regular
node.js
modules.
A
So,
to
start,
let's
talk
about
loco
development
to
help
put
it
into
context,
let's
just
step
back
and
think
about
how
coding
has
evolved.
In
the
beginning,
there
was
machine
code,
the
raw
binary
used
by
the
computer,
to
control
its
circuits.
As
a
developer,
you
had
to
speak
the
computer's
native
language.
The
second
generation
of
languages
were
assembly
languages.
These
were
the
first
steps
towards
accommodating
of
programmers
needs
rather
than
those
of
the
computer.
We
then
have
a
third
generation
languages,
which
is
what
many
of
us
think
of.
A
When
we
talk
about
programming
languages
today
see
Java,
Python,
JavaScript
and
so
on.
They
are
much
more
independent
of
the
machine
they
run
on.
They
are
far
more
portable,
some
more
than
others.
They
provide
structured
data
types
rather
than
simple
bits
and
bytes.
They
provide
easier
ways
to
organize
and
structure
code,
and
then
we
come
to
the
fourth
generation
of
languages.
A
They
tend
to
be
more
domain-specific
tools,
with
much
less
of
a
focus
on
bits
and
bytes
and
more
interested
in
the
higher
level
data
they
work
with,
and
the
key
thing
to
recognize
is
the
increased
labor
abstraction
as
you
go
through
these
generations
of
language.
Each
abstraction
moves
your
way
from
having
to
understand
the
machine
code
from
having
to
deal
with
low-level
memory
management
from
having
to
decide
how
best
to
represent
your
data
in
whatever
binary
format
as
developers.
A
We
accept
those
abstractions
for
what
they
are
they're
our
convenience
to
make
us
more
productive
and
those
abstractions
do
more
than
just
that.
A
modern
compiler
can
generate
machine
code.
That's
highly
optimized,
probably
far
more
so
than
if
you
try
to
write
it
by
hand
because
they
can
fold
in
the
decades
of
experience
and
knowledge
that
exists.
A
A
No
code
programming
means
just
that
the
user
who
may
well
not
consider
themselves
a
developer
in
the
slightest
does
not
need
to
touch
anything
that
looks
remotely
like
code,
a
great
example
that
menu
review
be
familiar
with
is
if
this
than
that
as
a
web
service,
it
allows
you
to
create
workflows
in
your
browser
purely
through
clicking
options.
Whilst
it's
very
versatile,
it
does
keep
you
somewhat
constrained
to
the
types
of
integrations
they
support
and
there's
nothing
wrong
with
that,
except
when
you
want
to
do
that.
Extra
little
thing.
A
That's
slightly
off
the
rails
that
they
keep
you
on
low
code
by
contrast,
still
allows
the
user
to
create
workflows
through
visual
tools,
but
it
does
give
the
user
some
more
leeway
to
insert
bits
of
code
when
it's
needed.
Different
loco
tools
provide
different
degrees
of
flexibility.
In
that
regard,
the
higher
level
of
abstraction
also
helps
to
make
it
more
accessible
to
a
wider
range
of
users.
By
hiding
the
individual
lines
of
code,
a
user
is
able
to
focus
on
solving
whatever
problem
they're
trying
to
address.
A
They
can
also
be
tailored
to
particular
problem
domains,
so
they're
presented
in
terms
of
domain
experts,
who
may
not
be
a
developer,
is
able
to
relate
more
closely
to
and
making
it
easier
for.
A
wider
range
of
users
to
be
able
to
create
applications
is
a
good
thing,
but
how
does
this
relate
to
no
js'
and
JavaScript?
Well,
with
node,
you
see
a
similar
pattern
of
distraction.
Node
core
provides
a
set
of
standard
libraries
to
provide
an
abstraction
over
the
v8
engine.
A
You
have
things
like
HTTP
module,
but
more
than
not
you'll
use
a
module
that
wraps
the
low-level
HTTP
API
into
something
more
consumable.
Axios
got,
or
whichever
is
the
flavor
of
the
month.
These
modules
don't
stop
you
as
a
developer
from
using
the
lower-level
api's,
but
it's
often
more
comfortable
to
use
the
higher
level
abstractions,
and
it
goes
in
the
other
direction
as
well.
A
If
you
haven't
seen
node
read
before
this
is
what
it
looks
like
you
get
a
browser-based
editor
with
a
pallet
of
nodes
down
the
left-hand
side
and
a
workspace
in
the
middle.
Where
you
drag
on
the
nodes
to
create
your
flows,
each
node
represents
a
discrete
piece
of
functionality
and
it
acts
as
a
black
box.
It
receives
a
message,
does
something
with
that
message
and
then
passes
it
on
to
whatever
other
nodes,
it's
wired
to
so
in
this
environment.
A
You're
drawing
the
logical
flow
of
information
here,
I
have
a
flow
that
defines
an
HTTP
endpoint
when
the
HTTP
request
arrives
at
node
read
this
node
is
triggered.
The
message
it
passes
on
contains
information
about
the
incoming
request.
We
pass
that
to
a
template,
node
that
generates
HTML
content
using
the
data
provided.
A
Those
two
files
are
then
packaged
as
a
regular
node
module
by
adding
a
packaged
or
JSON
file
that
contains
a
custom.
Node
read
section
that
identifies
the
files
and
the
module
containing
nodes.
Let's
dive
into
a
nodes
code
to
see
how
its
structured,
a
node
module,
has
to
export
a
single
function.
This
function
is
called
when
the
module
is
being
loaded
into
the
node-red
runtime.
It
gets
passed
in
an
object.
That's
the
nodes
handle
into
the
runtime
api.
A
Next,
the
code
defines
a
constructor
function
for
a
node.
This
gets
called
whenever
the
runtime
needs
to
create
a
new
instance
of
that
node.
That
happens
whenever
the
users
made
some
changes
in
the
editor.
They
click
the
deploy
button,
the
editor
packages
up
the
configuration
in
a
JSON
format
and
sends
it
back
to
the
runtime,
the
runtime
then
loops
through
all
the
nodes
and
the
flow
configuration
and
creates
instances
of
each
one
passing
in
the
configuration
for
that
particular
instance.
A
So,
within
the
constructor
function,
the
first
thing
has
to
do
is
call
this
utility
function
called
create
node.
That
turns
this
object
into
a
proper
node
red
node.
It
can
then
do
whatever
work.
It
needs
to
do
to
get
ready
to
start
handling
messages,
for
example,
it
needs
to
validate
its
configuration.
Maybe
it
needs
to
establish
a
connection
to
a
remote
system,
whatever
it
needs
to
do
so.
At
this
point,
we've
defined
the
code
for
creating
the
node.
Next,
we
need
to
define
how
the
node
will
handle
messages.
The
run
time
passes
it.
A
This
is
done
by
adding
a
handler
for
the
input
event.
The
event
is
triggered
whenever
there's
a
message
for
the
node.
An
important
point
to
know
here
is
the
events
are
handed
completely
asynchronously
to
when
they're
emitted,
which
is
unlike
the
core
node
event.
Emitter
object,
which
is
fully
synchronous.
A
The
event
handler
is
passed,
the
message
being
received
a
send
function
and
a
done
function.
The
handler
can
do
whatever
work
it
needs
to.
In
response
to
that
message.
If
it
wants
to
send
a
message
on
within
the
flow,
it
can
pass
the
new
message
to
the
send
function
once
it's
finished
its
work
for
that
message,
it
calls
the
done
function.
Now
this
send
done.
Parra
functions
were
new
additions
in
node
Reds
wander
over
lease
late
last
year.
Before
that
nodes
would
use
the
node
object's
own
send
function.
A
The
reason
for
using
the
passed
in
function,
though,
is
it:
has
the
runtime
to
correlate
to
the
call
to
send
with
the
message
that
was
received,
allowing
for
better
traceability
of
your
flows.
That's
something
we
need
to
make
easier
to
do
within
the
project
generally
now.
Finally,
the
node
may
also
register
a
handler
for
the
close
event.
A
This
gets
called
when
if
the
node
is
being
stopped
by
the
runtime
either
because
a
new
set
of
flows
are
being
deployed
or
the
runtime
itself
is
being
stopped,
this
allows
the
node
to
clean
up
any
internal
state,
such
as
its
database
connections
or
whatever
resources
is
created,
and
that's
largely
it
in
terms
of
the
framework
for
creating
a
node.
There
are
a
bunch
of
other
API
s
for
logging
errors,
updating
node
status
and
other
features
that
we
don't
need
to
get
into.
A
Switching
to
the
HTML
side
of
the
node,
there
are
three
things:
the
HTML
content
for
the
nodes,
edit
dialog
help
text
and
the
jot
script
code
used
to
register
the
node
with
the
editor,
which
defines
various
aspects
of
its
appearance
and
lists
out
the
properties
of
the
node
that
can
be
configured
by
the
user.
The
definition
also
includes
optional
JavaScript
functions
that
will
be
run
when
the
Edit
dialog
for
node
is
being
opened
or
closed.
A
This
allows
the
Edit
dialog
provide
a
much
richer
user
experience
than
just
a
plain
HTML
form
the
edit
of
bundles
jQuery,
but
doesn't
otherwise
use
any
JavaScript
toolkit
for
its
UI
generation.
We
occasionally
get
asked
about
angular
react
or
one
of
the
other
various
JavaScript
frameworks,
but
we've
generally
tried
not
to
tie
ourselves
to
one
framework
or
another.
A
The
editor
does
provide
a
number
of
useful
widgets
that
nose
can
use
to
go
there.
You
eyes,
such
as
the
typed
input,
which
allows
the
user
to
specify
the
type
of
a
property
as
well
as
its
value.
This
makes
for
a
much
more
consistent
user
experience
rather
than
having
each
node
creates
its
own
way
to
do
it.
So,
given
the
time
available
today,
I'm
not
going
to
delve
any
deeper
into
how
to
create
nodes.
Instead,
I
wanted
to
talk
a
bit
more
about
the
general
design
principles
that
apply
when
creating
them.
A
When
designing
a
node
for
no
dread,
the
first
thing
to
consider
is
who
the
audience
is,
who
are
the
people
that
will
install
the
module
ad?
It's
the
palette
and
drag
it
into
their
workspace
with
low
code
platforms
like
node
read,
you
have
to
remember
the
users
come
from
a
much
broader
range
of
experience.
They
may
already
be
deeply
familiar
with
whatever
functionality
your
node
provides,
or
they
may
have
no
knowledge
of
the
underlying
details
and
just
know
they
need
that
functionality
in
the
node
provides.
A
A
The
first
is
making
it
intuitive.
The
nodes
configuration
is
stored
as
a
set
of
JSON
key
value
pairs.
Expressing
that
as
a
plain
list
of
texts,
Bach
labels
assumes
the
user
will
know,
what's
expected
in
each
box.
For
a
simple
note
that
expects
perhaps
just
a
URL,
username
and
password.
That
may
well
be
good
enough,
but
when
there
starts
to
be
lots
of
other
options,
a
different
approach
might
be
needed.
A
One
of
the
approaches
we
took
with
the
core
trigger
note,
for
example,
was
to
build
the
UI
in
such
a
way
that
the
user
could
read
how
it
was
configured
almost
as
an
English
sentence.
Send
hello
then
wait
for
five
seconds
then
send
goodbye.
It
doesn't
approach
that
would
work
in
all
cases,
but
it
certainly
helped
in
this
case
every
feature.
An
option
you
add
to
the
node
increases
the
cognitive
burden
of
using
the
node
for
feature
rich
nodes.
A
It
can
be
quite
hard
to
design
their
UI
to
write
all
of
those
features
without
also
making
it
much
harder
to
find
a
particular
option.
A
user
needs
to
use
providing
your
user
with
a
clear
hierarchy
of
choice
can
also
help
them
reach
their
desired.
Configuration
by
that
I
mean
only
presenting
options
that
are
relevant
to
the
choices
a
user
is
made
up
to
that
point,
there's
certainly
a
balance
to
be
made
here,
having
options
appear
and
disappear
if
overdone
could
also
be
confusing
to
the
user.
The
key
is
finding
that
right
balance.
A
The
next
principle
is
about
having
sensible
defaults,
and
this
very
much
follows
on
from
the
making
the
node
intuitive
to
use.
It
should
come
with
a
sensible
set
of
default
configuration
values,
don't
force
the
user
to
have
to
set
everything
they
the
first
time
they
want
to
use
the
node.
A
good
example
of
this
is
the
split
node.
This
node
can
be
used
to
turn
a
single
message
into
a
stream
of
multiple
messages
by
default.
If
you
give
to
string,
payload
you'll
send
a
message
for
each
line
of
text
in
that
string.
A
A
A
The
third
Prince
was
about
choosing
what
can
be
controlled
dynamically
nodes
exposed
to
different
API
surfaces
to
the
user.
The
configuration
properties
set
in
the
edit
dialog
and
the
properties
of
the
individual
messages
passed
of
the
node,
both
the
means
to
control
the
nodes
behavior,
but
that
doesn't
mean
everything
should
be
exposed
in
both
ways.
A
The
HTTP
requests
node
allows
you
to
set
the
URL
of
the
request
in
the
node
itself.
That's
useful
if
you're
sending
the
request
to
a
fixed
end
point
whether
URL
never
changes,
but
the
node
also
allows
you
to
pass
in
message
to
RL
to
set
the
URL
on
a
per
message
basis.
The
node
also
lets
you
set
custom
HT
headers
for
the
request
by
setting
message:
dot,
headers,
but
that's
an
example
of
an
option.
A
That's
not
exposed
in
the
nodes,
edit
dialog
there's
an
important
design
principle
here
as
well
that
a
message
property
should
not
override
a
property.
The
user
has
explicitly
set
in
the
nodes
edit
dialog,
for
example,
in
the
request
node
case.
If
the
user
has
provided
euro
in
the
edit
dialog,
then
the
node
will
ignore
message:
dot
URL.
This
was
a
deliberate
choice
to
avoid
the
cases
where
a
nodes,
behavior
changes
unexpectedly,
because
a
user
didn't
realize
a
property
happen
to
still
be
set
on
a
message
in
the
flow.
A
The
fourth
principle
is
about
being
forgiving
notes
should
be
forgiving
in
what
they
receive
and
be
kind
when
things
go
wrong
and
a
good
example
is
the
mqt
node
an
empty
message.
Payload
is
just
a
collection
of
points,
but
the
node
will
accept
any
JavaScript
type
and
try
to
do
the
right
thing
with
it
strings
numbers
boolean's
all
get
handled,
as
we
think
the
user
would
expect
them
to
be
passing
in
an
array
or
objects
will
lead
it
to
be
stringify
to
jason
automatically
before
it
gets
published
and
I'm
sure.
A
We've
all
tripped
over
the
handling
of
false,
like
values
in
JavaScript.
If
a
node
accepts
a
true
false
flag
as
a
message
property
take
care
to
consider
how
it
handles
non
boolean
type
values
should
undefined
null
0
and
empty
string.
Behave
as
you
think
it
would
v.
Prince
was
handling
with
grace.
One
of
the
most
important
things
is
ensuring
nodes
have
the
proper
error
handling
to
avoid
the
dreaded
uncaught
exception.
An
uncaught
exception
will
cause
the
runtime
to
shut
down
in
the
immortal.
A
Words
of
the
nodejs
documentation
is
simply
not
safe
to
resume
normal
operation
after
an
uncaught
exception,
attempting
to
resume
normal
after
an
uncaught
exception
can
be
similar
to
pulling
out
the
power
cord
and
upgrading
computer
nine
out
of
ten
times.
Nothing
happens,
but
the
tenth
time
the
system
becomes
corrupted
restarting
is
the
only
option
we
have.
A
The
sixth
principle
is
about
being
consistent
with
such
a
large
ecosystem
of
nodes
available.
There
are
a
whole
bunch
of
well-established
patterns
for
how
nodes
look
and
behave.
What
is
good
to
challenge
those
norms?
It's
less
good
to
reinvent
the
wheels
for
sake
of
it
use
the
patterns
that
exist
use.
The
common
UI
widgets
node-red
provides
follow
the
style
guide
for
the
help
text.
It
all
makes
for
a
better
user
experience.
A
A
Api's
are
all
about
user
experience
just
because
you're
exposing
your
module
VAR
an
exported
code
API
rather
than
the
visual
wrappings
of
a
low
code
environment.
You
still
want
to
ensure
the
user.
Experience
means
it's
a
joy
to
use
a
well
defined
API
that
puts
the
user
first
above
the
internal
implementation.
Details
will
always
provide
a
better
end
result
get
the
externals
right
first,
as
they
are
so
much
harder
to
change
down
the
line
compared
to
internals.
A
Now,
if
you
maintain
a
node.js
module
that
you
think
would
be
interesting
to
expose
in
a
low
code,
programming,
environment,
I,
hope,
I've.
Given
you
a
bit
of
a
bit
of
a
flavor
of
some
inspiration
to
try
it
out
with
no
dread,
if
you're
interested
in
learning
more,
then
please
do
get
in
touch
via
the
project.
Slack
or
discourse
forum.