►
From YouTube: A Double Header with Blazor - PHINUG 2021.06
Description
This session is run by the Philippine .NET Users Group (https://meetup.com/phinug) that hosts meetups in Manila, Philippines.
Meetup link: https://www.meetup.com/phinug/events/278610403/
For our next session we're going to get a double-header!
Why Blazor? A CTO's perspective
- In this talk, mindzie's CTO Soren Frederiksen will be talking about why mindzie chose Blazor and how has it helped mindzie with their products
Lessons from Blazor Server in Production
- In this talk, mindzie's Software Development Manager Kedren Villena will be talking about the different things that his team learned while using Blazor Serve for real world projects. He'll also share some tips and tricks when using Blazor Server.
======
About our speakers:
Soren Frederiksen is the Founder and CTO aka Head Nerd of mindzie. He held several leadership roles in various IT orgnizations before founding mindzie in 2020. Outside of tech, he is an accomplished Freediver and respected leader in the Freediving community.
Kedren Villena is a Software Development Manager for mindzie. He has been a regular speaker in PHINUG and other community events such as SOFTCON, where he had talked about .NET, software quality, and distributed systems design.
A
My
name
is
john
limhapp,
I'm
the
community
manager
of
the
philippine.net
users
group
and
I'm
a
principal
developer
for
a
company
called
page
up
and
tonight
we're
going
to
have
two
speakers.
Hence
a
doubleheader
talking
about
blazer
and
talking
about
their
experiences
and
share
sharing
their
experiences
about
about
using
it
for
for
for
their
work,
but
before
we
before
we
go
to
that.
So
so,
let's
just
you
know
a
few
words
for
for
our
sponsors.
We
we
would
like
to
thank
it's
not
moving
there.
A
A
Meetup.Com.Net
virtual
dash
user
dash
group,
so
that
you
would
be
able
to
you
know,
get
event
alerts
not
just
for
the
philippine.net
users
group
live,
live
stream
of
of
the
online
dev
session,
but
also
about
the
fro
for
the
events
from
around
the
world
from
different
dotnet
user
groups.
Different
microsoft
stack
groups
that
are
out
there
talking
about
everything
from
from
web
to
the
cloud
blazer,
all
all
things,
microsoft
where
they
are
are
discussing.
A
A
For
for
about
a
couple
of
years
now,
and
for
many
of
us
yeah,
we
haven't
been
able
to
really
have
an
opportunity
to
try
it
at
work
and-
and
you
know,
there's
some
feeling
of
there's
some
feeling
of
apprehension
for
some
people,
especially
those
who
have
been
burned
by
by
by
house
silver
light
how
the
whole
silver
light
affair
went.
You
know
in
the
past,
so
this
is
so
so
it
would.
A
B
A
C
B
This
picture
by
the
way
is
taken
last
week
when
I
went
for
a
morning
swim
something
I
do
fairly
often
the
ocean
to
to
to
relax
and
one
of
the
interesting
things
in
a
picture
like
this
there's
not
a
lot
of
stuff
on
this
picture,
and
I
think
a
lot
of
people
will
say
that
this
is
actually
that
looks
nice.
It's
very
pretty
so
I
do
think
that
when
we
develop
the
most
important
is
to
try
to
figure
out
not
to
kind
of
keep
adding
stuff
to
our
development
right.
B
So
very
often
when
we
develop
stuff
that
doesn't
work,
people
will
put
layers
on
instead
of
going
back
to
the
fundamentals
and
the
guy
like
elon
musk
is
very
good
at
talking
about
this
first
principles:
let's
go
to
the
bare
bones
and
see
what's
going
on,
and
I
want
to
talk
a
little
bit
about
that,
because
it
has
a
big
impact
on
exactly
what
john
just
talked
about
on
silverlight
microsoft,
history,
and
why
do
we
choose
blazer
like?
Why
do
we
trust
blazer
now
on
this
stuff
right?
B
So
I
changed
this
quote
actually
from
perfection
to
excellence,
because
I
don't
think
perfection
is
achievable,
but
excellence
is
and
one
of
the
things
we
do
a
lot
as
developers
is
we
release
stuff
and
then
we
iterate
over
it
and
make
it
better
and
better
as
we
go.
So
nothing
is
kind
of
perfect
out
of
the
gate.
It
kind
of
becomes
perfect
with
iteration
one.
Other
thing
I
think
that's
never
talked
about
enough
in
development.
Is
development
is
a
technical
skill
right
software
development
is
technical
skill,
but
product
development
is
not
product
development.
B
I
find
more
as
a
an
art
than
a
skill
and
figuring
out.
How
do
we
make
a
good
user
experience?
My
title
is
actually
head
nerd,
I'm
a
proud
nerd.
I
still
develop
quite
a
bit,
but
often
us
nerds
forget
the
user
in
the
screen.
Right
often,
I
hear
stuff
like
yes,
but
it's
working
on
my
computer
or
I
know
how
to
do
this,
but
we
forget
to
interact
with
the
user,
so
so
having
some
of
this
in
here.
B
What
we
do
at
mines
is
is
taking
technology
and
making
it
really
simple
for
users
that
does
not
need
a
phd
to
use
our
tools,
that's
kind
of
our
main
goal
of
what
we
do
so
translating
our
technical
stuff
into
very,
very
simple,
to
use
tools,
and
it
is
not
just
a
ui
that
needs
to
be
simple
right.
It's
everything
in
development
to
the
maintenance,
all
the
way
through.
So
if
we,
if
also
to
you
guys
spending
time
with
my
me
with-
I
appreciate
it-
it's
like-
why
should
you?
B
Why
should
you
even
listen
to
what
I'm
talking
about
right?
That's
a
little
bit
about
my
background
and
you
can
find
this
on
linkedin
as
well.
I
I
did
neural
network
development
in
the
90s,
which
is
quite
a
long
time
ago
I
mean
I
started
developing,
maybe
before
some
of
you
were
born,
so
I've
been
doing
this
for
a
long
time.
That
doesn't
mean
I'm
have
to
be
good
at
it.
B
I
could
be
bad
at
it
for
a
long
time,
but
I'd
spend
a
lot
of
time
on
different
levels
of
development,
so
neural
networks
were
the
beginning
is
if
some
of
you
guys
know
that
jeffrey
hinton
is
the
big
guru
he's
in
deep
learning
he's
one
of
them.
He
actually
started
here
in
toronto.
Ontario
around
the
same
time
was,
I
was
actually
doing
it,
but
neural
networks
didn't
really
take
off.
He
started
early
90s,
actually,
actually
late,
80s
and
neural
networks
haven't
really
started
taking
off
and
ai.
B
We
didn't
going
to
hear
about
it
until
2012.,
so
it
was
a
long
ramp
up
for
the
technology
to
actually
be
introduced.
So
muffled
blazer
is
just
starting,
so
it'd
be
interesting
to
see
how
quick
is
the
adoption
rate
on
blazer,
but
ai
took
almost
20
years
2012,
they
did
a
seminal
paper
and
an
imagenet,
and
that
really
took
off.
So
all
this
stuff
we
did
in
the
early
90s
it
all
worked.
It
was
just
too
early
technology.
B
B
After
this
I
actually
started
a
company
where-
and
this
this
is
relevant
for
our
talk
a
little
bit
about
technology
selections.
I
started
the
company
around
2003,
where
we
had
the
choice
between
using
c-sharp
or
visual
basic.
So
I
I
came
from
c
c
plus
plus
did
low-level
development.
Did
some
ui
development
as
well
on
c
plus
any
of
you
remember,
mfc,
that
was
back.
B
It's
not
that
close,
but
it's
not
that
far
from
you
guys
and
if
you
go
to
any
casino
in
macau
and
you
do
anything
bad,
you
steal
you
cheat.
Hopefully
you
don't!
But
if
you
do
they
end
up.
Writing
a
report
about
you.
That
report
ends
in
a
software
called
itraq
and
every
single
casino
in
macau
uses
itrack,
which
is
the
software
we
built,
which
I
started.
B
One
of
my
best
decisions
we
made
back,
then
we
almost
chose
visual
basic
because
it
was
it
had
a
lot
more
tooling.
Back
in
the
day,
I
am
so
glad
we
did
and
c-sharp
was
brand
new
was
out
in
version
one
and
then
1.1.
This
is
kind
of
when
we
started
this.
The
tools
weren't
really
there.
Yet
there
were
some
bugs
in
it,
but
it
was
the
best
decision
we
ever
made
because
visual
basic.
B
B
So
what
do
we?
What
are
we
actually
building
at
minzy
right?
What
does
mind
see
do
and
at
our
core?
One
of
the
things
we
do
is
something
called
process
mining.
Let
me
just
see
if
there
are
any
questions
here,
nope
not
so
far.
So
please
ask
questions.
If
you
have
and
we'll
I'll
try
to
answer
them
the
best
I
can
as
we
go
along
so
process.
B
Mining
is
a
technology
that
was
actually
started
by
a
professor
in
in
the
netherlands,
a
guy
called
bill
van
de
alf,
and
it
was
in
1999.
So
it's
an
old
technology
when
you
kind
of
think
about
it,
there's
very
little
adoption
of
process
mining.
Yet
in
north
america,
there's
large
adoption
in
europe
and
what
process
mining
does
and
if
I
actually
just
try
to
just
show
you
a
little
bit
of
our
tool.
B
Now
I
can
show
you
what
what
you
can
actually
do
with
process
mining,
but
it's
only
a
part
of
our
technology
is
you
can
extract
data
out
of
process
systems
so
and
process
systems
could
be
any
erp
system
that
you
have
anywhere
where
you
enter
in
the
process
and
the
one
that
I'm
showing
here
is
just
a
an
invoice
for
paying
in
it's
called
accounts
payable,
and
it's
where
you
pay
your
invoices
in
a
company.
So
the
process
you
would
like
to
happen
is
the
vendor.
Sends
you
an
invoice.
B
B
If
we
look
at
here
when
we've
extracted
data-
and
this
is
anonymized
data
from
a
real
company-
what
they
do
most
of
the
time
actually
in
28
of
their
cases,
we
can
actually
show
them
that
most
of
the
time
what
they
do,
is
they
they
get
the
vendor
invoice.
They
actually
miss
the
due
date
even
before
they
put
it
into
their
system,
and
then
they
pay
the
invoice.
So
this
is
obviously
not
desirable
and
we
can
show
them
things
so
process.
B
Mining
takes
data
from
erp
system,
extracts
it
out
and
presents
it
in
a
form
that
a
user
can
use.
So
when
we
wanted
to
build
process
mining,
we
have
to
kind
of
figure
out
what
are
the
parts
in
doing
that
right?
We
have
to
extract
stuff
out
of
erp
system
to
improve
processes.
We
want
to
use
ai
tools
to
figure
out
where
things
are
good
and
bad
and
learn
from
previous
mistakes
and
learn
from
different
tenants
in
our
environment.
B
B
It's
there's
so
many
more
benefits
from
being
in
the
cloud
with
continuous
integration
and
continuous
delivery,
which
is
from
somebody
who's
been
delivering
software
on
site
for
almost
12
to
14
years.
It
is
a
much
easier
process
and
it's
a
much
better
experience
for
the
user
having
the
ability
to
update
more
frequently
not
have
to
rely
on
their
own
it.
So
a
cloud
for
us
was
a
must
and
then
there
are
really
only
kind
of
three
major
suppliers
of
cloud
services.
There
are
others
ibm
you
could
put
in
here.
I
I
don't.
B
I
don't
really
consider
ibm
not
for
the
market,
we're
in
and
then
some
of
the
things
we
had
to
build.
We
had
to
build
some
very
proprietary
algorithm,
there's
a
lot
of
open
source
and
research
papers
on
process
mining.
So
we
had
to
build
all
these
algorithms
and
a
lot
of
them
came
from
java
or
python.
B
So
one
of
the
reasons
we
didn't
choose
java
and
one
of
the
reasons
we
don't
just
take
sample
code
pretty
much
ever,
is
unless
you,
if
you
put
any
code
in
your
system
and
you
have
to
support
it,
so
you
have
to
maintain
it
down
the
road.
If
you
don't
understand
it
and
something
goes
wrong
and
there
are
no
support
for
it
in
big
industry
development
you're
in
trouble
right,
because
something
always
breaks
in
our
code
most
of
the
time
right.
B
So
some
of
some
of
the
first
things
we
actually
also
looked
at
when
we
did.
This
is
what
are
the
things
that
we're
building
right?
This
was
early
on
in
the
stage.
I
won't
show
that
many
architectural
diagrams,
because
I
don't
think
it's
that
relevant
here,
but
we
have
three
pillars
that
we
kind
of
have
to
do.
We
have
our
extraction
stage
where
we
pull
data
out
of
large
erp
systems,
and
we
support
a
little
more
than
20
of
them
currently
and
its
list
is
growing,
so
there's
a
lot
of
different
databases
or
apis.
B
A
B
Where
open
source
has
a
lot
of
that
in
java
and
a
lot
of
it
comes
from
python
python,
I
don't
think
is
a
great
tool
for
production.
I
know
people
do
I
just
don't
like
it
as
much.
There
are
lots
of
tools
that
now
take
jupiter
notebooks
and
turn
them
into
production,
ready
stuff,
I'm
not
a
big
fan
of
that,
and
I'm
not
a
big
fan
of
java
either.
So
engine
also
needed
to
be
really
fast.
B
Speed
was
a
fairly
big
portion
of
this,
but
integration
with
ai
tools
was
was
a
bigger
one.
Again.
Python
is
the
best
tool
there,
but
there
are
now
other
alternatives,
especially
with
the
cloud
providers
you
can.
You
can
use
other
tools
to
integrate
with
so
the
the
third
part
of
this
is
actually
the
presentation
to
the
user.
The
ability
for
the
user
to
play
with
this
data
set
up
some
of
the
pieces
they
want
and
so
whole
our
whole
ui
layer.
B
So,
each
one
of
these
three
layers,
we
probably
spend
equal
amount
of
time
on
they'll,
look
different
in
our
history
and
where
we
spend
it
so
blazer
would
only
be
one
part
of
it,
but
where
you
can
see,
blazer
has
a
huge
benefit.
Is
a
development
talent
that
goes
in
our
ui
side.
It
would
be
nice
if
they
can
move
into
the
engine
and
the
extraction
side
and
understand
what's
going
on
it
just
makes
them
better.
B
But
usually
you
tend
to
be
good
at
really
really
good
at
one
language,
maybe
two,
but
the
fewest
of
us
can
can
actually
handle
three
four
five
different
languages
and
be
really
good
at
all
of
them.
So
having
a
language,
a
common
across
all
these
pillars,
we
found
was
a
a
very
nice
thing
to
have
it's
not
a
must,
but
it
was.
B
It
makes
a
lot
easier,
so
technical,
that's
the
other
one
when
you
have
here
after
we've
been
doing
this
couple
years,
you
need
to
be
able
to
maintain
these
versions
and
that's
definitely
one
of
the
things
I've
seen
in
the
dot
net
library.
If
any
of
you
have
been
part
of
it
for
a
long
time,
upgradepath
and
net
have
been
not
flawless,
but
it's
been
really
good.
It
hasn't
been
difficult.
I've
gone
from.net,
1,
all
the
way
up,
to.net
6,
and
then
we
converted
to.net
core
after
that.
That
was
probably
the
trickiest
part.
B
B
So,
oh,
I
just
saw
the
question
down
there,
but
okay,
so
this
is
some
of
the
things
we're
building
and
you
can
see
some
of
the
names
of
the
erp
systems.
If
you're
familiar
with
these
kinds,
it's
it's
not
really
relevant
what
they
are,
but
they're
the
big
players
in
in
the
space
of
erp
and
also
some
smaller
one.
B
So
the
first
thing
we
have
to
choose
is
actually
a
cloud
environment
and
now
I'll
kind
of
getting
closer
to
a
little
bit
of
talking
about
laser.
There
are
these
three
that
I
mentioned.
I
think
that
are
as
serious
for
what
we
wanted
to
do
and
one
of
the
things
we
did
earlier
on
is
we
actually
applied
for
microsoft.
I
I've
grown
up
with
microsoft,
really
like
them.
It
doesn't
matter
that
aws
is
bigger
than
microsoft.
They're
catching
up,
but
still
aws
is
probably
the
biggest
and
aws
has
some
really
really
nice
services.
B
We
did
not
want
to
be
cross
platform,
so
we
don't
have
to
be
able
to
deploy
on
any
of
these.
We
could
probably
sell
it,
but
it's
not
really
something
we
want.
We
would
rather
pick
one
of
these
and
then
really
utilize
their
their
services
because
benefit
you
can
see
on
the
right
just
some
of
the
services
we
use.
These
are
just
a
part
of
them
and
we
do
already
use
all
of
these
azure
services,
which
has
cut
our
development
down
tremendously.
B
B
He
then
developed,
delphi,
borland
and
he's
the
father
of
c
sharp.
He
was
a
big
part
of
switching
microsoft
from
common
ole,
which
was
a
pretty
bad
technology
way
back
and
switching
over
to
net.
So
this
whole
community.
Here,
you
kind
of
think
him
as
one
of
the
people.
That
said,
we
can't
fix
oily
the
income
anymore.
B
B
It
would
have
been
another
layer
on
top
of
that
and
fixing
so
he's
also
the
guy
now
behind
typescript,
a
lot
of
typescript
he's
part
of
typescript,
not
the
only
guy,
obviously
behind
it
and
typescript
is
really
fixing
all
the
problems
with
javascript
large-scale
javascript.
It's
not
the
only
thing,
but
it
makes
a
javascript
type
safe
and
it
gives
a
lot
of
better
tooling
for
javascript
as
well.
B
That
I
find
is
an.
It
is
an
unfortunate
thing
to
do.
I
understand
why
they
have
to
because
javascript
is
so
much
everywhere,
but
what
I
would
find
is
a
much
better
if
you
can
get
rid
of
typescript
and
javascript
altogether.
That
would
be
a
much
better
solution
and
that's
that's
one
of
the
things
blazer
actually
presents
so
talking
about
silverlight.
It's
actually
a
very
good
question.
I
got
burned
by
silverlight.
I
didn't
use
visual
basic
very
much
and
I
stayed
away
from
all
e
and
calm
as
much
as
possible,
but
silverlight.
B
We
did
actually
choose
earlier
on
as
a
company
and
got
burned
with
a
fairly
large
project.
We
had
that
died
and
looking
back
on
that,
it's
very
different
silver
light
is
very,
very
different
than
what
blazer
is
silverlights
was
proprietary
technology
that
used
activex
to
run
it
all
and
activex
wasn't
supported
on
all
browsers.
B
B
All
right,
I
think
I
can
pick
it
up
from
there,
so
so
I
think
it's
okay
to
move
on
no
john
thanks.
So
so
now
it's
kind
of
coming
down
to
the
the
thing
we're
kind
of
talking
about.
So
why
blazer
and
all
this
stuff
right,
we
could
have
chosen
and
some
of
the
alternatives
that
I've
shown
that
we
did
explore.
I
mean
we
could
have
chosen
java
python
or
c-sharp
as
a
back-end
right
java
would
have
made
it
easier
for
algorithms,
tooling.
I
don't
find
nearly
as
good
as
c-sharp.
B
B
I
believe
asp.net
mvc
will
be
supported
as
for
a
long
time,
because
there's
so
much
develop
in
it,
but
I
think
it's
like
once
people
start
using
blazer,
I
think
more
and
more
would
want
to
switch
over
there.
I
can't
see
why
you
would
stay
to
stay
with
mvc,
it's
a
much
better
experience
in
blazer
when
you
actually
start
using
it,
so
we
could
have
done
that.
We
looked
at
all
of
them,
but
again
the
problem
was
that
the
back
end
and
the
front
end
are
now
different
developers.
B
B
If
you
look
at
any
of
the
things
coming
out
of
microsoft,
there's
so
much
focus
on
blazer
and
when
you
look
use
laser
server
side,
there's
no
browsers,
you
don't
support,
there's!
No.
They
can't
really
yank
out
a
technology
in
the
browser
side
to
kill
blazer
like
what
happened
to
to
silverlight
right.
They
could
have
kept
supporting
it,
but
a
lot
of
the
browsers,
probably
weren't,
going
to
keep
supporting
activex
and
they
could
have
found
other
ways.
But
it's
it's
not
nearly
as
fragile
as
as
that
silverlight
was
so.
B
The
other
thing
that
was
huge
is
actually
being
able
to
to
carry
on
libraries
that
come
from
the
the
extraction
side,
all
the
way
at
the
bottom,
all
the
way
to
the
front
end
like
sharing
of
code
and
libraries.
We
build
up
it's
a
lot
of
cost
in
developing
all
that
and
having
those
libraries
be
able
to
go
across
and
not
just
use
nuget
packages
for
all
of
it.
B
Because
again,
you
lose
a
little
bit
of
understanding
when
you
go
to
nougat
unless
it's
well
supported
and
it's
big
in
the
industry.
So
so
so
there's
several
reasons
for
blazer,
but
the
standards
and
the
fact
it
supports
all
browser.
You
have
the
server
side
and
the
client
side,
which
I
know
kedran,
will
talk
a
little
bit
more
about.
But
if
you
just
want
to
talk
about
that
a
little
bit
and
why
we
chose
also
to
go
server-side,
so
we
we
chose
to
go
server-side
blazer
for
for
two
main
reasons.
B
The
biggest
one
was
probably,
we
can
control
the
speed
of
what's
happening
if
we
go
more
to
the
client
side
and
if
we
did
any
algorithm
development
on
the
client
side,
we
would
be
relying
on
the
client's
browser
and
his
hardware,
and
we
didn't
want
to
do
that.
We
don't
have
millions
of
users
and
we
never
will.
We
have
large
companies
and
a
few
users
that
expect
things
to
run
quickly,
so
we
don't
mind
paying
for
the
server
hardware
to
run
all
this
and
only
present
the
ui
layer.
B
I
know
that
could
have
been
done
also
with
a
rest
api
and
having
a
client
side,
but
especially
as
we're
building
up
our
tools.
We
don't
have
to
build
a
full
rest.
Api
build
those
layers
until
we're
fully
baked
on
our
our
products.
So
it
is
much
easier
to
start
with
server
side
also
because
you
are
right
next
to
the
database,
so
you
don't
need
to
introduce
that
layer
of
the
client
side
server
side
talking
back
to
it,
for
each
other.
B
B
The
other
thing
we
then
have
control
over
is
the
memory
we
load.
Very.
Very
large
data
sets
millions
and
millions
of
records
that
that
kind
of
consume
up
to
like
a
gigabyte
of
memory,
because
we're
going
to
analyze
them
quick
enough,
and
it's
not
fast
enough
to
do
it
out
of
the
database.
So
having
also
that
in
the
server
side,
makes
it
easier,
especially
the
scale
prototype
and
and
run
really
quickly
on
the
server
side.
B
The
other
thing
that
that
server
side
blazer
gives
for
the
kind
of
at
my
level
when
I
think
about
this
stuff
is
it
gives
protection
of
your
code
right.
Anything
you
send
through
the
browser,
even
though
it's
compiled
is
you've
got
it.
You've
got
to
assume
somebody
can
look
at
it
and
that's
okay
for
a
lot
of
our
code.
It's
not
that
proprietary,
but
some
of
our
algorithms
are.
We
spend
a
lot
of
money
on
it,
we're
not
an
open
source
company,
so
we
want
to
protect
our
source
code
and
server
side.
B
Does
that
right?
Nothing
and
kevin
will
explain
how
that
works,
but
nothing
is
sent
of
the
code,
the
c
sharp
code
onto
the
client
side.
We
do
use
client
side
for
some
other
things.
We
do
it
for
some
compression
algorithms,
where
it's
much
faster
and
there
we
were
actually
able
to
write
a
lot
of
that
stuff
in
c
sharp
instead
of
javascript.
B
B
So
it's
very
easy
to
create
an
experience
where
this
seems
like
a
spa
app
right,
a
single
page
application
and
it
seems,
like
everything,
is
running
on
the
client
browser.
But
whenever
you
click
on
anything
here-
and
you
drag
these,
it's
actually
sending
all
of
this
stuff
to
the
server
using
the
signalr
connection
and
then
the
the
updated
dom
is
sent
back
to
you.
B
But
you
don't
really
experience
the
latency
unless
you're
doing
high
turnover
stuff
so
and-
and
so
there
is
a
lot
of
libraries
already
that
you
can
use
so
actually
let
me
show
you
this
one.
I
don't
want
to
go
too
much
about
what
our
tool
does.
I
don't
think
it's
as
important,
but
this
library,
for
instance,
is
actually
a
javascript
library
that
we
use
for
charting.
There
are
tools-
and
we
use
unfortunately,
syncfusion
as
one
of
our
tools
for
this,
but
the
way
they've
wrapped
their
tool
in
blazer.
B
Is
that
it's
not
it's
not
done
very
well.
So
the
speed
of
blazer
didn't
really
happen
because
they
just
took
their
old
tool
and
wrapped
it
and
didn't
do
a
good
job.
So
here
we
actually
wrapped
it
in
a
known,
javascript
library
on
our
own,
and
this
is
much
faster.
I
mean
you
can
drag
and
drop
these
things
as
if
you're
on
the
client,
side
and
you're
actually
going
back
and
forth
to
the
server
when
you
do
this
kind
of
stuff.
B
B
You
basically
only
show
a
version
of
your
scrolling
it.
So
this
is
it.
This
is
a
control,
we're
actually
replacing
we're
in
the
midst
of
replacing
this
to
to
do
this
a
lot
better
in
blazer.
So,
if
you're
willing
to
go
with
the
blazer,
I
I
mean
we
are
all
in
on
blazer.
We
don't
have
an
alternative,
we're
not
going
to
switch
back.
We
have
chosen
to
do
our
whole
stack
and
everything
we
do
is
in
blazer
and
I
think
our
speed
of
development
is
much
higher
if
we
used
any
other
technology.
B
That's
one
of
the
benefits
we've
had,
but
you
are
you.
You
have
to
just
be
aware
of
some
of
the
tooling
earlier
on
in
your
life
yeah,
so
in
the
development
life.
So
I
don't
know
if
I
have
that
many
more.
I
don't
see
if
there's
any
questions,
so
I
think
that
kind
of
wraps
up
what
I
have
to
talk
about.
Hopefully
that
gives
another
high-end
experience.
C
B
A
A
I
guess
he
said
he
means.
Is
there
any
side
effect
performance
issue,
but
using
cascading
parameter
and
cascading
value
in
big
enterprise
application,
I'm
not
sure
what
he
meant
by
this,
but
but
but
but
but
he
asked
this
around
yeah
around
the
time
you
were
explaining
about
the
old
enterprise
systems
that
you
were
you
you
were
building
before
you
went
to
the
blazer.
B
B
B
B
A
B
We
are
very
happy
with
it.
We
found
that
anyway,
we
had
problems
with
the
performance
was
actually
the
tool
manufacturer
for
blazer
or
us
making
mistakes
not
blazer
itself.
We
haven't
found
any
direct
problems
in
blazer
that
we
didn't
cause
right.
We
misunderstood
something
and
did
something
wrong,
but
our
all
our
tools
run
really
fast.
So
no,
no
performance
problems
that
we've
kind
of
not
been
able
to
solve.
A
All
right,
that's
it
that's
good
to
know
and
then
yeah
I
was.
I
myself
am
curious
about
about
one
something
that
you
said
earlier
about
the
the
part
where
you
you
said
something
about
new,
get
preferring
blazer
over
new
get
packages
and
try
to
figure
out
what
the
scenarios
are
or
what
the
use
cases
are.
I
mean
where
would
where
would
a
new
kid?
A
new
get
package,
be
preferable
or
or
something
I
guess.
I
guess
it's
it's
it's
part
of.
It
sounds
like
it's.
A
Oh
all,
right
all
right
all
right
what
yeah
yeah,
what
I
was
asking
about
is
of
new
get
packages
versus
you
know:
blazer
apps!
Well,
what's
the
what's
the
story
on
on
on
that
or
is
there
you
know,
did
you
have
any
experiences
in
preferring
new
blazer
over
you
know
creating
a
new
get
package
or
or
for
for
some
kind,
some
sort
of
capability
or
some
sort
of
functions.
A
B
B
So
if
you
use
there
are
nugets
that
that
are
not
supported
if
they're
old.net46
or
something
right
yeah,
but
most
of
the
newer
nougat
packages
would
work
so
on
the
server
side.
It's
not
a
problem
at
all.
Anything
will
pretty
much
work
because
you're
not
downloaded
to
the
browser
things
that
download
to
the
browser
you
have
to
use
core.
If
you
use
core
there's
still
a
few
calls
that
are
not
supported
on
the
browser
side,
but
on
the
server
side
we
found
very
little
nougat.
B
A
B
Yep
so
yeah
browser
is
always
fun.
We've
had
some
issues
with
some
of
them,
but
again
it's
nothing.
We
haven't
been
able
to
solve
it
so
far,
so
it's
not
like
they're,
not
supported.
We've
had
some
issues
with
layout
right
where
they
lay
out
slightly
different,
but
that
is
more
in
the
html
and
css
issue
than
an
actual
blazer
issue.
B
So
because
I
mean
that's
really
what
ends
up
being
generated
by
blazer
right,
it's
just
html
on
the
client
side,
so
it
hasn't
been
because
of
blazer.
It's
been
because
of
just
html
and
css.
We've
had
problems
with,
but
it
fully
works
on
all
the
all.
The
major
browsers
I
mean
we
support,
safari
chrome
edge,
so
are
the
main
ones
that
we
support
and
and
so
far
they
they've
worked.
That
problem,
not
without
problem
without
solvable
problems.
A
All
right,
yeah
have
to
be
have
to
be
really
clear
about
that.
Yeah
yeah-
I
wouldn't
oh
all
right.
So
so
I
think
that's
that's
all
the
time
we
we
have
for
for
the
first
half
of
this
of
this
session.
So
thank
you
so
much
soren
and
and
yeah,
hopefully
we'll
get
another
chance
to
do
to
talk
with
a
better
internet
connection
on
both
sides.
I
think
I
also
cut
off
a
little
bit
at
some
point.
A
C
Okay,
so
hi
everyone
good
evening,
so
I'm
katrin
villana,
so
I'm
one
of
the
developers
here
at
minzy
and
earlier
you
heard
from
sauron
like
from
a
high
level
perspective
right
from
a
ceo
perspective,
why
we
chose
blazor
and
honestly
with
blaze
or
it
helped
us
deliver
the
product
and
where
in
basically
in
a
very
short
amount
of
time,
and
we
were
able
to
focus
on
delivering
the
product
rather
than
studying
the
technology.
I
think
that's
one
of
the
biggest
things
that
sauron
mentioned
earlier
right
and
with
what
we
have
right
now.
C
All
of
the
all
of
our
developers
can
actually
work
in
the
front
end
in
the
back
end
like
we
want
to
remove
the
division
between
the
two
right,
meaning
if
we
need
help
on
database
or
on
ui.
Basically,
everyone
can
jump
in
right,
there's
no
point
person
to
like.
We
don't
have
to
wait
for
anyone.
Basically,
we
can
support
the
whole
stack
because
of
this
one.
So,
for
my
talk,
what
I'm
going
to
be
focusing
on
is
some
of
the
things
that
we
have
learned
in
terms
of
using
blazor
server
in
production.
C
So
hopefully,
if
you
guys
are
planning
to
use
data
server
or
is
already
using
this
reserver,
some
of
our
experiences
here
might
help
you.
So,
let's
start
with
okay:
let's
start
laser
server.
Okay,
so,
as
you
all
know,
there
are
two
versions
of
blazor
blazer
server
and
blazor
wassum
right.
I
think
that's
the
that's
how
they
named
it
now.
So,
let's
start
first
with
the
blazer,
the
quick
comparison,
so
a
laser
server.
Basically,
it's
all
the
state
management,
all
the
event
handling
are
being
done
on
the
server
side,
it's
being
communicated
from
the
browser.
C
Basically,
if
you
pick
a
button,
it's
going
to
be
the
event
it's
going
to
be
sent
over
to
the
server
for
the
computation
to
happen,
and
it
can
update
the
element,
basically
once
it's
done,
rendering
it
can
give
it
back
to
the
server.
I
mean
to
the
browser
to
update
the
dom
elements
right
and
client
side.
It's
your
typical
spa
application
like
your
angular
or
react
or
but
the
difference
is
that
it's
only
using
the
c-sharp,
the
dot-net
runtime
that
is
built
on
webassembly,
meaning
you
can.
You
can
still
use
c-sharp
right.
C
Of
course,
there
are
some
downsides
to
it
and
there
are
some
upsides
to
it.
I'm
not
going
to
be
focusing
on
them.
There
are
a
lot
of
articles
and
there
are
a
lot
of
videos
and
documentation
that
can
help
you
on
that
one.
What
I
want
to
focus
on
today
is
our
experiences,
and
hopefully
you
will
learn
something
from
it
as
well.
If
you
are
planning
on
using
data
server,
so
I
want
to
what
I
want
to
focus
on
now
is
bleeder
server.
C
C
C
The
reason
for
that
one
is
I'm
going
to
be
focusing
on
them
later
on,
so
to
give
a
quick
overview
overview
of
what's
happening
on
the
left
side,
you
can
actually
see
the
browser
and
then
on
the
right
side.
This
is
actually
the
server.
This
is
where
blazer
is
running.
So
what
happens?
Is
that
each
connection?
C
So
let's
try
to
put
it
in
another
perspective,
if
you're
using-
let's
say
another
version,
let's
say
angular
or
react.
Basically,
what
happens
is
if
you
click
something
you
and
you're
gonna
get
you're
gonna
go
fetch
data
from
an
api,
so
you're
gonna
do
an
http
call
right,
but
there's
no
signalr
for
you,
it's
just
a
plain
old
http
call
to
un
restful
endpoint
with
signal
r.
We
don't
have
to
worry
about
that
one,
because
all
those
things
are
being
handled
by
signal
r.
C
C
What
you
usually
do
is
do
an
http
call
like
you,
go
use
a
post
or
a
get
http
call
to
an
endpoint
right
and
you
get
the
data
once
you
get
the
data,
it
might
be
served
in
a
different
format
like
it
can
be
an
xml
format
or
it
can
be
a
json
format
or
whatever
it
is
that
the
endpoint
is
giving
back
to
you
right
and
you
have
to
understand.
Okay,
how
do
we
parse
that
data?
C
What's
the
amount
of
data
that
we
can
actually
store
on
the
browser
right,
for
example,
do
you
think
that
a
one
gigabyte,
or
let's
say
a
let's,
just
go
to
a
more
realistic
example?
Do
you
think
that
a
data
table
with
500
000
rows
can
actually
you
can
ask?
Can
you
actually
give
it
back
into
just
one
http
get
call,
I
don't
think
that's
possible
because
the
browser
might
run
out
of
memory
or
it's
going
to
be
very
taxing
on
the
client
side
or
in
the
browser
side
to
render
them.
C
Even
if
you
use
virtualization,
there
are
limits
that
you
need
to
understand
and
you
have
to
think
of
them
if
you're
trying
to
start
from
scratch
right,
but
with
signalr
and
with
data
server,
we
don't
actually
have
to
think
about
those
things
or
just
focus
on
returning.
What
you
want
to
return
and
signal
r,
basically
and
later
server
will
do
that
one
for
you
also
another
good
thing
with
signal
r.
Is
it
basically
switches
between
three
different
techniques?
I'm
not
sure.
C
If
you
guys
are
familiar
with,
I
think
website
is
the
most
common
one
right,
websocket
is
usually
being
used
nowadays
with
the
with
the
wss
protocol.
There's
all
there
are
also
other
techniques,
the
server
sent
events
and
the
long
polling.
I'm
not
going
to
discuss
them
in
detail
so
feel
free
to
research
them,
but
the
good
thing
with
signalr
is
it
will
automatically
switch
between
the
three,
for
example.
C
For
some
weird
reason,
your
web
sockets
are
blocked,
signalr
can
use
long
polling
or
servers,
and
events
signalr
will
automatically
determine
the
best
connectivity
depending
on
the
current
setup
of
the
client.
So
that's
how
good
signalr
is-
and
let's
say,
you're
concerned
about
scalability
azure
even
has
a
signalr
service
that
you
can
actually
get,
and
it's
very
easy
to
combine
it
with
asp.net
applications
or
even
c-sharp
applications
in
general.
C
So
but
enough
about
signal
r.
Now,
let's
focus
on
the
things
that
we
have
learned
with
blazer
server
when
we
are
using
it
in
production
number
one.
So
what
I
want
to
focus
on
is
I
want
to
go
back
to
the
previous
sentence,
the
one
that
is
on
the
definition
of
microsoft
on
laser
server.
Let's
talk
first
on
this
on
the
text
here
on
the
server
okay,
when
we
say
on
the
server,
I
think
it
was
also
mentioned
by
sauron
earlier
in
mind,
z.
C
C
The
instance
that's
where
and
we
really
have
to
bake
it
in
in
the
ui
logic,
because
it's
part
of
it
like
filtering
or
doing
some
kind
of
data
manipulation
on
the
real
on
the
fly
on
the
real
time
and
take
note
the
data
that
we're
handling-
it's
not
just
mere
500
500
rows,
whatever,
where
we're
dealing
with.
As
what
sorry
mentioned
earlier,
hundreds
of
thousands
to
millions
of
records,
okay
handling
those
amounts
of
data
and
imagine
if
we
don't
use
blaze
or
server
or
we
don't
use
what
we're
using
right.
C
Now
we
have
to
learn
on
how
to
do
paging.
Whenever
we
do
some
kind
of
execution
we
need
to
send
over
to
the
server
by
http
call
wait
for
some
latency,
not
from
some
latency
to
happen,
etc.
Those
kinds
of
things,
but
with
laser
server.
What
we're
maximizing
is
the
execution
speed
of
those
things.
Why?
C
Okay,
if
you're,
if
you're
a
developer,
if
you're
a
web
developer
chances
are
or
90.
I
think
you
should
know
this
one
right
that
a
browser
will
only
give
you
a
single
trend
that
a
single
trend
right.
So
your
reactor
angular
they're,
just
using
one
single
trend
but
they're
using
promises.
That's
why
it
looks
like
it's
doing
multiple
things
at
the
same
time,
but
it's
still
a
single
trend.
C
At
the
end
of
the
day,
it's
still
a
single
trade
executing
one
line
of
code,
no
matter
how
many
contexts
which
you
do
it's
still
just
one
single
trend
right.
However,
if
you
go
with
server
side,
for
example,
laser
server,
this
is
something
unique:
it
can
actually
maximize
the
the
number
of
threads
inside
the
server.
So
a
good
example
for
this
one
would
be,
I
think,
from
soren's
screenshot
earlier
like
if
you
watch
soren's
presentation,
our
application
actually
has
several
components
to
it.
C
It
has
a
left
bar
side,
it
has
a
left
sidebar
and
then
it
has
a
lot
of
components
that
are
chained
with
each
other
when
we
load
that
page,
for
example,
we
have
five
blocks
inside
a
component,
those
five
blocks.
We
can
actually
render
them
using
five
different
threads
on
the
server
which
is
through
multi-threading,
not
just
one
thread
during
context.
Switching
there's
a
big
difference
between
that
one
right:
five
threads
actually
executing
five
lines
of
code.
C
At
the
same
time,
it's
much
much
better
compared
to
one
thread,
that's
doing
and
that's
doing
a
contact
switching.
So
that's
one
of
the
advantages
that
we
have
when
we're
using
data
server.
Imagine
if
five
of
them
have
its
own
data
set,
and
even
if
they're
sharing
the
data
set,
they
need
to
do
some
kind
of
computational
value
into
it.
It's
gonna
take
a
lot
of
time.
Remember
we're
handling
thousands
and
hundreds
of
hundreds
of
toughness
to
millions
of
records
here.
C
C
Okay,
if
you
are
using
a
multi-thread
ui,
if
you
are
using
multi-trend,
especially
multi-trading,
especially
on
the
ui
and
I'm
just
going
to
go
back
to
a
bit
of
c-sharp
basic,
I'm
not
sure
how
many
you
guys
have
used,
wpf
or
winforms,
or
those
typical
c-sharp,
ui
development,
there's
a
concept
of
a
ui
trend
even
on
the
server,
even
on
the
browser
side.
There's
a
concept
of
the
ui
trend
right.
C
So
one
of
the
big
learnings
that
we
found
here
is
that,
if
you're
going
to
do,
if
you're
going
to
do
multi-chart
rendering
for
blazer
server,
you
have
to
make
sure
that
you
get
the
ui
trend.
Okay
and
that
you
don't
block
the
ui
trend.
Okay
blocking
the
ui
thread
may
make
yours.
May
it
can
actually
make
your
blazer
server
application,
slow
and
not
responsive
at
all.
So
you
have
to
be
very
careful
with
it,
but
there
are
techniques
to
do
it.
C
You
just
need
to
get
back
the
ui
trend,
so
that's
one
of
the
things
that
we've
learned
from
this
one,
okay,
so
moving
on
the
next
thing
that
I
want
to
talk
about
is,
I
think
it
was
mentioned
earlier.
Signalr
connectivity
on
laser
server
clients
needs
to
yes,
I
know
for
some
of
you.
This
might
be
a
throw
off,
but
there's
actually
several
advantages
to
it.
Being
always
connected
means
that
you
can
track
which
users
are
online.
You
can
easily
give
them
notifications
on
the
fly
like
a
real-time
notification
system.
C
Okay-
and
you
can
also
do
a
lot
of
other
things
with
regards
to
getting
the
connection
alive,
because
you
can
easily
know
that,
for
example,
if
the
client
gets
disconnected
right,
all
of
the
all
of
the
updates
that
he
or
she
was
doing
basically
it
can
actually
be
saved,
or
the
good
thing
with
that
is
before
she
can
proceed
before
he
or
she
can
proceed
with
doing
anything.
If
the
connection
is
blocked,
then
it
can.
C
It's
also
an
immediate
feedback
to
the
user
that
okay,
we
cannot
do
anything
because
you
don't
have
internet
connection.
That's
also
a
good
experience
to
a
certain
degree
like
it
depends
on
how
you
want
to
go
over
it,
but
for
hours
it's
actually
a
helpful
technique
for
us
in
order
to
handle
those
scenarios.
C
Of
course,
there's
some
things
that
you
have
to
be
very
careful
with.
So
a
downside
of
being
always
connected
is
always
being
connected
as
well,
because
you
have
to
take
care
of
something
what
that's
called
the
latency
right.
So
in
laser
server,
there
is
a
microsoft
for
microsoft.
There's
a
recommended
latency
of
at
least
200,
ms,
for
a
very,
very
good
user
experience.
C
So
it's
just
a
matter
of
learning
the
blazer
life
cycle
and
you
need
to
maximize
offloading
if
you're
familiar
with
the
blaze
or
life
cycle,
just
make
sure
that
your
own
initializes,
a
thin
layer
and
put
the
heavy
lifting
on
after
render
async
make
sure
you
to
wrap
it
in
a
background
thread
and
get
the
thread
afterwards.
I'll
explain
this
more
in
detail
later,
but
even
for
latency
issues.
C
Okay.
Now
what
I
want
to
focus
on
next
is:
I
want
to
focus
on
ui
updates
and
event
handling.
So,
let's
start
with
this
statement.
Okay,
ui
updates
are
always
take
note,
always
given
to
the
server
okay.
Now,
some
of
you
might
think
that
this
is
a
negative
thing.
What
does
it
mean
by
always
giving
to
the
server?
Let's
say
you
do
a
mouse
click
right
almost
rather
like
a
button
click.
C
If
you
click
a
button
and
you're,
let's
say
you're
in
a
typical
react
or
angular
application
when
you
click
the
button-
and
you
have
some
logic
inside
of
it-
that
logic
is
being
handled
by
the
browser
right,
it's
being
handled
by
the
browser,
it's
all
it's
at
the
client
side
right
and
then,
if
it's
going
to
do
some
api
calls,
then
that's
the
time
that's
going
to
pass
it
to
the
server
via
the
api
call
and
blazer
server.
It's
different.
C
When
you
click
a
button,
it's
going
to
pass
that
event
to
the
server
meaning
the
browser
doesn't
do
anything.
It
just
passes
that
event
to
the
server.
Why
take
note
invasive
the
state
management?
Even
the
dome
state
management,
it's
not
handled
by
the
client,
it's
not
on
the
browser
side.
All
of
them
are
on
the
server
side,
so
a
click
on
the
button
needs
to
be
passed
to
the
server,
because
the
server
needs
to
understand
what's
happening.
C
It
needs
to
know
those
things.
Okay,
so
there's
some
advantages
and
disadvantages
to
it
right
and
for
me,
the
best
advantage
to
this
well,
of
course,
the
disadvantage
is
the
latency
issue
right,
because
you
have
to
pass
it
to
the
server
and
the
server
will
have
to
handle
it,
but
there's
another
good
thing
to
that:
one:
the
server
can
actually
just
spawn
another
thread
when
you
do
a
click
button,
wrap
it
in
a
task.
It's
an
editor
that
will
be
handling
it
right,
meaning
it's
still
the
server
that
does
the
heavy
lifting.
C
Once
it's
done,
it's
just
going
to
get
the
ui
thread
back
and
you
can
just
display
the
updated
value.
So
that's
one
of
the
advantages
to
it
right,
but
of
course,
there
are
downsides
to
it.
For
example,
you
need
to
understand
that
all
events
are
being
forwarded
to
the
server.
I
keep
repeating
myself,
because
this
is
very,
very
important
okay,
so
you
have
to
be
very,
very
careful
of
some
events.
An
example
would
be
on
mouse
move,
okay,
why?
C
C
So
you
have
to
be
very
careful
with
those
kinds
of
things,
because
everything
is
being
passed
to
the
server
right,
so
this
can
be
a
disadvantage
or
it
can
be
an
advantage,
so
you
have
to
know
when
to
use
them
and
what
events
to
use
for
your
use
cases.
For
example,
if
you
have
an
on
input
listener,
so
you
can
just
offload
it
to
javascript
and
then
just
do
the
validation
afterwards
or
pass
it
to
the
server.
C
It
depends
on
your
use
cases
all
right
so,
but
this
is
something
that
you
have
to
be
very
aware
of.
Next
is
what
I
want
to
talk
about.
Is
I
just
coined
this
term?
I'm
not
sure
if
there's
a
right
term
for
this,
it's
the
simultaneous
component
loading,
as
I
mentioned
earlier,
one
of
the
main
advantages
of
blazor
is
of
laser
server.
Rather,
is
you
have
the
power
of
multi-trading
at
your
disposal,
meaning
if
you
have
five
components
or
more
that
you
want
to
render
you
can
take
advantage
of
multi-trading
take
note.
C
I
highlighted
one
side
trending
and
task
because
they're
very
important
concepts.
So
let's
say
you
have
you're
gonna
render
15
components.
All
of
them
need
to
do
some
data
manipulation
or
some
data
fetches
of
the
database,
your
you
can
just
you
can
just
maximize
the
server's
multi-trading
capability
right
so
and
then
it's
kind
of
easy
to
scale
those
applications
right.
C
You
can
even
wrap
this
in
a
container
and
then
it's
just
gonna
scale
that
easily
so
the
main
advantage
for
this
one
is:
if
you
know
how
to
maximize
multi
trading
on
your
server
and
on
your
c
sharp
code,
then
you
can
also
apply
it
on
blazor
on
the
laser
server
components.
That's
how
good
it
is.
So
the
key
technique
here
is
to
learn
the
blazor
life
cycle.
Take
note.
That
is
very,
very,
very
important.
One
thing
that
I
want
to
share
I'll
share
I'll
show
you
a
technique
with
this
one.
C
What
we
usually
learn
from
our
experience
is
that
you
have
to
make
sure
that
your
uninitialized
logic,
even
if
it's
on
initialized
or
uninitialized
async
in
the
live
cycle,
make
the
code
as
thin
as
possible,
meaning
you
don't
do
database
calls
there
or
you
don't
do.
Let's
say
long
running
processes,
heavy
a
heavy,
intensive
database
call
or
manipulation
right.
The
reason
for
that
one
is:
you
have
to
go
back
to
your
ui
basics.
There's
always
a
dispatcher
trend.
C
C
It's
actually,
a
very
nice
experience
compared
to
having
just
one
single
thread
on
the
client
side
and
you're
kind
of
limited,
with
the
resources
of
the
client
right
so
and
the
good
thing
with
this
one
is
even
if
we're
processing
lots
and
lots
of
rows
of
data
like
thousands
to
millions
of
rows
of
data,
we
can
still
do
it
fast
right
because
we
have
the
power
of
the
we
have
the
power
of
multi
trading
behind
the
scenes.
So
that's
one
of
the
big
advantages
and
guys
in
the
laser
website.
C
There's
a
life
cycle,
but
another
website
that
I'm
looking
at
is
the
laser
university.
They
have
a
good
diagram
of
the
blazer
life
cycle,
having
a
good
understanding
of
the
life
cycle.
I
think
it
also
goes
the
same
for
angular
and
the
other
spa
application.
Spa
framework
applications
is
that
you
need
to
understand
the
life
cycle
and
in
blazer.
If
you
know
how
to
maximize
the
life
cycle,
then
you
can
also
maximize
multi-threading,
so
it
goes
hand
in
hand
with
those
two
okay.
C
So
the
last
thing
that
I
want
to
talk
about-
and
I
think
this
is
very
important-
I
think
sauron
also
made
a
demo
on
this
one
earlier,
javascript,
so
c,
blazor
server,
either
blazer
server
or
blazer
wasm.
They
both
can
communicate
with
javascript
right.
So
blazor
blazer
code
in
general,
has
the
interoperability,
meaning
javascript
can
call
c
sharp
code
c
sharp
code
can
call
javascript
right.
It's
vice
versa.
You
can
even
add
nougat
packages
like
nougat
libraries
inside
blaze
or
inside
your
blazer
application.
So
just
a
short
segue.
I
actually
wrote
a
blog.
C
I
was
actually
curious
about
it.
A
few
years
ago
I
added
a
node
node
library,
an
npm
library
in
my
blazer
application,
and
I'm
calling
that
node
library
it
works
perfectly.
It
works
really
really
great.
I'm
not
sure
if
you
guys
have
seen
that
blog
before,
but
it
was.
It
was
a
really
good
experience
like
meaning
with
blazer.
C
You
have
the
power
of
the
whole
node
library
at
your
disposal,
the
whole
npm
library
or
if
they
work
right,
but
most
most
of
them,
you
can
actually
use
it,
but
the
good
thing
or
the
thing
that
you
need
to
be
aware
of
is
there's
also
a
downside
to
it
it
actually
we
actually
experience
it
when
we
use
a
third
party,
javascript
library
for
charting.
I
think
it
was
presented
by
sauron
earlier.
C
So
initially
we
use
another
a
third-party
provider
for
blazor
that
has
charting
libraries,
but
the
problem
is
there
were
a
lot
of
limitations
on
their
system
and
there's
it's
kind
of
it.
It's
gotten
to
the
point
that
we
wrote
our
own
wrapper
to
some
javascript
libraries,
which
made
it
much
much
much
faster.
That's
the
experience
on
it.
Oh
thanks
john.
So
the
link
showed
up
so
okay,
so
with
javascript.
What's
happening
is
that
if
you're,
integrating
with
javascript,
if
it's
just
a
simple
call
like
a
node
library
call,
then
it's
gonna
work.
C
Fine
as
expected,
but
from
our
experience,
sometimes
our
javascript
needs
to
generate
dynamic
components
or,
for
example,
the
drag
and
drop
events
are
on
the
javascript
side.
We
need
to
communicate
it
to
the
server
code
or
to
the
c
sharp
code,
or
sometimes
our
c
sharp
code
needs
to
reference,
an
element
that
was
dynamically
generated
on
the
client
side.
Of
course,
this
it's
going
to
take
some
time
because
of
signal
r.
C
It's
gonna
be
instant
right,
but
if
you're
doing
a
lot
of
things
or,
for
example,
it's
gonna
happen
in
an
instant,
but
sometimes
the
client
or
the
because
the
you
are
ui
is
quite
fast.
Sometimes
the
client
can
just,
for
example,
we're
still
loading
some
things
on
the
back
end
and
the
client
moves
to
another
page.
If
you
are
not
careful
with
using
referencing
on
c-sharp
and
java
by
and
vice
versa,
you
might
end
up
with
uncaught
exceptions
right,
so
you
have
to
be
very,
very
careful
with
those
things.
So
to
give
you
an
example.
C
So
here
are
some
cases,
for
example,
an
element
where
javascript
is
looking
where,
where
js
is
looking
for,
is
already
disposed.
For
example,
the
user
switched
pages,
or
basically
it
switched
to
another
page
right,
so
the
javascript
might
still
look
for
that
element,
but
it
was
already
it
gotten
this
post
by
laser.
So
you
have
to
be
to
take
note
of
those
scenarios
right
else
your
application
might
crash.
C
Also,
another
example
would
be
you
have
a
javascript
callback
right,
but
the
element
got
disposed
ready.
So
you
have
to
be
very
careful
on
those
things,
but
nonetheless
the
experience
with
integrating
with
javascript.
It
has
been
really
really
great
for
us.
I'm
not
sure
if
you've
seen
the
presentation
earlier
by
sauron,
wherein
he
was
showing
this
variance
like
there's
some
graph
there.
It
was
actually
written
on
blazor
and
javascript
and
it
works
really
flawlessly
like.
If
you
do
the
drag
and
drop.
C
You
won't
believe
that
a
server
call
is
happening
on
the
back
end
and
that's
how
good
it
is,
and
aside
from
those
things,
we
use
third-party
like
third-party
java
script,
libraries
that
are
basically
written
in
javascript,
we
wrote
a
blazer
wrapper
around
it.
It
works
perfectly
good
for
us,
it's
like
having
your
own
blazer
component,
but
in
reality
it's
just
using
javascript.
C
So
you
have
to
be
very
careful
like
you
can
just
write,
try
catch
around
it
just
to
catch
those
errors,
because
those
errors
are
something
that
are
not
really
easy
to
catch
like
if
in
production
like
in
local
development,
it's
not.
Sometimes
it's
really
hard
to
recreate
them.
It
sometimes
it
only
happens
in
production.
So
those
kinds
of
things
you
have
to
be
very,
very
careful
with
it,
but
do
using
javascript
is
either
it's
the
best
experience
like
combining
them.
It's
actually
a
good
experience.
C
I
know
sauron
is
not
a
fan
of
javascript,
but
combining
them.
It's
actually
giving
us
a
better
experience,
and
personally,
I
think
what
we're
doing
combining
both
of
them.
It's
actually
the
best
approach
for
now,
especially
for
blazor,
okay.
So
another
thing
that
a
general
rule.
Well,
this
is
something
that
we
applied
on
our
end,
a
general
rule.
Is
we
try
to
anticipate
all
possible
scenarios?
C
It's
not
possible
to
anticipate
all
right.
That's
that's
really
impossible
right,
but
at
least
try
to
wrap
it
with
try
catch
to
see
so
that
you
can
see
what's
happening
right.
We
right
now
we're
still
working
on
it.
We
have
some
problems
with
unquote
exceptions,
we're
doing
we're
learning
from
it.
So
I
hope
that
you
guys
can
also
learn
from
this
one
as
well
right,
because
any
uncaught
exception
that
involves
the
ui
thread.
It's
gonna
bubble
up
to
the
browser
side
and
it's
gonna
crash
the
application.
C
Okay,
so
I
just
wanna
quickly
wrap
up
my
presentation
and
then
I'm
gonna,
be
I'm
gonna.
Try
to
start
answering
some
of
the
questions.
So
some
of
the
key
points
that
I
discussed
was
number
one.
Multi
threading
is
your
best
friend
you
keep
hearing
this
from
me
over
and
over
again
during
this
presentation.
It's
because
really
this
is
the
power
of
blader
server
right.
I
know
that
a
lot
of
people
are
afraid
with
multi-threading.
C
They
just
rather
stick
with
one
single
thread
and
then
do
promises
and
call
backs,
but
there's
a
there's,
a
really
limitation
to
it.
There's
a
limitation
to
it
like.
If
you
have
the
power
of
multi-trading,
why
not
take
advantage
of
it
right,
especially
you
have
the
tpl
library
for
c-sharp.
You
don't
even
have
to
create
new
threads
right.
You
just
have
to
do
task.run
and
let
the
tasks
get
and
let
the
trend
pool
decide
which
one
should
it
give
it
to
you.
Even
the
even
the
tpl
has
helpers
for
you
on
that
one.
C
You
can
just
use
that
start
new
with
the
long
running
as
the
option.
Then
it's
just
gonna
spawn
a
new
thread
right,
so
even
trend
management
in
c
sharp.
It's
not
that
hard
anymore
right.
It's
it's
quite
easy
for
you
as
well.
You
just
need
to
know
the
basics
of
treading,
so
that's
actually
a
good
thing
with
the
user
server.
I
think
this
is
something
that
I
don't
correct
me.
C
C
Next
is
be
careful
on
events.
Okay,
like
what
I
said
earlier
on
mouse
down
or
a
mouse
move,
can
actually
hit
your
latencies.
It
can
actually
send
a
lot
of
data
to
the
server,
so
you
have
to
be
very
careful
on
those
things,
but
do
not
be
afraid
of
it
like
if
there's
a
really
use
case,
for
it
go
ahead
and
use
it.
C
Try
to
anticipate
all
possible
scenarios
with
javascript,
it's
not
always
possible
to
anticipate
them,
but
at
least
understanding
what
can
happen
or
what
might
happen.
It's
a
very
good
tool
for
you,
okay,
so
I
also
just
want
to
share
some
helpful
tips,
a
vase
from
our
experience
and
hope
that
it
can
also
help
you
in
your
journey
with
the
user.
Server
have
a
good
understanding
of
trends
versus
task.
Even
if
you're,
not
a
laser
developer,
you
need
to
understand
threads
versus
task.
There's
a
big
difference.
C
Okay,
all
right
tasks
can
actually
the
context
of
a
task
can
actually
be
executed
by
multiple
threads
right.
A
trend
can
actually
switch
between
multiple
contexts
of
between
multiple
contexts
or
between
multiple
tasks.
So
you
need
to
know
that
sometimes
using
your
lock,
it's
kind
of
dangerous
if
you're
combining
thread
and
task
so,
but
you
need
to
have
a
good
understanding
of
the
thread
versus
task
and
you
can
take
advantage
of
blizzard
server.
C
The
recommend
for
personally
what
I
do
recommend
is
for
on
initialize:
try
to
make
sure
that
you
don't
use
on
initialize
async,
if
possible,
just
use
uninitialized,
because
uninitialized
will
guarantee
that
you're
not
doing
any
async
call
meaning
because
an
async
call
might
it
might
be
an
indicator
that
you're
doing
a
long
running
task
somewhere
like
doing
a
database,
a
data,
a
database
fetch
or
getting
it
from
an
external
api.
Okay,
just
put
it
on
the
on
after
render
async,
that's
the
best
helpful
tip
on
that.
C
One
next
is,
of
course,
if
you're,
if
you're
maximizing
multi-trading,
you
need
to
know
the
difference
between
luck
and
sigma
for
slim
right
in
lock.
Take
note.
It's
a
tread
level
note
that
it's
not
a
task
context
right,
there's
a
big
difference
to
it,
while
assam
affords
them.
It's
basically
on
a
task
context,
not
on
a
tread
level,
so
just
take
note
that
it's
gonna,
it's
if
you
don't
know
the
difference
between
the
two.
Please
start
eating
them.
Now,
it's
gonna
help
you
on
your
c-sharp
journey,
not
just
your
blazer
server
journey.
C
Okay,
also,
another
thing
that
I
forgot
to
add
in
the
slides
is
we
had
something
that
we
figured
out
recently.
It
actually
added
a
lot
of
bottleneck
on
our
servers
is
that
we
did
something
in
wrong
we're
in
we're
actually
giving
back
the
date,
the
images
as
a
basics
before
and
we
did
not
scale
it
properly,
and
even
if
it
looks
like
it's
only
a
simple
process
for
an
on
initialize
method,
right
even
on
on
initialize.
C
What
we
found
out
is
that
the
browser
can
have
a
hard
time,
rendering
it
so
for
those
kinds
of
things
better
to
put
it
on
the
on
after
render
async
and
then
on
initial.
Let's
just
put
unloading
indicator
and
then
delay
the
loading
of
those
things
right,
because
sometimes
you
really
want
to
use
those
basic
type
or
images
because
of
let's
say
for
security
issues,
those
kinds
of
things.
C
Shouldn't
hurt
you,
but
we
actually
improve
the
speed
of
our
servers
or
of
our
applications
by
more
than
I
think,
90
or
80
80
to
90,
because
of
that,
and
we
were
able
to
fix
it
using
proper
scaling
algorithms,
so
yeah
just
to
finalize
my
thoughts
on
this
one,
so
is
blazer
server
worth
it.
I
think
this
is
the
biggest
question,
and
I
know
that
I
I
actually
just
saw
a
comment
from
my
friend
that,
for
him
is
not
gonna
go.
I
think
it's
not.
C
I
think
it's
still
not
in
the
position
to
be
convinced
that
laser
server
is
good
for
production,
but
for
our
use
case
personally,
I'm
just
I'm
just
gonna
speak
from
two
perspective.
From
a
z
perspective,
it
was
super
worth
it
for
us.
We
were
able
to
focus
on
delivering
the
product,
not
fine,
not
figuring
out
the
technology.
C
If
you're
from
a
high
level
management
perspective
delivering
the
product
is
a
much
much
better
experience.
Of
course
you
need
to
have
good
coding
behind
it
right,
but
instead
of
us
trying
to
learn
how
to
do
pagination
websites
real
time
streaming,
those
kinds
of
things
instead
of
us
creating
those
serialization
and
the
client
side
on
the
browser
side,
laser
server
removed
all
those
problems
for
the
blazer
server,
basically
allowed
us
to
deliver
faster.
We
don't
have.
C
We
didn't
have
to
worry
about
those
things
we
just
focused
on
delivering
the
product
and
that's,
I
think,
that's
that's.
What
made
my
nz
studio
our
product
have
its
features,
and
basically
it
has
a
lot
of
features
now
and
we're
growing
the
features
and
we
were
able
to
add
features.
For
example,
I
think
within
a
week
or
two
because
you
don't
have
to
worry
about
functionality
because
you
don't
have
sorry
happens.
Sorry
because
we
didn't
have
to
we
didn't
have
to
worry
about.
C
We
didn't
have
to
worry
about
learning
new
technology.
We
just
need
to
make
it
work
on
html
and
laser
and
we're
good
right
and
we
don't
have
to
worry
about
c
sharp
syntax
right.
We
just
need
sorry,
we
didn't.
We
don't
need
to
learn
about
javascript
syntax
in
that
in
depth.
Of
course,
we
know
it,
but
I
think
with
just
the
t-shirt
impact
it's
already
good
and
all
of
our
developers
can
work
on
the
ui
on
the
back
end
and
on
the
server
side
itself.
C
So
meaning
we
don't
have
a
division
of
the
developers
we
can.
We
can
get
help
from
anywhere.
They
can
do
database
right.
But
if
you
do
with
the
typical
development
you
have
a
ui
layer,
then
you
have
the
rest
api
layer.
We
don't
we
don't
want
to
worry
about.
We
don't
want
to
worry
about
those
things.
We
want
to
focus
on
delivering
the
product.
My
other,
my
other
answer
in
this
one
is
from
a
personal
perspective.
C
It's
I'm
not
sure
if
it
if
what
laser
survey
did
for
us
can
be
done
by
angular
and
the
app
in
a
short
amount
of
time,
and
we
basically,
I
was
surprised
because
we're
handling
hundreds
of
thousands
to
millions
of
records
and
later
surveys
doing
it
in
a
snap
and
it's
like
when
you
when
we
display
it
on
the
browser
side,
the
browser.
Basically,
it's
not
having
us,
it's
not
having
a
sweat
trying
to
display
all
those
things.
It's
hap,
it
happens
so
fast.
C
It
looks
like
we
don't
have
a
lot
of
data,
but
what
sure,
but
what
swarm
presented
earlier?
It
has
a
lot
of
data
behind
it.
It's
like
the
data
where
it
came
from.
It
has
500
mb,
500
megs
of
data
up
to
one
gigs
of
data,
we're
loading
it
and
the
browser
is
not
even
complaining
because
all
is
being
done
on
the
server
side.
C
So
yeah
I've
been
talking
a
lot
of
things
about
this
vhr
server.
So
hopefully
you
guys
have
learned
something
and
on
I'm
going
to
post
my
personal
email
address
and
my
email.
So
basically,
if
you
have
questions
on
laser
server
or
if
you
are
interested
with
data
server,
so
we're
open,
I
mean
we're
always
expanding
right,
so
I
think
it's
also.
C
I
join
it
and
maybe
I
can
just
quickly
plug
it
sure
go
ahead
if
you're
interested
with
blazer
server
or
laser
development,
we're
looking
for
developers
as
well,
who
are
interested
and
who
wants
to
share
the
passion
that
sauron
and
I
have
on
these
things
so
yeah.
Thank
you
so
much
for
the
time,
john
and
I'm
open
to
questions
now.
B
A
Really
well
well,
the
first
at
least
the
first
two
is
really
about
about
scale.
Retto
games
asks,
are
you
confident?
Blazer
server
can
scale
and
I
guess
the
same
question
is
asked
by
james
amity.
Can
blazer
client
scale
easily?
I
guess
that's
two
different
scaling
questions,
but
but
but
yeah
from
one
for
the
server
one
for
for
for
for
the
client
and
and-
and
I
guess,
we've
heard
a
lot
of
a
bit
of
the
answer
from
you
but
yeah.
What
can
you
say
about
their
their
questions?.
C
Okay,
so,
let's
start
with,
I
think,
let's
start
with
the
easier
one,
the
blazer
wasn't
the
blazer
client.
So
I
think
it
was
asked
by
james
amati
right
so
james
to
answer
your
question.
Blazer
client
can
actually
be
skilled
easily.
Why
it's?
You
can
just
have
a
cdn,
have
the
cd
and
serve
your
blazers
laser
client.
It's
the
same
as
your
typical
angular
or
your
typical
react
on
how
you
scale
it
right.
Typically,
when
they
scale
those
angular
or
react,
they
can
just
have
a
cdn
server
and
then
just
host
it
there.
C
C
It's
much
much
easier!
Okay,
next
question
the
harder
one:
the
blazer
server:
how
do
you
scale
a
blazer
server,
and
am
I
confident
that
we
can
actually
scale
blazer
server?
To
be
honest,
it's
a
yes
and
no
answer.
First,
one
is
we
add.
If
you
want
to
offload
some
of
the
load
on
the
server,
you
can
use
azure
signal
r.
Oh,
it's
a
good!
It's
a
good
segue
to
the
azure
signalr
as
a
service.
Azure
offers
a
signalr
as
a
service,
meaning
those
are
connections
you
don't
your
server
doesn't
have
to
keep
them.
C
You
can
just
make
azure
handle
them
for
you,
it's
going
to
make
things
easier
right.
It's
going
to
make
things
lighter,
because
you're
offloading
those
communication
platform
to
azure.
The
second
one
is
that
you
have
to
be
aware
of.
Is
you
can
put
blazer
server
in
a
docker
container?
You
can
even
scale
it
via
the
heart
container,
but
you
have
to
take
note
that
you
need
to
enable
sticky
sessions
right
because
in
sticky
sessions
sometimes
the
server
can
hold
the
dom
inside
of
it.
It
can.
C
If,
for
example,
the
client
wants
to
reconnect
it
can
reconstruct
the
dom
from
the
existing
connection
right,
but
from
our
experience
getting
a
new
dom
management
or
basically
getting
a
new
connection,
it
still
happens.
It
still
happens
so
fast.
So
I
think
scaling
won't
be
an
issue,
but
you
have
to
take
note
that
if
you
want
to
scale
you
have
to
take
note
of
the
server
memory
right.
C
You
need
to
understand,
for
example,
how
many
clients
can
go
to
a
server,
because
a
server
will
hold
all
those
whole
will
hold
all
those
information
into
memory.
So
you
need
to
understand
how
much
memory
are
you
consuming
per
a
per
client
and
then
the
with
that,
if
you
understand
those
things
scaling
would
be
much
easier.
A
C
C
Okay,
I
think
I
think
I
get
the
question
now
so
think
of
it
as
this
way,
if
you
click
a
button,
let's
say
you
have
a
javascript
element
right,
sorry
arrangement:
you
click
a
button
right
and
it's
gonna
send
it
back
to
the
server
right.
So
blazer
server
does
those
things
automatically
for
you.
You
can
hook
up
events.
I
think
I
think
I
mentioned
it
earlier
right.
We
can
manually
hook
up
events
via
javascript.
C
I
think
we
did
that
on
some
of
our
external
libraries,
but
the
problem
with
that
is,
you
have
to
be
very
careful
that
sometimes
the
element
might
get
disposed,
meaning
the
reference
is
not
there.
The
component
was
actually
removed
by
the
server
application
and
javascript
might
encounter
an
error
because
it
cannot
find
the
reference
anymore
or
vice
versa.
You
have
a
dynamically
rendered
element
in
your
dom
in
the
client
side
and
c-sharp
on
your
server
side
is
getting
a
reference
to
it
and
sometimes
the
c
sharp.
C
Might
the
c
sharp
code
might
not
yet
get
it.
It's
not
yet
on
the
c
sharp
reference.
So
it's
going
to
be
null,
so
you
might
have
null
reference
exception
in
your
code.
So
for
those
kinds
of
things
I
think
it's
more
or
less
being
having
the
mindset
of
a
defensive
coding
in
terms
of
those
things
would
help
you
a
lot
like
just
wrap.
C
A
C
Yeah,
so
for
those
kinds
of
things,
what
you
need
to
know
is
that
in
a
blazer
server
application
or
in
a
signal
r,
you
are
given
a
dedicated
connection.
You
don't
share
a
connection
with
another
user
right
so,
let's
say,
for
example,
the
three
of
us
here,
for
example
john
me
and
sauron.
We
will
have
our
own
connection.
So
let's
say
on
my
end,
I
have
the
on
the
I
have
the
on
mouse
move
event.
C
Even
if
I
keep
spamming
it,
it
won't
affect
the
connection
of
sauron
and
john,
because
it's
a
different
kind
of
connection.
They
are
going
on
a
different
hub.
It's
a
different
connection,
so
the
the
main,
I
think,
the
main
point
and
the
what
I
what
I
want
to
point
out
on
this
one
is
it's
still
an
isolated
connection.
So
as
long
as
your
server
can
handle
it
or
if
you
want
to
offload
it
to
azure,
then
you're
still
safe
with
this
one,
because
each
connection
are
repeated
independently
and
securely.
A
A
B
Side,
I
I
don't
think
I
would
use
server
side
blazer
if
you
have
a
million
users
that
are
always
connected.
So
if
you're
building
a
game
app
or
anything
like
that,
you'd
probably
go
client-side
for
us.
We
will
have
more
memory
usage
at
any
point
than
connections
right.
So
if
we
have
a
thousand
users,
our
memory
would
be
so
large.
We
would
have
multiple
servers
anyway
and,
like
kedran
said
that
we
huge
sticky,
sticky
sessions.
B
I
know
microsoft
have
done
some
tests
on
scaling
the
signalr
connections,
to
hundreds
of
thousands
of
connections
and
they're
still
working,
but
it's
not
really
our
scenario,
and
I
wouldn't
do
it.
If
it
was
me,
I
wouldn't
do
it
with
a
million
users,
for
instance,
if
you
want
to
scale
to
that,
so
no.
A
Yeah
great
great
point,
great
point:
I
guess
another
thing
I
wanted
to
do
to
bring
up
in
in
in
all
of
this
discussion
is
again
that
you
know
the
advantages
and
the
disadvantages
of
blazer
client
versus
versus
blazer
server.
One
of
the
things
that
that
that
was
pointed
out
to
me
is
that,
because
of
the
cost
of
hosting,
you
know
something
for
blazer
client
in
a
cdn,
it's
much
much
much
much
much
lower
than
having
an
app
service.
A
That's
that
that's
taking
your
api
calls
or
taking
signal,
or
in
some
cases
that's
much
better.
But
again,
if
you
were
your,
your
spy
is
getting
bigger
and
fatter.
That
means
that
there's
more
loading
time
upfront
on
on
your
side.
So
I
guess
it's
a
balancing
act
between
the
two
and
it
really
depends
on
what
your
application
is
doing,
and
this
is
a
great
example
of
mindsees.
Applications
is
a
great
example
of
something
that's
well
suited
for
that
server.
Blazer
server
model,
yeah.
C
Also,
join
your
point,
one
of
the
things
I
think
it
was
mentioned
by
sauron
earlier.
If
you
have
a
spa
application,
chances
are
basically
it's
not
chances.
It's
happening.
You
are
giving
your
client
source
code
to
the
browser
right.
So
if
you
have
some
proprietary
code
there
it's
going
to
be
given
to
the
client,
it's
exposed
publicly
right.
We
want
to
avoid
those
things
because
in
laser
server
we
only
give
out
the
final
dom
element.
C
We
don't
give
out
the
logic
on
how
we
build
those
components
right,
because
some
of
those,
though,
of
some
of
the
ways
that
we
build,
some
of
our
components,
are
of
our
blocks.
Our
logic.
Some
of
them
are
proprietary
because
there's
some
kind
of
like
code
and
code
proprietary
code
in
it
right.
So,
if
you
do
an,
if
you
do
a
spa
like,
for
example,
yeah
you're
actually
giving
the
whole
source
code,
it's
just.
It
was
transpiled
to
a
different
format,
but
it
still
does
source
code.
Someone
can
still
like
deconstruct
it
right.
A
C
C
Basically,
if
you
want
to
go
micro
services,
are
you
sure
that
you
want
to
go
microservices
with
signal
r,
because
I
think
I'd
rather
go
with
an
http
call
hitting
restful
apis
with
awesome
application
right,
because
signalr
basically
keeps
one
connection
open,
and
if
you
have
one,
if
you
have
let's
say
you
have
10
microservices
10
endpoints
that
you
want
to
connect
to.
Do
you
really
want
to
keep
10
single
arc
connections
inside
the
browser?
C
Take
note,
the
browser
has
a
limitation
of
I
think
it's
six
or
seven,
I'm
not
sure
I
forgot
the
right
number.
I
think
the
browser
can
only
keep
a
six
or
seven
connection
open
at
the
same
time.
So
if
you're
hitting
10
micro
services-
and
you
have
10
signalr
connections-
that's
not
going
to
work,
you
can
only
have
up
to
six
or
seven
six
right.
I
forgot
secret
seven
one
of
those
two,
but
in
signal
r,
with
blizzard
server
all
are
happening
in
that
one
connection,
so
you
still
have
six
four
other
different
connections.
C
So
I
think
that's
one
of
the
things
that
you
have
to
point
out
at
this
one.
So
if
we're
going
to
be
doing,
microservices
don't
use
wasa
because
wasan
you
can
just
do
a
cdn
just
use
microsoft
on
your
restful.
Endpoints
I'd
rather
go
microservices
with
laser
spa
and
keep
the
one
signalr
for
each
instance
that
I
have.
I
mean
for
each
client
application
that
I
have
and
then
do
the
internal
routing
inside
the
server
itself,
because
the
server
can
actually
be
the
one
to
call
the
internal
restful
apis.
A
So
that's
also
a
good,
a
good
talk
for
for
for
everyone
listening
here
if
they
want
to
go
back
on
the
youtube
channel
of
browse
back
of
back
in,
I
think,
that's
april,
our
april
session
actually
talks
a
lot
about
those
connections
and
and
how
many
connections
that
your
browser
can
keep
and
and
and
yeah.
That
was
an
awesome
session
on
on
on
optimizing
your
your
your
web
application,
so
that
might
clear
up
some
of
the
some
of
the
concepts
here
all
right.
A
C
Okay,
so
just
a
quick
closing
remarks
for
me,
so
I
think
yeah
I
I
talked
about
later
server
for
a
long
time
already
I
mean
for
all
yeah,
but
what
I
want
to
focus
on.
So
if
you
guys
are
interested
in
trying
out
blazer
server
and
if
you
want
to
find
a
good
like
company
and
if
you
think
that
our
philosophy
is
aligned
with
you,
so
you
can
contact
me
on
linkedin
and
we
can
talk
about
it
more
sorry.
I.
B
B
B
I
hope
also
thanks
for
the
time
by
the
way,
john,
it's
been
great
joining
you.
I
hope
that
there
are
some
people
that
will
look
more
carefully
at
blazer,
there's
a
lot
of
people
that
are
in
companies
where
you
can't
choose
it
or
it
may
or
may
not
be
your
choice,
but
the
only
way
you
get
stuff
like
this
into
your
company
is
do
some
of
it
on
your
own
time
right,
there's
so
many
sample,
apps
and
they're
very
easy
to
get
started
up,
build
some
sample
apps
and
actually
show
your
managers.
B
How
easy
some
of
this
stuff
is
and
a
couple
of
things
we
didn't
talk
about.
We
talked
about
keep
laser
server,
side
and
client
side.
You
can
switch
the
components
from
the
server
side
to
the
client
side,
it's
very
little
development
that
has
to
happen.
So
you
can
now
take
a
huge
application
that
our
previous
applications
were
a
massive
solution
that
was
hard
to
compartmentalize.
B
What
you
can
do
now
is
you
can
create
an
assembly
with
css
c-sharp,
all
the
code
html
all
inside
one
assembly,
and
you
can
now
start
componentizing.
Your
websites,
which
you
couldn't
do
before
so
not
only
join
our
company
we'd
love
to
have
you
and
love
to
talk
about
this
stuff,
but
also
start
using
blazer,
because
it's
a
much
better
technology
right.
So
try
to
use
it
guys
and
if
you
don't
agree
with
us.
Please
comment
on
the
videos
for
this
and
we'd
love
to
talk
about
it.
We're
very
passionate
about
this.
B
A
B
A
All
right,
that's
it
for
our
for
tonight's
session.
We
ran
over
time
for
for
half
an
hour,
but
but
but
that's
all
right
lots
of
learnings.
It's
a
totally
very
interesting
technology,
and
we
look
forward
to
everybody's
questions
on
this
dude
and
you
could
do
it
and
on
youtube.
You
could
do
it
on
the
on
facebook,
wherever
you're
watching.
A
Please
throw
out
your
questions
and
I'm
going
to
use
this
time
myself
to
to
to
to
advertise
some
openings
for
my
own
company,
so
paychecks
vanilla
office
has
a
few
openings
for
for,
for
senior
developers,
lead
developers,
and
we
also
have
openings
for
senior
ui
and
ux
people.
So
if,
if
you're
interested
in
in
joining
me
and
my
company,
please
please
reach
out.
That's
it.
That's
that's
everything
we
have
for
for
for
tonight.
Thank
you,
everyone
that
that
had
been
in
this
stream.