[00:00.000 --> 00:11.660]  All right, welcome everyone, we're going to go, yeah, it's four, so we did a kind of
[00:11.660 --> 00:15.220]  a dry run this morning and we realized that there's too much content, so we're going to
[00:15.220 --> 00:19.540]  have to, you know, skip, we're going to do the introduction, it's going to be very quick.
[00:19.540 --> 00:24.180]  So this is where we work, it's called Mirai, blah, blah, blah, connect to the website,
[00:24.180 --> 00:29.220]  you're going to see what we do, we do basically consultancy on a number of different clients
[00:29.220 --> 00:34.740]  on development, architecture, digitalization, so on and so forth.
[00:34.740 --> 00:40.700]  This is us, you can tell who's who, these are our Twitter handles and this is the Twitter
[00:40.700 --> 00:46.380]  handle of Mirai, if you like to talk or if you don't like to talk, just feel free to
[00:46.380 --> 00:49.860]  share on Twitter.
[00:49.860 --> 00:55.460]  What we're going to talk about today, so this is the result of a number of lessons learned
[00:55.460 --> 01:00.100]  that we had on a number of projects where we tried to solve a problem that we see coming
[01:00.100 --> 01:02.060]  up over and over again, okay?
[01:02.060 --> 01:09.100]  So it's just, we just took stock of the situation, we saw what was around, all the mistakes that
[01:09.100 --> 01:12.580]  we made and we kind of condensed it into a presentation that we're going to give to
[01:12.580 --> 01:17.700]  you, so this is by no means an idea of giving you best practices of any sort because there's
[01:17.700 --> 01:23.420]  a lot of context that goes behind these kind of problems, but it's just the way we are
[01:23.420 --> 01:27.700]  approaching the problem, the way we are analyzing the problem right now and the way we are
[01:27.700 --> 01:28.700]  approaching it.
[01:28.700 --> 01:33.140]  And we're going to talk about this idea of digital experience platform.
[01:33.140 --> 01:37.820]  You will see that like behind the name, there is a thing that you will know that is this
[01:37.820 --> 01:43.140]  idea that you start to have technical ecosystems that are more and more complex and these technical
[01:43.140 --> 01:47.660]  ecosystems are done by a number of systems that need to integrate together and they need
[01:47.660 --> 01:52.300]  to communicate together and they need to give back to the user in some form or another
[01:52.300 --> 01:59.100]  on one channel or another, a number of information, a number of capabilities and interaction.
[01:59.100 --> 02:02.500]  So that said, what is the state of the art?
[02:02.500 --> 02:06.660]  What is the thing that is the trendy thing right now?
[02:06.660 --> 02:13.940]  It's kind of synthesized, but this idea of the Mac kind of technologies, there's an
[02:13.940 --> 02:19.460]  organization behind it, you may know it about it or not, but it's this idea that the new
[02:19.460 --> 02:24.100]  architectures have kind of four major characteristics.
[02:24.100 --> 02:28.500]  They're based on microservices, we're not going to go into the debate of the microservice,
[02:28.500 --> 02:32.660]  what micro means and why do we need microservices or not.
[02:32.660 --> 02:35.820]  They're API first, they're cloud native and they're headless.
[02:35.820 --> 02:40.860]  We talked about headless, I think Alexandre talked about headless on material UI in the
[02:40.860 --> 02:42.020]  previous talk.
[02:42.020 --> 02:46.860]  I think that the two that you have to retain for this talk are these ones, that you have
[02:46.860 --> 02:51.580]  systems where you don't necessarily care how the information or how the capabilities
[02:51.580 --> 02:56.820]  are going to be exposed because it can be on a mobile app or it can be on a web application
[02:56.820 --> 03:02.100]  or it can be on a kiosk that you have on a store or on something else, you just don't
[03:02.100 --> 03:03.100]  care.
[03:03.100 --> 03:07.380]  The system is capable of giving you this kind of capabilities and data regardless of the
[03:07.380 --> 03:13.460]  channel that you use and how do they do that precisely by having an API first approach.
[03:13.460 --> 03:17.840]  So you don't have the interface, you have the capabilities, you can call any kind of
[03:17.840 --> 03:24.300]  HTTP REST service that is behind, the capabilities is there and then you take care of the visualization
[03:24.300 --> 03:29.300]  or the user interface or the user experience somewhere else.
[03:29.300 --> 03:30.740]  Am I going too fast?
[03:30.740 --> 03:31.740]  No?
[03:31.740 --> 03:32.740]  That's okay?
[03:32.740 --> 03:37.780]  All right, but there's a kind of a yes but a kind of situation.
[03:37.780 --> 03:40.300]  So let's see that you start from a simple website.
[03:40.300 --> 03:44.660]  So this is what happened most of the time, you have a relatively complicated kind of
[03:44.660 --> 03:49.420]  interaction website, you choose your framework, here you have React, you may have a number
[03:49.420 --> 03:55.340]  of others, we basically don't care, but that's kind of one of the possible starting point.
[03:55.340 --> 03:58.420]  And then you say, okay, but I would like to manage this content.
[03:58.420 --> 03:59.660]  So what do you do?
[03:59.660 --> 04:02.660]  You add a content management system.
[04:02.660 --> 04:03.660]  That is okay.
[04:03.660 --> 04:07.860]  You connect your content management system to your front end, off you go.
[04:07.860 --> 04:10.860]  Now you have a number of editors that can manage your content.
[04:10.860 --> 04:13.660]  All right, sounds good.
[04:13.660 --> 04:17.820]  Then you want to add some commerce because the company is doing good, they want to add
[04:17.820 --> 04:18.980]  commerce capabilities.
[04:18.980 --> 04:20.540]  Well, very good.
[04:20.540 --> 04:27.020]  You have a commerce engine that is headless API first, you can add your commerce engine
[04:27.020 --> 04:29.260]  and then you start to connect it to your front end.
[04:29.260 --> 04:35.460]  But you also have to connect it to your CMS because they need to share certain kind of
[04:35.460 --> 04:36.680]  data.
[04:36.680 --> 04:39.620]  And this is the situation that you have.
[04:39.620 --> 04:41.300]  And then you have a lot of products.
[04:41.300 --> 04:45.540]  So you start to have, you start to need a digital asset management because you need assets
[04:45.540 --> 04:50.700]  for your MOBA, you need assets for your kiosk, you need assets for the web.
[04:50.700 --> 04:55.260]  And you can't store them here because they're not made for this job.
[04:55.260 --> 04:59.100]  So they start to see a bit of their constraints.
[04:59.100 --> 05:02.820]  So you connect the dam and you connect it with the commerce, you connect it with the
[05:02.820 --> 05:08.100]  CMS, and then you connect it with your front end as well because it's the ultimate client.
[05:08.100 --> 05:12.700]  Okay, you kind of see where I'm going with this, right?
[05:12.700 --> 05:17.540]  Search, you start to have a huge catalog, you need to add search, you add Algolia or
[05:17.540 --> 05:21.740]  elastic search, we don't care, it's the same kind of concept behind.
[05:21.740 --> 05:25.580]  And then you connect Algolia and you need to connect it with your commerce layer, you
[05:25.580 --> 05:30.180]  need to connect it with your CMS, you need to connect it with your front end and off
[05:30.180 --> 05:32.060]  we go.
[05:32.060 --> 05:34.460]  Then you have a Netlify because why not?
[05:34.460 --> 05:37.660]  And then at some point somebody says, you know what, I would like to do some customer
[05:37.660 --> 05:42.340]  relationship management with the data that I have and then you start to add the CRM.
[05:42.340 --> 05:47.700]  And that's where you end up with the situation.
[05:47.700 --> 05:52.020]  Now if we remove all the capabilities that are provided by the system, which is a huge
[05:52.020 --> 05:57.460]  step forward because before you had to do all kinds of plumbing behind, you need to
[05:57.460 --> 06:02.620]  reconnect your user interface from the system behind, it was very tedious and very complicated.
[06:02.620 --> 06:08.980]  Now we have all those pieces of software that are capable of doing this by themselves,
[06:08.980 --> 06:11.700]  where you're basically left with this.
[06:11.700 --> 06:15.380]  And I was finding it funny what Alexander, I don't know if he's still here, was saying
[06:15.380 --> 06:20.740]  in the previous talk, I would say you go headless and you just remove the problem, where you
[06:20.740 --> 06:25.460]  would see that there's kind of a law of conservation of complexity, you just don't remove the problem,
[06:25.460 --> 06:31.260]  you just shift it somewhere else, you know, someone or something still need to take care
[06:31.260 --> 06:32.260]  of this.
[06:32.260 --> 06:35.860]  And then of course, because we're not stupid and we're a good intelligent developer, what
[06:35.860 --> 06:39.220]  we say is like, okay, this is not possible, we're going to create something that is going
[06:39.220 --> 06:43.220]  to aggregate this all together and we basically create a layer.
[06:43.220 --> 06:44.840]  But this complexity is still here.
[06:44.840 --> 06:49.700]  So you kind of have a tension between the fact of having these Lego blocks and the modularity
[06:49.700 --> 06:54.500]  and the fact that someone or something still needs to orchestrate all this kind of stuff.
[06:54.500 --> 07:01.540]  And it can get very, very messy and very, very complicated very, very quickly.
[07:01.540 --> 07:06.060]  All right, so this is the first problem, kind of big problem that we were trying to address.
[07:06.060 --> 07:11.340]  The second kind of problem is that if you take kind of a random e-commerce kind of interface,
[07:11.340 --> 07:16.300]  what we start to see more and more is that before it was just a matter of your CMS and
[07:16.300 --> 07:21.580]  your commerce, you had the catalog and the basket, these were coming from the commerce
[07:21.580 --> 07:25.100]  system and then your content was coming from the CMS.
[07:25.100 --> 07:29.540]  What you start to see right now is that if you take all the blocks that compose, let's
[07:29.540 --> 07:36.940]  say, a fashion e-commerce, in the same blocks, you have pieces of data that come from different
[07:36.940 --> 07:41.700]  systems and you need to aggregate those and you need to present them as if they were a
[07:41.700 --> 07:44.700]  unit because that's what the user cares about.
[07:44.700 --> 07:48.420]  I need to have a catalog and the catalog is normally coming from the search because the
[07:48.420 --> 07:52.980]  search is optimized so you don't ask it to the CMS and you don't ask it to the commerce
[07:52.980 --> 07:56.260]  because you want to do all sorts of categorization and classification.
[07:56.260 --> 08:01.340]  But then you don't show the IDs of the catalog, you show the product and the product comes
[08:01.340 --> 08:06.380]  from the image from the dam, some content from the CMS and the SKUs from the commerce
[08:06.380 --> 08:07.380]  system.
[08:07.380 --> 08:12.380]  So, again, you see where we're going with this, it can get very complicated very quickly.
[08:12.380 --> 08:16.860]  And the problem for us as developers behind is that every time that you need to change
[08:16.860 --> 08:23.540]  something here, you need to make sure that everything stays coherent and consistent behind
[08:23.540 --> 08:24.660]  the scenes.
[08:24.660 --> 08:28.060]  And again, this can get very tedious very quickly.
[08:28.060 --> 08:34.340]  So, I hope what I said kind of made sense as an introduction for the context.
[08:34.340 --> 08:37.420]  You raise your hand if that was not the case, okay?
[08:37.420 --> 08:39.900]  Everything is clear?
[08:39.900 --> 08:40.900]  Sounds good.
[08:40.900 --> 08:41.900]  I was getting scared.
[08:41.900 --> 08:42.900]  Okay.
[08:42.900 --> 08:43.900]  So, we have the problem.
[08:43.900 --> 08:45.420]  Now what?
[08:45.420 --> 08:49.180]  And that's where I handed over to Bouba that is going to show you what is the situation
[08:49.180 --> 08:51.340]  that we're applying right now.
[08:51.340 --> 08:55.420]  So, fully disclaimer, it's an approach that I'm showing you.
[08:55.420 --> 09:02.940]  It's not silver bullet, it's an exploration, so be with us, it's not perfect, and just
[09:02.940 --> 09:07.380]  trying stuff and trying to see where we can solve this problem if something.
[09:07.380 --> 09:12.020]  So, first thing that I'm asking you is, you tell me which framework I'm using.
[09:12.020 --> 09:19.420]  So basically, I'm running on 4,200 and 4,201, and if you look at the two websites, okay,
[09:19.420 --> 09:23.460]  we are in JavaScript, I have to make a joke about CSS, I'm really bad at CSS, CSS is
[09:23.460 --> 09:27.340]  a dark magic for me, so that's the reason why I don't bother with the logo, it's normal,
[09:27.340 --> 09:28.340]  it's okay.
[09:28.340 --> 09:30.060]  Just focus on the product here.
[09:30.060 --> 09:36.780]  Could you tell me on right or left, depending where you are, who is build with next and
[09:36.780 --> 09:51.380]  the other one is build with next, no, okay, so let's see on how we, here, so I will just
[09:51.380 --> 10:01.860]  open it, so if I do an inspect, if I scroll a bit, so one of them is based on next, okay,
[10:01.860 --> 10:12.700]  the second one is based on, because voila, next, okay, so you will say like, why I'm
[10:12.700 --> 10:20.420]  asking that, like, okay, so if I tell you like, these two pages use the same base has
[10:20.420 --> 10:26.860]  code, okay, and I just compile it, and then I get a component that works for React, that
[10:26.860 --> 10:34.860]  works for view, and it's not a component, okay, so do you know a tool that can do that?
[10:34.860 --> 10:42.300]  Nobody, okay, so I try, okay, so let's go.
[10:42.300 --> 10:46.780]  So for this tool, I will be speaking about some tools that we are using to orchestrate
[10:46.780 --> 10:51.220]  everything, so the first one is NX, so if you don't know NX, it's kind of like a tool
[10:51.220 --> 10:59.740]  that you can use to handle all your monorepo, okay, it's a really good tool because I don't
[10:59.740 --> 11:04.300]  want to set up webpack guys, or anything else, so I use this kind of tool to handle all
[11:04.300 --> 11:09.140]  the configuration, just handling webpack, handling, side press, story block, everything,
[11:09.140 --> 11:13.180]  it's handled by this tooling, okay, I just use that again, and then give you a good
[11:13.180 --> 11:19.700]  basic when you work with your team, and really good standard, okay, second tool that we will
[11:19.700 --> 11:25.420]  be showcasing is MetaZis, MetaZis will be the basic of how we build a component, like
[11:25.420 --> 11:30.060]  I said, it's an exploration, it doesn't solve everything, it's just a base, and we are trying
[11:30.060 --> 11:37.860]  to explore, so if someone knew something about MetaZis, did you hear about it, no, okay,
[11:37.860 --> 11:41.860]  so give you some context, so MetaZis is a kind of like a compiler, component compiler
[11:41.860 --> 11:47.940]  created by the Build.io team, so Build.io, they build kind of like a CMS that completely,
[11:47.940 --> 11:53.340]  I will say visual CMS, where basically they have a lot of SDK, they would like to support
[11:53.340 --> 11:58.900]  all the framework that we have in JavaScript, so it's a lot of frameworks, so they hire
[11:58.900 --> 12:02.220]  multiple people, and then they're like, okay guys, you're hiring too many people, okay,
[12:02.220 --> 12:05.980]  maybe you should find a way to be able to handle all this complexity, so they begin
[12:05.980 --> 12:13.060]  to create a compiler for components, so they use a common layer, like JSX, and then base
[12:13.060 --> 12:18.980]  with this common layer, they compile it to, natively, to React, Vue, Svald, or like all
[12:18.980 --> 12:24.060]  bunch of stuff, okay, basically they take the approach of LLVM, so if you don't know
[12:24.060 --> 12:28.420]  about it, they take the same approach, having a common layer where we can target, and then
[12:28.420 --> 12:33.940]  all the architecture can file for that, so we'll be using that, frankly speaking, it's
[12:33.940 --> 12:38.260]  not perfect, it's really at the beginning, what's really nice with that, they're really
[12:38.260 --> 12:42.820]  pushing the boundary of that, because all the SDK, so if you use Build.io, basically
[12:42.820 --> 12:47.700]  you're using me to this under the hood, so they use that to build all the SDK for the
[12:47.700 --> 12:51.180]  visual editor, like everything that you're using for React, Vue, it's based on that,
[12:51.180 --> 12:56.820]  so it's not perfect yet, it's improving every time, but it gives you really kind of like
[12:56.820 --> 13:01.420]  a good code, I will not say it's perfect, a human will be better, yeah, but at the end
[13:01.420 --> 13:06.740]  you win time and energy, because you write once, and you build everywhere, okay, it's
[13:06.740 --> 13:11.860]  a dream like since like 20 years, I know, but voila, every time, every 10 years we try
[13:11.860 --> 13:18.540]  to do it again and fail, maybe, but voila, someone try, okay, so basically if you take
[13:18.540 --> 13:23.700]  back what Maurizio said, we are going on the headless, so our goal is really to reduce
[13:23.700 --> 13:27.340]  the friction, so we have multiple frameworks, it's really difficult to go on client and
[13:27.340 --> 13:33.060]  say, hey, you use React, you use Vue, you use Angular, okay, and every time we're building
[13:33.060 --> 13:37.260]  the button, we're building the same thing, so trying to find like a common layer and
[13:37.260 --> 13:41.940]  using me to this, we can really focus on what I said most of the time, the presentation
[13:41.940 --> 13:46.660]  component, I'm not mean like for really big component with charts, it's not mean for that,
[13:46.660 --> 13:50.820]  and don't try to do it, you'll be it early, and you will hate it, and you'll be like this
[13:50.820 --> 13:55.700]  is shit, okay, it's really for, I will say common component that you will have, that
[13:55.700 --> 14:02.420]  will be really simple, mostly UI based, not too complex, but kind of complex for some
[14:02.420 --> 14:08.140]  stuff, so you can really reuse, basically if you're on React, the presentation component,
[14:08.140 --> 14:13.220]  so we shouldn't say it anymore, since Dan said it's bad, but voilà, use the term, okay,
[14:13.220 --> 14:19.380]  so I will show you how we did it, and what we have built, all the advantage issue that
[14:19.380 --> 14:28.580]  I got about it, so I'm using upstone, okay, and basically here on the left side, you can
[14:28.580 --> 14:35.100]  see I'm using, it's just a standard, which application on Enix, so you have the app folder,
[14:35.100 --> 14:40.500]  the lips, and then all bunch of stuff that you have every time on every stuff, okay,
[14:40.500 --> 14:44.460]  the lips contain all the kind of library, what's cool if Enix, so you don't need to
[14:44.460 --> 14:48.500]  publish it, so you can really put it on the more repo, it handle all the configuration,
[14:48.500 --> 14:53.780]  so when you import it in a React, it's basically use a test path on the hood and make the magic
[14:53.780 --> 14:59.660]  on the web pack, it just works, okay, it's kind of like.magic, but it's not too complicated
[14:59.660 --> 15:05.980]  on the hood, it's just test path and bringing it in port into the web pack, or vids, okay,
[15:05.980 --> 15:12.780]  so basically we create a library, a core library, okay, using metosis, okay, so if you open
[15:12.780 --> 15:16.860]  here, you can see I have a core library, this is the metosis, what I call a core, because
[15:16.860 --> 15:21.860]  it's the basic for everything, all the components we are using, okay, then I create a subfolder
[15:21.860 --> 15:28.500]  called the UI, UI will be like all my target that I'm pushing for people, okay, so I have
[15:28.500 --> 15:35.860]  the UI for React, okay, and I have UI for view, okay, so let's first focus on the core,
[15:35.860 --> 15:42.620]  so on the core I have like a metosis config, so basically it's a configuration layer where
[15:42.620 --> 15:47.660]  I basically set up how I want to target and how I want to compile everything, so you can
[15:47.660 --> 15:52.260]  see it's a bit messy, because like I said, it's not perfect, perfect completely, you
[15:52.260 --> 16:01.580]  have some edgek's, but behind it's just basically a config that you put and you say, okay, let's
[16:01.580 --> 16:06.100]  me scroll, you put where you put your file, where you put the right, really important,
[16:06.100 --> 16:10.260]  I will explain it after, and then the targets we would like to do, it gives you also some
[16:10.260 --> 16:15.460]  edgek's, like for example, you can set up if you want to compile the TypeScript, want to
[16:15.460 --> 16:21.740]  run pressure already handling, like for example, how you want to handle a strict act, and have
[16:21.740 --> 16:26.620]  like kind of like plug-in system, basically it helps you to hook into the system like
[16:26.620 --> 16:31.300]  when you compile, okay, it's really basic, it's not like a big compile, it's just basic,
[16:31.300 --> 16:37.780]  but it's already to fix some stuff that's not perfect, okay, like if I go a bit here,
[16:37.780 --> 16:42.300]  like Ragnative, QIP, Swalt, like Swalt, you can see here like, holy shit, what this guy
[16:42.300 --> 16:47.500]  is doing, like basically it's replacing stuff under the hood and patching stuff, yeah, sometimes
[16:47.500 --> 16:52.180]  you have to do it, but voila, it's just like to give you like the extent where we can go,
[16:52.180 --> 16:55.300]  most of the time you don't need that, this is really like edgek's for them, but you
[16:55.300 --> 17:01.260]  have already code, okay, so then you have the SRC, the SRC basically is just where we
[17:01.260 --> 17:06.780]  put all the code, so I will focus mostly on the component, so the convention is really
[17:06.780 --> 17:13.540]  straight forward, it's just you create a component basically with.ly.t6, it's the convention
[17:13.540 --> 17:18.660]  that will be every time pick automatically by the compiler and then we compile it to
[17:18.660 --> 17:23.300]  view or react, okay, so basically here I'm just taking a simple component, this one
[17:23.300 --> 17:29.620]  it's more tricky, I will open another one, I will say easier, not this one because this
[17:29.620 --> 17:35.900]  one is hollow, let's take this one, okay, so here basically just under the hood it's
[17:35.900 --> 17:41.260]  using like kind of like a.ly.t6, but a more.ly.t6 contraint, so if you know solid.ly.t6,
[17:41.260 --> 17:50.660]  you already play with it, not you, basically solid, it's kind of like a react, what Red
[17:50.660 --> 17:57.340]  should have been if they write it now, and basically to use like really a contraint.ly.t6
[17:57.340 --> 18:04.460]  system to make it more performant, and basically they kind of copy some stuff from solid, like
[18:04.460 --> 18:10.300]  for example if you want to do a maps, you don't do a maps, like in React like it's just
[18:10.300 --> 18:16.780]  JavaScript, yeah okay, we know it's just JavaScript, but here you have to use the four component,
[18:16.780 --> 18:22.740]  why it's because it makes easier for the compilation basically to be able to say okay, if I'm using
[18:22.740 --> 18:29.940]  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,
[18:29.940 --> 18:32.580]  so this reason why they create these contraints is to make the compilation easier, if not
[18:32.580 --> 18:37.700]  they have to play with the AST, so abstract the AST, abstract syntax tree, and just make
[18:37.700 --> 18:42.460]  the complexity increase, so try to make it simpler, okay, and then they come with some
[18:42.460 --> 18:47.980]  common ground, like for example you store, it's just kind of like a hook, basically this
[18:47.980 --> 18:53.620]  will be compiled to a use state or some similar in view, okay, so they give you some rules
[18:53.620 --> 18:57.820]  that you have to respect, it's really strict, it's not easy at the beginning, and that's
[18:57.820 --> 19:02.660]  make the complexity of using this kind of tool, because you have to really think like,
[19:02.660 --> 19:07.180]  when I say if I'm working in Java before, like in interface development way, okay, what
[19:07.180 --> 19:12.980]  I mean by that is you have to think about the common ground between all the component
[19:12.980 --> 19:17.580]  and all the frameworks, you cannot just say hey, I will write it like that, and basically
[19:17.580 --> 19:22.020]  this does not exist another component, okay, or it's not compatible, okay, you have some
[19:22.020 --> 19:26.100]  degree of flexibility, but it's not every time the case, okay, so you have to find really
[19:26.100 --> 19:32.460]  the common ground, try and do it, but accept that, it's kind of like a just react, okay,
[19:32.460 --> 19:37.180]  with some stuff, okay, so basically you get this component, and it will be compiled, and
[19:37.180 --> 19:41.860]  you can see it on the output folder here, it will be compiled automatically on react,
[19:41.860 --> 19:47.140]  so if I take the, here, why I have client and server, it's because I'm already testing
[19:47.140 --> 19:54.500]  stuff, whoa, five minutes, okay, I have to go straight, so client basically is where
[19:54.500 --> 19:59.060]  we put all the normal component, server is when you do LRC and so on, and not speak
[19:59.060 --> 20:04.860]  about it, so component here we have the future section, so basically it's really, I take
[20:04.860 --> 20:09.620]  this one, under the hood, it looks like really something that you should have written, okay,
[20:09.620 --> 20:14.700]  the compilation is not perfect, but it's going really well, the good thing with that,
[20:14.700 --> 20:19.420]  it's like, it gives you also an escape H under the hood, the escape H is the override system,
[20:19.420 --> 20:23.900]  so if some part of your application, you need to have like component that's not completely
[20:23.900 --> 20:28.060]  divided too complicated, you can override it, and how you do that, basically it just
[20:28.060 --> 20:32.940]  follows the path here, and then you can say, on the compilation level, when you meet this
[20:32.940 --> 20:39.060]  import, replace the file by this one, okay, and here for example, I do it for like headless
[20:39.060 --> 20:43.540]  UI, okay, I say okay, when someone meet the headless disclosure, basically under the hood
[20:43.540 --> 20:49.180]  it's switching to headless UI, and because headless UI is working both in a reacted view,
[20:49.180 --> 20:54.380]  it works fine, okay, when I have that, I copy it completely automatically on my library
[20:54.380 --> 21:02.020]  here, UI and next, and basically I just create a library, simple library, where the client
[21:02.020 --> 21:07.460]  and I do an export, simple of that, this morrow I can take it and publish it on npm, it works,
[21:07.460 --> 21:14.100]  okay, then that's, I take it, and then I use it in my application directly, thanks to nx,
[21:14.100 --> 21:17.820]  I don't need to do like npm, blah blah blah, it's already hundered automatically, so to
[21:17.820 --> 21:25.700]  give you an example on next.js, on the page here, I have like my application, so basically
[21:25.700 --> 21:30.700]  I will introduce now the layer, so do you see here, we speak about the component, but
[21:30.700 --> 21:34.180]  now we need a layer because everything is interconnected, so we need a layer to be able
[21:34.180 --> 21:38.620]  to say okay, I have a layer in common where I can connect everything and handle it, this
[21:38.620 --> 21:43.660]  layer is called uniform, okay, it's a tool that we use and we explore a lot with the
[21:43.660 --> 21:51.500]  teams, so let me show you, so uniform, it's basically that, okay, it's kind of like a
[21:51.500 --> 21:56.540]  visual editor that you can get, it starts completely with CMS, but it's way more powerful
[21:56.540 --> 22:01.340]  than that, where we can connect a lot of stuff, so here basically I'm connecting my next application
[22:01.340 --> 22:07.100]  directly with my component, I will show you in two minutes, and I'm also able to connect
[22:07.100 --> 22:13.180]  directly the data coming from multiple source if I want, so here, okay, to show you like
[22:13.180 --> 22:20.700]  the example, so here I have my sitemap, I have my what I call like FAQ mesh, it's just
[22:20.700 --> 22:27.420]  an example, the FAQ mesh basically is connecting to, I hope it works, connecting to my CMS,
[22:27.420 --> 22:33.540]  okay, and you can see here on the container level, I'm clicking on this one, basically
[22:33.540 --> 22:37.860]  here you can see it provide me a component called loops that allow me to make reusable
[22:37.860 --> 22:43.660]  stuff, and then it's okay, the first component is the template, okay, and the template I
[22:43.660 --> 22:51.580]  can say, okay, I want to connect it to something, the title, the title is connected to something,
[22:51.580 --> 22:58.580]  okay, this here what you see, it's a note from my API from Storyboard, okay, how I get
[22:58.580 --> 23:08.060]  that, I move uniform, come with a lot of stuff, first thing that you provide you is a component
[23:08.060 --> 23:13.820]  layer, okay, all the components that you saw basically are recreated here, so you can take
[23:13.820 --> 23:18.380]  them, reuse them and use as building block like a CMS, then with the component you can
[23:18.380 --> 23:23.860]  create what you call a composition, a composition is basically just aggregation of your component
[23:23.860 --> 23:29.020]  or basically here I create pages, okay, and then you have a third system called the data
[23:29.020 --> 23:34.180]  type, the data type is basically your injector, okay, do you see all this mess, so they provide
[23:34.180 --> 23:40.220]  you a tool to be able to connect in one way, in a standard way, every system that you want,
[23:40.220 --> 23:47.100]  here I will show you with my CMS, so basically here I'm configuring my CMS, and I can go
[23:47.100 --> 23:52.100]  and say okay, I have multiple code, and the code is really simple, basically it's an
[23:52.100 --> 23:57.780]  HTTP request, I can say what is the name, I can say where I want, I can create variable
[23:57.780 --> 24:04.660]  that can be reused into the visual editor, and then here I can get that and connect everything,
[24:04.660 --> 24:09.460]  so when you saw a lot two minutes ago what I'm using, it's basically a connection with
[24:09.460 --> 24:14.900]  that, this it gives you like the full extent, completely, when you have full power, but
[24:14.900 --> 24:19.780]  if you're lazy and sometimes you come with an integration, they have some integration,
[24:19.780 --> 24:26.060]  one of them is you go here, they have all this integration already available, you just
[24:26.060 --> 24:31.020]  plug and play, and they provide you into your system, you connect, you have access, you
[24:31.020 --> 24:36.260]  put your credentials, and you're ready to go, like for example here, I set up Shopify,
[24:36.260 --> 24:41.300]  blah blah blah, and I will remove stuff, but basically here, if I wanted I can connect
[24:41.300 --> 24:47.780]  Shopify, then basically it provides me information so I can just reuse and pick for example my
[24:47.780 --> 24:54.420]  product magically, automatically, and then I get one endpoint where I can get the data.
[24:54.420 --> 24:59.660]  One last thing that I would like to speak, why this tool is also interesting, it's about
[24:59.660 --> 25:04.180]  personalization and testing, so it's already built into the system, because it's the orchestration
[25:04.180 --> 25:09.620]  layer, you don't need to add like, non-jokely next to it, because the handle already did
[25:09.620 --> 25:18.420]  a bit of personalization for you, the handle already did a bit of testing for you, voilà.
[25:18.420 --> 25:25.620]  Do you have a question?
[25:25.620 --> 25:31.620]  Before the question, we'll say thank you.
[25:31.620 --> 25:41.620]  Thank you.