Nuxt 3 Layers — The Key to Smarter Architecture (DDD) [Vaimo DevDays 2024 Meetup]

hi everyone thank you for attending my  current topic today is Nuxt 3 Layers I will   tell you some prehistory of this presentation I  will describe some alternative Solutions I will   tell you about underestimated feature of nox  3 and will explain to you a possible uh design   architecture with KNX uh framework development and  will tell you in the end all the advantages of my   solution so let's start with prehistory it could  be a scary story but maybe not so four or maybe   five years ago I created my own side portfolio  and it was like it started as a pet project as we   usually do I guess every developer wants to spend  some time to investigate something new so when I   started to learn uh react I decided to practice  with it and I built my portfolio and as a like   two developer I uh wanted to start uh to make  it over complicated I prepared three instances   uh like for storefront for API and for the admin  panel uh and I separate the development completely   for different repositor stories different domains  different everything it was fine but it's really   slow me uh because I needed a lot of time to  switch between them and start and build something   working like MVP stage in this year uh since  January I decided to start my another pet project   and I spent already uh more than 600 hours for  that I decided to make it easier at the beginning   like including all the uh issues and problems with  the previous uh my experience I decided to create   a monolit application because there is nothing  better than monolit application you know uh so I   have only like one end application But it includes  all the sides that I mentioned before like uh   architecture layers or areas uh on the store  Front I want to see only that information that   is not secure for all the like customer visitors  uh for admin panel I want to edit everything that   I need to show on starfront but next three prepare  API layer uh like as a server Handler that could   be strictly typed uh and help you to develop it  faster because uh when you fetch something in the   admin p on any component it doesn't matter admin  panel or storefront you always know which data   will come in uh because uh next generates types uh  in runtime as well and it's really easy to develop   so in this case I decided to uh start with this  simple monolit architecture because it's really   fast why not but as you know there's no silver  ballet always you have some issues and for example   in my uh previous uh experience I mentioned issu  that is just really slow and over complicated uh   but when you choose some eer development and  faster development you will see other sides of   issue and the first one is security issue it's  pretty simple to explain because uh usually you   know when we have end application uh you include  uh all the areas and size to the end application   like admin panel and storefront uh and we have  API as I mentioned it and API uh contains some   uh server handlers that could expect not only get  request but also uh post put delete and others uh   so it's nice in storefront to Fage some data  with get requests and it also nice uh for the   admin panel to uh also use get request but also uh  to um add some records to database with post and   put request but it's unexpected when storefront  also has access to uh post and put because uh is   insecure this is for first issue the second issue  is result bundle when you have only end uh one   n application you include everything in result  bundle like you have shared UI Library API end   points middle Wares components Pages models etc  etc a lot of stuff most part of that is necessary   only for the admin panel because admin panel  functionality is about 70% of the whole stuff   that you could write for the working application  so in this case uh I didn't want to make the   bundle really huge uh to load it on storefront  because I just didn't need it uh it also like   this issue s issue project n is related to the  previous issue result bundle because everything   that I mentioned uh is about one project structure  like one repository one uh one components shared   components between every stuff and it's really  difficult to navigate between a project even if   you separate everything by different directories  like between admin and storefront uh anyway uh   sometimes you need to edit something in both  directories in both areas and when you expand   everything that you need uh it's really difficult  to find something so we have three issue here and   how we can uh fix them existing solutions that  provided by uh KNX 3 uh security area the first   part uh we can solve everything just by middle  Wares it's understandable for every developers   like we have middle Wares for roting for accessing  and etc etc uh so we can uh write additional logic   to prevent post and post put request from the  storefront side yeah uh then result bundle we   can easily to fixed by lazy loading and next also  contains some uh built-in feature like when you   import some components by their name you can uh  easily to put uh prefix lazy uh for each import   and uh the component won't be included to result  bundle until it's necessary and project Mass uh we   could uh uh Handle by models because models could  be uh divided to different repositories different   directories and easily included as an npm  package but what could combine uh issues of these   Solutions more code and when we have more code  it's more complexity and more time to develop so   uh I I started to find another solution what could  help me I find out that in KNX 3 uh documentation   uh I saw underestimated feature and uh I need  to explain why underestimated underestimate   at because uh it's the only page that you could  find in uh KNX 3 documentation and that's it uh   if you uh already fac it uh N3 documentation you  know it's pretty um good uh because it contains   a lot of information useful information and it's  uh really structured and it's really nice but when   you open layers page you don't understand enough  from this page because it's really short without   enough um use cases uh explanation how to use  it and I just missed it each time I was uh on   KN documentation um domain maybe for around  30 maybe 40 hours uh this year and I never   joined this page I just missed it I don't know  why because it's really small uh so uh it's a   reason why I didn't start with this but when I  found out that I could Implement with layers it   really changed my mind and it's really GameChanger  for me so uh I started to design architecture with   new uh like new feature for me for example uh  we still have an application and we could have   different areas for example admin panel yeah and  it could be top level layer like as a separate   um application so layers is pretty close to uh  usual next um application with the same feature AO   impers this uh it's necessary to add more code to  implement it everything like Pages server handlers   etc etc um but without additional code like as  for models because layers it's the same nox3   application but the main difference it could be  included to another application so we could build   uh really difficult chain like uh step by step  uh and for example we have end application then   we include uh extend like another layer AS  application and this layer could also extend   different layers so uh this is just example  diagram but let's go next uh as I mentioned I   have two areas admin and storefront and what could  we build with layers we could start with the UI   Library uh and we could separate uh different UI  libraries per uh instance and for example I want   to have for admin panel only admin UI not to share  some uh components with store front uh and also I   want to have another layer storefront AI also if  I will have some component that has to be shared   I could make some like sharable uh UI uh between  admin and star font it could be like error alert   messages uh popups models uh buttons even it  depends on the design solution but in my case   I didn't need sharable UI so I decided to build  it separately so in this case we could uh have   end applications like admin and storefront and  in layers UI expected project structure we could   have admin UI and store font and then just uh in  a config TS uh include uh those directories as   to extend this application but let's go make it  more difficult to use it for real cases and for   example uh in my application I need e-commerce  functionality uh some functionality has to be   related to core functionality sharable uh for as  usual um layer but also I want to uh carefully   include b2c and B2B stuff because sometimes I  won't need it uh I could create a new directory   Commerce and inside I could create additional  directories like or b2c B2B uh it's expected but   uh some of them has to be shared only for admin  and storefront let's expand it deeper and in core   I could also have some like models uh ORD store  use payments and let's expand orders again and in   orders I could have like real layers uh real KNX  3 applications where I could write some um middle   Wares uh the database connection um create some  API and points and a lot of stuff that's related   to only uh to Ecommerce layer and only for orders  functionality and in this case when I have three   directories I could put only uh secure part to  admin uh directory and extend it in the end admin   application also could uh create the same for  storefront that has to be accessible only from   the stor front side and also this example with get  request I could uh create another directory shared   layer uh with some getting points or something  that could be shared between admin and storefront   application in the end uh so this is example uh  like simple example of usually that we met in   different applications uh but uh we could change  our mind to understand uh architecture with next   three layers because you don't need to prepare uh  different uh completely different applications uh   as microservices and in this case you don't need  to build only man application it's something like   middle probably it's even silver ballet as I  mentioned before uh because it allow us to make   it highly customizable uh monol application but  with um different instances like one instance for   admin as a separate uh application and another one  for store front uh so this is a short example how   we could extend uh next config TS is a basic file  that has to be uh appear in each KNX application   and in extance we could specify that we want to  include one layer for example admin UI for admin   application and for example e-commerce admin  and sharable stuff and under the hood it could   uh extend more applications for core functionality  for b2c functionality and B2B and by if statements   we could exclude some of them or include it  depends on our uh potential uh necessaries and for   example if we want to build with this stuff some s  Solutions or something uh we could prepare uh like   I describe it everything from technical point of  view but if I want to present it from the business   point of view uh I want to uh prepare a free plan  for customers for S solution and I expect that we   could build some I don't know maybe Academy  platform or something with courses workshops   and uh some educational materials so in this case  why uh we need uh a separate Ecommerce solution   because we need only virtual products yeah we  don't have any like shipments and other stuff that   usually we use for physical products but uh in our  case we need only virtual and for example courses   uh could be a virtual product with these layers  uh we could prepare a free plan uh where we could   include only like basic functionality like uh  we could all only one admin us user we could add   only one content languages language for example  English by default yeah and uh also we include   basic functionality courses but uh and we include  only necessary layers from the e-commerce like sh   directory but also I want to prepare like the next  level maybe paid stuff uh and I want to provide   more functionality like two content languages to  translate something I want to include workshops   blog function it customers orders discounts  coupons and payment methods I'm going through with   this uh visualization of possible plans uh I want  to include additional um stuff but I also thinking   about from business point of view I want to have  like an Enterprise plan but it doesn't need to   um to include all of this layers from e-commerce  stuff why because for example just imagine that we   have this platform in inside WMA and we have WMA  Academy platform uh but it doesn't need to have   like customers and orders because participants  don't need to pay for these courses because it's   shareed only inside V yeah right and in this case  I have to exclude from e-commerce uh layer uh all   the uh stuff that related to payments and orders  but I want to include another layer for example   C login to share only with uh why domain account  with Google suit this is uh just imaginable but   uh I wanted to explain why layers are flexible  AR about flexible architecture because you could   easily uh could easily exclude some layers but  include other ones and easily replace one solution   with another solution like you have integration  with uh one database in one layer but you want   easily to replace to another database yeah and  you could exclude one and extend another uh layer   uh to easily switch between them so uh shortly uh  advantages why I decided to uh keep it uh to keep   this architecture type because um every layer is  the same as usual kn3 layer it has Auto impers   auto types and all the stuff that you usually  use for nx3 application uh and uh each layer   could extend another layer and that layer could  also extend another the layer so we could build   a really long chain in this case and uh make a  complicated structure as we need additional stuff   that like layer is not replacing for modules it  it could be combined like we could install modules   per layer but if we uh disable some layers all the  modules won't be installed in the end application   as well uh and as I said we could easily swap  our integration with CMS Solutions uh mail server   marketing Services datab databases stor Services  Etc you could also separate uh these layers by   different repositories and even make them private  ones uh and KNX three allows you to install   some layers with specific token from GitHub as  example uh and for gitlab as well as I remember   it solves all the risks and security potential  issues that I mentioned before it also solves   myy project because you can easily separate by  different directories different repositories and   you can carfully extend layers that only you need  in the end application to uh reduce your bundle   size additional features that we have um in ax  config TS we could provide some configs uh and uh   it will be all merged uh in the end application  like if you have some specific config in one   layer then in another one all of them uh you will  have as a merged array object or something in the   result application for my opinion it's nox layers  are much better than nox modules because it's uh   it has everything out of the box and you don't  need to uh write additional stuff uh in comparison   with modules and as for me as I mention that why  I decided to stay stay on it uh so layers is uh a   perfect solution for me like architecture solution  uh to build some flexible application uh also   I prepared some useful links for you uh and you  could uh download my slides then and uh navigate   by this links but also you can uh scan uh this QR  code and um go it's just a GitHub repository with   the same links that I uh kept here so if uh I can  switch to the next slide uh This is the End slide   you can subscribe on me in GitHub and Linkedin  and after uh all we could go to a separate room   where you could ask everything that you uh want  about my pet project about KNX 3 architecture   and everything you have in mind so thank you  for attending thank you for listening George   your mic I have one question for you sir yeah sure  what Point did no introduce layers and what which   version do we um are we able to use that only nox  3 layers W appear in nox 2 and previous version   okay how how big of an effort is it I mean this is  a very V open question but how big of an effort it   is to migrate from next two to next three I didn't  have this uh like uh experience of upgrading   uh but I remember that KNX 2 and KNX 3 uh in the  project is pretty uh similar because in comparison   KNX one first KNX and KNX 2 uh they completely  different uh but anyway upgrading is always uh   about complicated things so it's not like just  upgrade a version and everything will be fine   so probably some adjustments uh have to be done  but uh I guess it's still possible the project   already the app the more difficult it usually is  to migrate yeah it's it's cool um cool to hear and   see about these different um architecture patterns  how to approach things the uh yeah same under the   react side there's multiple ways of doing same  thing yeah uh I recently uh work only with react   in my like Pet Project expertise or something uh  but when I uh joined team with uh VR project uh I   was interested in view what what's new we have  because I remember VI one and view2 wasn't so   good and I decided to check what uh view3 could  offer and it's really GameChanger to me even in   comparison with previous versions and even  in comparison with react because currently   uh even I uh knew uh react and didn't have any  experience with view uh view uh I I prefer better   uh so more uh and I started to prepare certain two  certifications I passed middle level then Senior   Level examinations yesterday I uh submitted next  exam and awaiting the result this ecosystem really   friendly for developers and is much better than  next and uh in additional I join it project with   nextjs and react and I do the same thing that  I have in pet projects uh mostly uh but it's   completely different and I can say that uh no is  really better than next uh especially with nox 3   layers feature because next doesn't provide this  one yeah it's it's really good for longterm growth   to to be able to see the the both sides of it yeah  yeah that's true to see the different patterns   that are being used in the end those those common  go if there's something cool in let's say view   side it usually ends up on the react side as well  in some form and the other way around that they   copy each other quite a bit over the long term  but uh yeah but I like uh uh view documentation   and N documentation because when you open it uh  in some pages you can find information like uh   yes we implemented some features like composes  and and you can M them in react called hooks but   we fix it uh this point this point and this point  and that's the reason why our solution is better   than in a react so they uh they confirm that they  have competitor like nextjs and react but also   they mentioned why their solution could be better  and I don't remember about disadvantages but it's   really nice to to have this comparison even in the  documentation so I agree I agree yeah I've always   likeed view um view side of things especially  because they they went with the mindset that   let's simplify things let's keep them um they the  monolithic approach they took with the very at the   very beginning with the architecture I really like  that and it has always bothered me that with react   you split things too much you over complicate  it yeah but at the same time we know that the   the the industry is is especially in our in our  area of the industry it's leading so heavily on   the react side that we also we're kind of forced  to go into that side as well but uh yeah it is   what it is yeah um I will I will lead you to to  discuss thank you for joining thanks yeah see you

2024-12-22 21:21

Other news