All right, welcome everyone, we're going to go, yeah, it's four, so we did a kind of
a dry run this morning and we realized that there's too much content, so we're going to
have to, you know, skip, we're going to do the introduction, it's going to be very quick.
So this is where we work, it's called Mirai, blah, blah, blah, connect to the website,
you're going to see what we do, we do basically consultancy on a number of different clients
on development, architecture, digitalization, so on and so forth.
This is us, you can tell who's who, these are our Twitter handles and this is the Twitter
handle of Mirai, if you like to talk or if you don't like to talk, just feel free to
share on Twitter.
What we're going to talk about today, so this is the result of a number of lessons learned
that we had on a number of projects where we tried to solve a problem that we see coming
up over and over again, okay?
So it's just, we just took stock of the situation, we saw what was around, all the mistakes that
we made and we kind of condensed it into a presentation that we're going to give to
you, so this is by no means an idea of giving you best practices of any sort because there's
a lot of context that goes behind these kind of problems, but it's just the way we are
approaching the problem, the way we are analyzing the problem right now and the way we are
approaching it.
And we're going to talk about this idea of digital experience platform.
You will see that like behind the name, there is a thing that you will know that is this
idea that you start to have technical ecosystems that are more and more complex and these technical
ecosystems are done by a number of systems that need to integrate together and they need
to communicate together and they need to give back to the user in some form or another
on one channel or another, a number of information, a number of capabilities and interaction.
So that said, what is the state of the art?
What is the thing that is the trendy thing right now?
It's kind of synthesized, but this idea of the Mac kind of technologies, there's an
organization behind it, you may know it about it or not, but it's this idea that the new
architectures have kind of four major characteristics.
They're based on microservices, we're not going to go into the debate of the microservice,
what micro means and why do we need microservices or not.
They're API first, they're cloud native and they're headless.
We talked about headless, I think Alexandre talked about headless on material UI in the
previous talk.
I think that the two that you have to retain for this talk are these ones, that you have
systems where you don't necessarily care how the information or how the capabilities
are going to be exposed because it can be on a mobile app or it can be on a web application
or it can be on a kiosk that you have on a store or on something else, you just don't
care.
The system is capable of giving you this kind of capabilities and data regardless of the
channel that you use and how do they do that precisely by having an API first approach.
So you don't have the interface, you have the capabilities, you can call any kind of
HTTP REST service that is behind, the capabilities is there and then you take care of the visualization
or the user interface or the user experience somewhere else.
Am I going too fast?
No?
That's okay?
All right, but there's a kind of a yes but a kind of situation.
So let's see that you start from a simple website.
So this is what happened most of the time, you have a relatively complicated kind of
interaction website, you choose your framework, here you have React, you may have a number
of others, we basically don't care, but that's kind of one of the possible starting point.
And then you say, okay, but I would like to manage this content.
So what do you do?
You add a content management system.
That is okay.
You connect your content management system to your front end, off you go.
Now you have a number of editors that can manage your content.
All right, sounds good.
Then you want to add some commerce because the company is doing good, they want to add
commerce capabilities.
Well, very good.
You have a commerce engine that is headless API first, you can add your commerce engine
and then you start to connect it to your front end.
But you also have to connect it to your CMS because they need to share certain kind of
data.
And this is the situation that you have.
And then you have a lot of products.
So you start to have, you start to need a digital asset management because you need assets
for your MOBA, you need assets for your kiosk, you need assets for the web.
And you can't store them here because they're not made for this job.
So they start to see a bit of their constraints.
So you connect the dam and you connect it with the commerce, you connect it with the
CMS, and then you connect it with your front end as well because it's the ultimate client.
Okay, you kind of see where I'm going with this, right?
Search, you start to have a huge catalog, you need to add search, you add Algolia or
elastic search, we don't care, it's the same kind of concept behind.
And then you connect Algolia and you need to connect it with your commerce layer, you
need to connect it with your CMS, you need to connect it with your front end and off
we go.
Then you have a Netlify because why not?
And then at some point somebody says, you know what, I would like to do some customer
relationship management with the data that I have and then you start to add the CRM.
And that's where you end up with the situation.
Now if we remove all the capabilities that are provided by the system, which is a huge
step forward because before you had to do all kinds of plumbing behind, you need to
reconnect your user interface from the system behind, it was very tedious and very complicated.
Now we have all those pieces of software that are capable of doing this by themselves,
where you're basically left with this.
And I was finding it funny what Alexander, I don't know if he's still here, was saying
in the previous talk, I would say you go headless and you just remove the problem, where you
would see that there's kind of a law of conservation of complexity, you just don't remove the problem,
you just shift it somewhere else, you know, someone or something still need to take care
of this.
And then of course, because we're not stupid and we're a good intelligent developer, what
we say is like, okay, this is not possible, we're going to create something that is going
to aggregate this all together and we basically create a layer.
But this complexity is still here.
So you kind of have a tension between the fact of having these Lego blocks and the modularity
and the fact that someone or something still needs to orchestrate all this kind of stuff.
And it can get very, very messy and very, very complicated very, very quickly.
All right, so this is the first problem, kind of big problem that we were trying to address.
The second kind of problem is that if you take kind of a random e-commerce kind of interface,
what we start to see more and more is that before it was just a matter of your CMS and
your commerce, you had the catalog and the basket, these were coming from the commerce
system and then your content was coming from the CMS.
What you start to see right now is that if you take all the blocks that compose, let's
say, a fashion e-commerce, in the same blocks, you have pieces of data that come from different
systems and you need to aggregate those and you need to present them as if they were a
unit because that's what the user cares about.
I need to have a catalog and the catalog is normally coming from the search because the
search is optimized so you don't ask it to the CMS and you don't ask it to the commerce
because you want to do all sorts of categorization and classification.
But then you don't show the IDs of the catalog, you show the product and the product comes
from the image from the dam, some content from the CMS and the SKUs from the commerce
system.
So, again, you see where we're going with this, it can get very complicated very quickly.
And the problem for us as developers behind is that every time that you need to change
something here, you need to make sure that everything stays coherent and consistent behind
the scenes.
And again, this can get very tedious very quickly.
So, I hope what I said kind of made sense as an introduction for the context.
You raise your hand if that was not the case, okay?
Everything is clear?
Sounds good.
I was getting scared.
Okay.
So, we have the problem.
Now what?
And that's where I handed over to Bouba that is going to show you what is the situation
that we're applying right now.
So, fully disclaimer, it's an approach that I'm showing you.
It's not silver bullet, it's an exploration, so be with us, it's not perfect, and just
trying stuff and trying to see where we can solve this problem if something.
So, first thing that I'm asking you is, you tell me which framework I'm using.
So basically, I'm running on 4,200 and 4,201, and if you look at the two websites, okay,
we are in JavaScript, I have to make a joke about CSS, I'm really bad at CSS, CSS is
a dark magic for me, so that's the reason why I don't bother with the logo, it's normal,
it's okay.
Just focus on the product here.
Could you tell me on right or left, depending where you are, who is build with next and
the other one is build with next, no, okay, so let's see on how we, here, so I will just
open it, so if I do an inspect, if I scroll a bit, so one of them is based on next, okay,
the second one is based on, because voila, next, okay, so you will say like, why I'm
asking that, like, okay, so if I tell you like, these two pages use the same base has
code, okay, and I just compile it, and then I get a component that works for React, that
works for view, and it's not a component, okay, so do you know a tool that can do that?
Nobody, okay, so I try, okay, so let's go.
So for this tool, I will be speaking about some tools that we are using to orchestrate
everything, so the first one is NX, so if you don't know NX, it's kind of like a tool
that you can use to handle all your monorepo, okay, it's a really good tool because I don't
want to set up webpack guys, or anything else, so I use this kind of tool to handle all
the configuration, just handling webpack, handling, side press, story block, everything,
it's handled by this tooling, okay, I just use that again, and then give you a good
basic when you work with your team, and really good standard, okay, second tool that we will
be showcasing is MetaZis, MetaZis will be the basic of how we build a component, like
I said, it's an exploration, it doesn't solve everything, it's just a base, and we are trying
to explore, so if someone knew something about MetaZis, did you hear about it, no, okay,
so give you some context, so MetaZis is a kind of like a compiler, component compiler
created by the Build.io team, so Build.io, they build kind of like a CMS that completely,
I will say visual CMS, where basically they have a lot of SDK, they would like to support
all the framework that we have in JavaScript, so it's a lot of frameworks, so they hire
multiple people, and then they're like, okay guys, you're hiring too many people, okay,
maybe you should find a way to be able to handle all this complexity, so they begin
to create a compiler for components, so they use a common layer, like JSX, and then base
with this common layer, they compile it to, natively, to React, Vue, Svald, or like all
bunch of stuff, okay, basically they take the approach of LLVM, so if you don't know
about it, they take the same approach, having a common layer where we can target, and then
all the architecture can file for that, so we'll be using that, frankly speaking, it's
not perfect, it's really at the beginning, what's really nice with that, they're really
pushing the boundary of that, because all the SDK, so if you use Build.io, basically
you're using me to this under the hood, so they use that to build all the SDK for the
visual editor, like everything that you're using for React, Vue, it's based on that,
so it's not perfect yet, it's improving every time, but it gives you really kind of like
a good code, I will not say it's perfect, a human will be better, yeah, but at the end
you win time and energy, because you write once, and you build everywhere, okay, it's
a dream like since like 20 years, I know, but voila, every time, every 10 years we try
to do it again and fail, maybe, but voila, someone try, okay, so basically if you take
back what Maurizio said, we are going on the headless, so our goal is really to reduce
the friction, so we have multiple frameworks, it's really difficult to go on client and
say, hey, you use React, you use Vue, you use Angular, okay, and every time we're building
the button, we're building the same thing, so trying to find like a common layer and
using me to this, we can really focus on what I said most of the time, the presentation
component, I'm not mean like for really big component with charts, it's not mean for that,
and don't try to do it, you'll be it early, and you will hate it, and you'll be like this
is shit, okay, it's really for, I will say common component that you will have, that
will be really simple, mostly UI based, not too complex, but kind of complex for some
stuff, so you can really reuse, basically if you're on React, the presentation component,
so we shouldn't say it anymore, since Dan said it's bad, but voilà, use the term, okay,
so I will show you how we did it, and what we have built, all the advantage issue that
I got about it, so I'm using upstone, okay, and basically here on the left side, you can
see I'm using, it's just a standard, which application on Enix, so you have the app folder,
the lips, and then all bunch of stuff that you have every time on every stuff, okay,
the lips contain all the kind of library, what's cool if Enix, so you don't need to
publish it, so you can really put it on the more repo, it handle all the configuration,
so when you import it in a React, it's basically use a test path on the hood and make the magic
on the web pack, it just works, okay, it's kind of like.magic, but it's not too complicated
on the hood, it's just test path and bringing it in port into the web pack, or vids, okay,
so basically we create a library, a core library, okay, using metosis, okay, so if you open
here, you can see I have a core library, this is the metosis, what I call a core, because
it's the basic for everything, all the components we are using, okay, then I create a subfolder
called the UI, UI will be like all my target that I'm pushing for people, okay, so I have
the UI for React, okay, and I have UI for view, okay, so let's first focus on the core,
so on the core I have like a metosis config, so basically it's a configuration layer where
I basically set up how I want to target and how I want to compile everything, so you can
see it's a bit messy, because like I said, it's not perfect, perfect completely, you
have some edgek's, but behind it's just basically a config that you put and you say, okay, let's
me scroll, you put where you put your file, where you put the right, really important,
I will explain it after, and then the targets we would like to do, it gives you also some
edgek's, like for example, you can set up if you want to compile the TypeScript, want to
run pressure already handling, like for example, how you want to handle a strict act, and have
like kind of like plug-in system, basically it helps you to hook into the system like
when you compile, okay, it's really basic, it's not like a big compile, it's just basic,
but it's already to fix some stuff that's not perfect, okay, like if I go a bit here,
like Ragnative, QIP, Swalt, like Swalt, you can see here like, holy shit, what this guy
is doing, like basically it's replacing stuff under the hood and patching stuff, yeah, sometimes
you have to do it, but voila, it's just like to give you like the extent where we can go,
most of the time you don't need that, this is really like edgek's for them, but you
have already code, okay, so then you have the SRC, the SRC basically is just where we
put all the code, so I will focus mostly on the component, so the convention is really
straight forward, it's just you create a component basically with.ly.t6, it's the convention
that will be every time pick automatically by the compiler and then we compile it to
view or react, okay, so basically here I'm just taking a simple component, this one
it's more tricky, I will open another one, I will say easier, not this one because this
one is hollow, let's take this one, okay, so here basically just under the hood it's
using like kind of like a.ly.t6, but a more.ly.t6 contraint, so if you know solid.ly.t6,
you already play with it, not you, basically solid, it's kind of like a react, what Red
should have been if they write it now, and basically to use like really a contraint.ly.t6
system to make it more performant, and basically they kind of copy some stuff from solid, like
for example if you want to do a maps, you don't do a maps, like in React like it's just
JavaScript, yeah okay, we know it's just JavaScript, but here you have to use the four component,
why it's because it makes easier for the compilation basically to be able to say okay, if I'm using
in view I use a v4, if I'm in React I use a map, if I'm in Angular I use an ng4, okay,
so this reason why they create these contraints is to make the compilation easier, if not
they have to play with the AST, so abstract the AST, abstract syntax tree, and just make
the complexity increase, so try to make it simpler, okay, and then they come with some
common ground, like for example you store, it's just kind of like a hook, basically this
will be compiled to a use state or some similar in view, okay, so they give you some rules
that you have to respect, it's really strict, it's not easy at the beginning, and that's
make the complexity of using this kind of tool, because you have to really think like,
when I say if I'm working in Java before, like in interface development way, okay, what
I mean by that is you have to think about the common ground between all the component
and all the frameworks, you cannot just say hey, I will write it like that, and basically
this does not exist another component, okay, or it's not compatible, okay, you have some
degree of flexibility, but it's not every time the case, okay, so you have to find really
the common ground, try and do it, but accept that, it's kind of like a just react, okay,
with some stuff, okay, so basically you get this component, and it will be compiled, and
you can see it on the output folder here, it will be compiled automatically on react,
so if I take the, here, why I have client and server, it's because I'm already testing
stuff, whoa, five minutes, okay, I have to go straight, so client basically is where
we put all the normal component, server is when you do LRC and so on, and not speak
about it, so component here we have the future section, so basically it's really, I take
this one, under the hood, it looks like really something that you should have written, okay,
the compilation is not perfect, but it's going really well, the good thing with that,
it's like, it gives you also an escape H under the hood, the escape H is the override system,
so if some part of your application, you need to have like component that's not completely
divided too complicated, you can override it, and how you do that, basically it just
follows the path here, and then you can say, on the compilation level, when you meet this
import, replace the file by this one, okay, and here for example, I do it for like headless
UI, okay, I say okay, when someone meet the headless disclosure, basically under the hood
it's switching to headless UI, and because headless UI is working both in a reacted view,
it works fine, okay, when I have that, I copy it completely automatically on my library
here, UI and next, and basically I just create a library, simple library, where the client
and I do an export, simple of that, this morrow I can take it and publish it on npm, it works,
okay, then that's, I take it, and then I use it in my application directly, thanks to nx,
I don't need to do like npm, blah blah blah, it's already hundered automatically, so to
give you an example on next.js, on the page here, I have like my application, so basically
I will introduce now the layer, so do you see here, we speak about the component, but
now we need a layer because everything is interconnected, so we need a layer to be able
to say okay, I have a layer in common where I can connect everything and handle it, this
layer is called uniform, okay, it's a tool that we use and we explore a lot with the
teams, so let me show you, so uniform, it's basically that, okay, it's kind of like a
visual editor that you can get, it starts completely with CMS, but it's way more powerful
than that, where we can connect a lot of stuff, so here basically I'm connecting my next application
directly with my component, I will show you in two minutes, and I'm also able to connect
directly the data coming from multiple source if I want, so here, okay, to show you like
the example, so here I have my sitemap, I have my what I call like FAQ mesh, it's just
an example, the FAQ mesh basically is connecting to, I hope it works, connecting to my CMS,
okay, and you can see here on the container level, I'm clicking on this one, basically
here you can see it provide me a component called loops that allow me to make reusable
stuff, and then it's okay, the first component is the template, okay, and the template I
can say, okay, I want to connect it to something, the title, the title is connected to something,
okay, this here what you see, it's a note from my API from Storyboard, okay, how I get
that, I move uniform, come with a lot of stuff, first thing that you provide you is a component
layer, okay, all the components that you saw basically are recreated here, so you can take
them, reuse them and use as building block like a CMS, then with the component you can
create what you call a composition, a composition is basically just aggregation of your component
or basically here I create pages, okay, and then you have a third system called the data
type, the data type is basically your injector, okay, do you see all this mess, so they provide
you a tool to be able to connect in one way, in a standard way, every system that you want,
here I will show you with my CMS, so basically here I'm configuring my CMS, and I can go
and say okay, I have multiple code, and the code is really simple, basically it's an
HTTP request, I can say what is the name, I can say where I want, I can create variable
that can be reused into the visual editor, and then here I can get that and connect everything,
so when you saw a lot two minutes ago what I'm using, it's basically a connection with
that, this it gives you like the full extent, completely, when you have full power, but
if you're lazy and sometimes you come with an integration, they have some integration,
one of them is you go here, they have all this integration already available, you just
plug and play, and they provide you into your system, you connect, you have access, you
put your credentials, and you're ready to go, like for example here, I set up Shopify,
blah blah blah, and I will remove stuff, but basically here, if I wanted I can connect
Shopify, then basically it provides me information so I can just reuse and pick for example my
product magically, automatically, and then I get one endpoint where I can get the data.
One last thing that I would like to speak, why this tool is also interesting, it's about
personalization and testing, so it's already built into the system, because it's the orchestration
layer, you don't need to add like, non-jokely next to it, because the handle already did
a bit of personalization for you, the handle already did a bit of testing for you, voilà.
Do you have a question?
Before the question, we'll say thank you.
Thank you.