oh hello everyone I can see that people
are still having a coffee out there so
hopefully you can rush and come in so
that we don't lose much time with this
presentation okay so we start my name is
Naruto so ease as they were mentioning
I'm from Argentina very living kale and
I came to talk about api's the
presentation slice are already online so
you can actually check it out
slice come slash lilo so slash
component-based API you can actually
take a picture of that if you want to
check it out later I will give quite
some stuff 25 minutes is kind of hard to
fit everything in so if you want to find
out more later I mean maybe we can go in
more detail and my twitter handle is
your service same as my surname okay so
we start so if we're talking old api's
we must talk about the current host
stuff which is what graph cured right so
graph QL is increasingly popular this is
the stats from the state of JavaScript
from last year that is says that 20% of
people who have used it they have they
have liked it so they won't talk should
use it again and 62% they have heard of
it unlike to learn so I mean this is
certainly gaining ground and we can
expect graph QL to be the new normal
affion maybe time out for rest a lot of
rest api switch are still out there of
course but it like if you have to start
a new project quite likely you might
actually want to do it graph QL oh
that's the situation right now so why is
it so the one characteristic from graph
QL that everyone talks about is how you
can actually get exactly the data that
you need to fill your layouts your
components so say that you have this
layout ok so this is like a widget with
a feature director we have they're
showing a couple of themes and each film
showing some of its outdoors
so the way that you actually fetch the
data through mmm through okay well
actually you need to get data so in the
case of the director we need to get the
name the country on the avatar then for
each of the things we have the thumbnail
and the time and then for reactors we
have the avatar and the name so graph QL
is very straightforward you can define a
scheme and then you define a query that
lets you get the data as you need it and
what you're actually get from this is a
response with the data in the structure
as you need it so this is actually quite
cool right you get exactly what you need
so this is improvement of a rest and why
is taking over from rest and this plays
very nicely with components so if you're
actually guys calling with Riyadh and
buges I guess that's in the situation
you will actually love graph QL because
it goes one-to-one with with with the
concept of components so in this
situation we have an outer component
called feature director which has a film
it iterates over the list of films and
each film component has an called an
actor component okay and if you actually
pay attention to this is exactly the
same structure so very practical for
this so so far so good graph QL is
awesome but it is not perfect and
luckily so it comes with a few
limitations or trade-offs we can
actually say so one of the trade-offs is
that it is not catchable on the back end
you can still cache the aquarium but it
has to be on the client side and there
is a penalty for that because you're
adding code to the front-end you had to
part the JavaScript you had to execute
the JavaScript sorry not ideal okay
another problem is that this is
acceptable to denial of service attacks
because now you're given a lot of power
to the client to fetch whatever data
they want so if any evil person they
won't actually take your database down
they can actually execute a very complex
query that maybe you're thoroughly like
take one second to process it doesn't
seem so much but actually doing that for
many many thousands of course can
actually take the data rate down on your
server
so once again they can be mitigated
they're like strategies for dealing with
the with these gos attacks but it's all
in complexity to the application now you
had to actually think about the
complexity of the query you have to
think out the nested that the depth of
the query you can limit that you can
actually think about timeout so once
again this is not ideal so let me
present you a project that I've been
working on that it's called the
component based API and before anything
I need to say it's a work in progress
and it will be released in a few months
so I'm kind of sorry about this I wanted
to finish it for J's conf
be here saying okay we're releasing it
today and you know I mean a planning
time management of time is one of the
most complex things in software
development so it hasn't happened it has
been like two months away from being
ready for like six months now and still
a few months away so yeah I'm sorry
about this but everything that I'm going
to show you now is working all the
fundamental having implemented and I
also have it running on a couple of
production sites so whatever you will
actually see here is pretty much there
okay I'm not talking I'm not bluffing
everything I will show is actually
working I will try to do this following
the example by graphical of having an
open specification so then you can
implement it for different technologies
and how different systems interact with
each other independently of their
underlying implementation that's pretty
cool what it is and finally it's a
recognition that not everything is bad
about rest so graph QL is actually
taking over from rest not because rest
is pal both have advantages and
disadvantages and actually they may even
complement each other in the sense that
res has advantages that graphical does
not have and the other way around so I
was actually thinking this is actually
pretty cool from retina to discard that
and were actually try to do is to get
the best from both approaches which is
what I'm going to show you now so mostly
concerning fetching data basically the
good thing about graph QL is that it
allows you to fetch the data that you
need exactly that and that was the big
problem with rest so I actually took
this it allows you to fetch exactly the
data that you need like Rafkin
but it has an interface like rest so if
in graph curl you have a Korean of this
type you have a feature detector with a
few properties then film with a few
properties and then an actor the way
that I translate this through the URL is
first I get the properties for the
director and I pass it through a field
parameter on the uran then I get the
property for the film and I also passes
through the fields parameter in a kind
of dot notation so it now films to
tighten and then a pipe thumbnail to say
this property or that probably watch a
deeper the and that property and finally
once again for the actors starting from
the root films dot actors dot name pipe
avatar so having these syntax I can
actually query the the service from the
URL so we have solved the catch ability
issue because now my URL is my
identifier and I can actually cache this
in the backend so that's the first thing
that is actually solved a combination
from rest and graphical now concerning
the shape of the data that were actually
fetching so in graph QL what you have is
that the shape of the data mirrors one
to one their query right you say give me
future director and then the future
director has the film and if you has a
doctor and you're actually returning
exactly that same shape but I decide to
use the structure as the data has been
defined on the database assuming there
is an SQL database maybe this doesn't
make much sense within no SQL database
but you have an SQL database that you
have like tables and you're thinking of
rows and columns okay and then you have
relationships among the entities that
you have an ID
pointing to an object on another table
so that was my model on which I actually
implemented this so once again this is
graph QL this is how you get the
response and what we have in this other
paradigm is databases and then you
this you can call it the table sort of I
call it people with the idea of the
entity okay now he has the name the
country avatar and themes and the film's
is of being nested to get the entity of
the film it has a reference to the ID
entity so then we go to the film's down
here here we have the entity with that
idea so this one has its own property
style thumbnail and then he has the
property actors which is an ID pointing
to the actor entity back again on people
so it's you know as you can see this is
actually replicating sort of the
structure of the database are you have
it on the back end like like bringing it
to the front end these solves the denial
of service attacks now why is that I
will actually have a different quality
to explain better this is a tiny bit
exaggerated I don't think I would
actually have a body like this but it
makes the point imagine that you have
this query that you're querying for
posts and all the post you bring the
tile and the author then the author you
have the name and followers the
followers have the name and the
recommended post which has a tile author
whatever okay so if you actually pay
attention to this you are given
different names to the same two entities
which are the post and the users okay so
if you actually think about this in
terms of graph QL you have a nested
relationship upon all of the entities
and you have a query executes after
query executes in after a query executes
after acquiring right so everything is
is compound and I've read in a paper
that the complexity of this I don't know
if it is right or not because I hadn't
seen any validation of the paper I can
share the URL with you but he says that
the complexity is exponential to fetch
data and it's polynomial to find out the
complexity of the query so that if it
goes over the threshold of your security
limitations you cannot execute it but at
least it takes polynomial time but if
you think about this structure in terms
of database that you have in there like
SQL database this is simply two tables
like post and users with relationships
among them and you have actually made it
flat
No and because it's flood and I know
that the entity that I will have is the
sender I already have loaded in advance
I just get the aquarium sorry I get the
IDS from the forth or executions and
then I compile everything together the
time complexity is linear so because
it's linear you can actually have 200
nested the relationship among entity can
be like 200 levels down okay
and this still be performs well I don't
know if that's a game with graph QL I
don't think that you'll have a use case
to have like 200 levels deep down but if
you ever had to this performs better
because it's flat
so let's I'll show you a tiny bit more
about the API response whether we
actually get so the idea is that you
have the data it comes back how do you
use the data right I mean how do I know
which is the data that I need to show in
my component so we say that we have
another component called feature
director getting its fields name country
now water then you have an inner
component the film and then you have
another another component the actor
right so the way that I actually solved
that problem is that you have the idea
of the of the entity that is querying
for the data in this case the the one
who's calling for the data is a feature
director is saying I need the feature
director okay and then the subcomponents
will be asking for properties from this
rich field entity so this guy he says
here the future director the result is
entity with ID 1 ok from which database
or which database tell it appears under
the key ID which is people so when you
go to people here it says people entity
with ID 1 name country avatar and then
films and then he gives me the ID of the
films from this guy so and it is 1 and 2
where do I retrieve this data from here
it says from the
key under films which is called films
also so now we come to films and he
gives me the entity okay Tyler thumbnail
actors and I trust he gives me the
actors with IDs two and three once again
what do I get them from from films dot
actors and he says you have to get these
from the database or table called people
okay so now in people two and three we
have these entities and you can see that
the data that are actually retrieved
from from each is exactly what they need
so this number one is George Lucas is
the director I need to display the
avatar from him and the country okay a
one McGregor he's only an actor so I'm
not sure in the the country from him and
not even display this
okay so doesn't bring it is pretty much
like graph QL but the data is arranged
on a different structure what is the
cool thing about this one thing that
they take normalized so you can see on
the example we have the same actor twice
Natalie Portman so in graphic where you
actually bring this data twice here you
bring it only once then they they say
unique database containing all the dates
and the client so you can actually merge
all of these because now it's flat you
know how like next levels with renaming
of the same entity now you know I posted
suppose the user is a user it's flat you
can actually merge it when you bring it
from the from your cultural API you
merge it on the client and you have a
cache so if you know that you will need
to fetch this data later on and you
already have retrieved it you have it
there you don't even need to make that
that call so this is awesome for
performance because the most performing
application is the one that does not
need to make that HTTP call if it is
redundant don't make it and this makes
it possible and finally another cool
property is that because the dates
already share among all of the
components if one component is fetching
data okay and this data has been updated
in the time in between and another
component also was using the same data
then both components can be render
Europe you can observe on the database
basically so it's a building content
object
on the fly and then observe this object
you can actually have an idea of being
overly observing the database and the
layout can be can react to the data
inside the database this is not
implemented by the way but the
architecture supports this and that's
hopefully one of the upcoming things are
will implement soon so concerning the
API response I don't have enough time so
I cannot show it to you but if you are
going to check out the presentation
later on you can click on these two
links and this is deployed on a
production server so you can actually
see it working already so having this
everything that comes that I would
actually explain in the next slides is
working so let's see how this works so
the important thing here and I'm sorry
about this is that the components are
implemented partly in the front end and
partly in the back end so I know that
you're not that you don't trust back-end
developers yeah this is something that
believe me makes sense and I will try to
convince you so that maybe you can have
a tiny bit more of steam for us but the
thing about these is that is it not back
end or front end the component actually
lives pretty in the back end and the
front end and implements part of your
responsibilities where it makes most
sense so what am I talking about here is
a following
I have delineated four layers okay that
make it up as a progressively enhanced
service from API to application on the
very first layer you have the data layer
okay so this is basically your API you
define what data the component needs and
having that alone you really have the
API you can actually stop it there okay
but you can also continue you can on top
of the data layer you can add a
configuration layer okay on the backend
so I'm talking about defining classes
and styles and the strings that you need
to display in your view that you
actually set it up on the backend then
we got referent in the view layer is in
the fronton and of course reactivity
also will happen on on the front end so
what basically I'm saying with all of
this is that the application your own
application that you have for your own
it can be model as an extension of your
API so you have to provide an API for
your clients to retrieve your data well
your application can actually continue
from there and and yeah and demonstrate
the API the application becomes the API
the other thing is that the examples
that I showed you about querying
specific fields to the URL which is the
basically the graph QL like
functionality is simply a specific use
case of this architecture because what I
do is to basically on runtime create the
hierarchy of components that I need to
match those fields and I and I give it
back to you so that's just one use case
and what you can do with this is
actually much more so I found out
actually pretty pretty cool how does
this work so on the back end we have a
component hierarchy which is how a
component relates to each other like I
own like I'm dropping this component and
that component wrapping that component
you have props you have data fields and
you have the configuration so I have
coded this in PHP this PHP code so you
have functions get some modules which
first define the hierarchy or how
companies read to each other then you
have init props and init props is very
interesting I mean it receives a module
and the object props to initialize a
component can set properties for itself
of course and also for his children
component like all the way down right
and every ancestor has higher priority
over its children so the top most
component at every job conferring the
properties overriding all the properties
from its children ok that's one thing
but second thing that this is on the
back end so it's a very easy to set
properties horizontally not just
vertically so you can actually in just
one line of code say all these many
components inject this property and it
just works and you don't need to deploy
any JavaScript file you know when you
change one string you know like I mean
one description or one class name ok it
you you touching it on the bakken and
it's already live no need to deploy
anything only for web pack or anything
then you have the data fields I will
explain this tiny bit later
and the configuration and this is the
how it looks on the view have
implemented he would handlebars so this
is an example of a drop-down and you can
see basically a deal then they say
button then they say a ul and it
iterates all of its sub modules and for
each of them like it prints on LI and it
says each of the sub modules
render yourself so what's so cool about
this is that the component the view in
this case is completely decoupled from
its children this drop-down doesn't know
whose children is going to be you
actually settle that on the on the on
the back end through configuration so
then you are really playing like Lego
like this is on steroids because you
have any one implementation of the of
the view that you can actually add
inject everywhere yesterday when we had
the talk by issue and she was mentioning
about this approp collapsing right this
complexity of props because you don't
want to separate the component into
another component because the
functionality is kind of the same and
you don't want to duplicate : right you
want to stick to dry and then you end up
having a monster and you're saying it's
okay you can repeat call it makes sense
okay with this architecture they no need
for that because this is how the
component looks like in the front end
okay it's extremely decoupled from all
of its children so then they know a prop
Clips it just cannot happen so every
component creates its context on the
back end and it receives its context on
the front end and only its context conde
on the view you just don't care about
having to iterate the data you carried
the view doesn't know or doesn't care
about its subcomponents and props can be
set vertically and horizontally so this
is the component architecture let's say
that we actually have a page in this
case / po / lovely tango at the very top
of the other page my component is called
post and it will contain some other
components right so in this case I have
a sub component called post l1 called
post thumbnail and one called post
content so this is
the way to represent is very simple okay
just like that this is an
oversimplification I mean you can see
that like a big widget there and the
widget contains other components in the
component contains other components this
is just to simply to simplify okay it
makes the case and the way that it works
on the backend is that you define the
relationships among all of these
components with that function for
retrieving data each component must
define what data fits in is from the
database just for itself without
including the data fields for its sub
components so you can think of these
like fragments in graph QL but on
steroids because once again each level
of the component defines this is my data
that I need not my cell components
somewhere QL right now you have the
possibility of a component getting the
data also for its sub components okay
but in this case each component at each
layer says this is the data Deranian at
every single level and the cool thing
about this is a by having this
architecture the endpoint URL from which
to fetch the data and also the query to
execute against the database can be
automatically generated from the
component hierarchy itself so what does
this mean so we have this component
architecture right so the originally the
topmost component says I need to fetch
data from this post okay the one
corresponding to the URL and for that
moment on all the components inside of
this guy whenever they fetch a property
it will be referencing this entity in
this post so post title will actually
load property title the post terminal
will load property thumbnail and post
constant will actually load property
content so iterating from the topmost
component all the way down you get the
property from each and you can construct
the URL so now this endpoint URL okay
that I was showing you how you can fetch
the data and you need it like graph QL
like sorts I don't even need to call it
anymore because it's automatically
generated from the structure of the
components itself and that's amazing if
you actually change one component that
you have another component is it already
works but not only that because now this
is on living on the backend I have the
possibility to also create the query
okay so you can also say
so execute the data Amelie on the server
and retrieve and return the date I
merely no need to actually have that
round-trip to give to load the client
and then the client needs to fetch the
data from the server and then the server
returns the date and then you render
that you can just return the data
directly that's an option understand
that you had to do this but now you had
the possibility you can actually choose
so if you actually want to have like
relationships among entities this also
works when we're actually loading this
post author component he will actually
change the entity from the post to the
post offer okay and from that moment on
all the sub components from this guy
will be loading properties on this
entity on the user or author in this
case the user name lost property name
and the user loads property avatar once
again the endpoint URL and the database
query are automatically generated how
does it look on the back and on the
front end so we had a view for the outer
most component which is basically a
simple field line saying okay now inject
this entity into the context and then
iterate over all my sub modules or sub
components and for each of them render
yourself using this entity on your
context okay so when this sub component
the receive the data in this case the
tile it just prints itself okay you have
the objector having loaded on its
context and he says I want to show my
property tile that you have expesive ID
on the backend
okay property tile but now also because
we can load configuration we can even do
something like this we can actually say
okay I want instead of saying h1
straight on the view you can actually
say h1 through configuration add a class
also and you can change this through
configuration that's pretty powerful
what is it so
when he reaches the post author is the
same so this guy will actually change
from the current post to the post of
Thor into the context and tell all of
its subcomponents render yourself using
the new entity I had to wrap up so I'm
going to be pretty quick now with this
but I want to enumerate all the many
advantages of this architecture first
one is isomorphism which is basically
the capability of running your call on
the on the server side or on the front
end you're thinking of JavaScript this
is another approach so on one side the
handle bar templates they can be
compiled to run as PHP they say
wonderful library called light on
candidate at that and he runs like like
native PHP code is very fast awesome and
on the other side the pitch free
configuration can be exported as a JSON
file because basically this component
hierarchy is a big array of components
listing all of their properties and then
saying these are my sub components
listen they're producing these are minor
components so listen an array you just
execute JSON encode on this and you
obtain a JSON so that means that you
have on one side the possibility to run
this on the server and execute
server-side rendering okay I don't I
decide you can export these for the
front-end you have a service application
it's up to you and the cone is the same
an ewok it works on both back in and
from them then you can also target
specific components so in this case we
have a post and the post has a component
called post I'll I can through the URL
saying I want the data just for this
component and also for this other
component okay and what you get is the
equivalent of getting the data just for
these two guys and nothing else and that
I find wonderful because what it means
is that the component is its own API
imaginary have a component that is like
a infinite scroll you reach the bottom
of the page you need to get more data
now the component can just talk to
itself say I need more data so you
construct the URL the current URL and
the path to this component starting from
the top and you will only
the data for this guy and once again
because the hierarchy is such that at
the top you have one component at the
very top then the website is its own API
so then you know different between API
and website anymore this is both an API
and a website at the same time so you
can also implement single page
applications and you can also create
pattern libraries very easily because
you render a component and it gives you
the the visual identity it a component
also knows which is css3 hostel and it's
JavaScript files it just that's it you
don't need to call it somewhere else
finally you can implement cope which
means create once publish everywhere so
you have a single source of truth for
multiple platforms wave email apps so
you can actually have a JS component
that extends HTML CSS component and then
html's is a component that extends from
your abstract component so you can
actually layer the generations of the
other layout in this case we have a
website and then you have the email
every page on the website can be sent by
email for no extra cost so I'm finishing
yeah in a nutshell advantages of this
architecture you have the client-side
cache is it change the behavior of the
application is isomorphic they've
component anniversary's is own API
implement single page applications
generated pattern library you can
implement cope
so in summary from all of these you have
a lot of reduced complexity because if
you want to do all of these other things
anyway you have to do two three four
different technologies here with one
with just one architecture you solve
everything
more output in less time with fewer
resources so finishing finishing so this
is open source of course MIT license the
URL is github.com slash lilo so slash
pop okay so check it out is not ready
yet okay I'm a few months away from
finishing okay so if you cannot wait
come talk to me they know much
documentation there's some documentation
so you have to talk to me okay
but check it out okay and once again if
you want to check the presentations
right so come so I shoulda loss of slash
component by CPR you can click on the
list
it working thanks so much