Ngobrolin MicroFrontend - Ngobrolin WEB

3:16Bandung apa Jakarta ya?

3:18Jakarta sepertinya ya.

3:20Saya dapat invitation-nya untuk jadi, karena tulisannya di e-mail, karena jadi kontribusi di Open Source dapat gratis.

3:31Jadi saya udah klik linknya, eh gratis, tapi belum daftar. Jadi karena ada Mas Irfan sana, saya coba usahakan datang, iya.

3:40Lagi ini, akhir-akhir ini lagi ngulik apa sama Mas Irfan?

3:44Kemarin baru banget nyoba yang Svelte 5 tuh. Svelte 5, mengalaminya. Migrasinya cepet banget, enggak.

3:54Migrasinya gampang?

3:55Cepet banget, cepet banget. Karena udah ada code mod-nya gitu. Terus ada beberapa yang nggak berhasil di-migrate kan.

4:05Itu pun sebenarnya cukup straightforward gitu dokumentasinya. Jadi kayak nggak sampai sejam itu migrasi dari versi 4 ke 5, cepet-cepet banget.

4:14Nggak seperti kelasan sebelah ya kalau dari React 17, ke-18, gimana ceritanya.

4:22Project-nya gede apa enggak. Project-nya gede apa enggak dulu. Kalau project kecil mah, harusnya juga nggak sampai sejam kan.

4:33Soalnya yang Mas Rizet tuh kan pakenya baju depth circle, jadi harus ngebelain dikit lah.

4:38Tapi saya juga baru tahu, kemarin beberapa waktu yang lalu kan banyak yang pindah tuh dari X-Twitter ke Blue Sky kan.

4:56Terus di situ kan dan Abramov kan sekarang kerjanya di Blue Sky. Saya baru tahu ternyata dia udah nggak kontribusi ke React lagi.

5:05Jadi aja sebagai pengguna aja, sebagai yang pake. Udah nggak terlalu aktif lagi.

5:10- Nggak dibayar. - Udah sempat jadi kayak ini ya.

5:13- Nggak dibayar lagi. Udah nggak dibayar Facebook lagi. - Bosan kali.

5:18- Sempat jadi kayak ininya top person gitu loh, kayak mukanya React gitu. - Iya betul. Udah jadi mascot lah ya.

5:25Udah jadi mascotnya React kan. Banyak yang jadikan dia panutan juga kan di dunia React. Terus tiba-tiba hilang.

5:32Twitternya juga udah nggak aktif dimatiin. Ternyata dia pindahnya ke Blue Sky.

5:37Oke, anyway malam hari ini kita akan bicara tentang Microfront N dan pas banget di sini ada Mas Irfan yang mungkin sudah pengalaman cukup banyak.

5:48Eh nggak, pengalaman cukup lama. Pernah gitu ya. Pernah mengalami dan di kantor sekarang pakai juga.

5:57- Nggak, di kantor sekarang nggak? - Nggak, nggak ada di kantor sekarang. Nggak. Tapi ada pengalaman lah ya ke arah sana.

6:04Jadi bisa kita tanya-tanya ini gitu. Tapi sebelum itu mungkin kita lihat dulu ya. Sebenarnya Microfront N itu apa sih?

6:13Nah, ini ada artikel dari tim engineering-nya Peppol. Tapi sebenarnya orang Indonesia, Mas Bimo.

6:24Di sini dijelaskan tentang Microfront N itu istilahnya itu mulai dari 2016 ya.

6:36Mulai dari 2016. Terus kurang lebih Microfront N itu adalah ekifalentnya microservice lah kalau di back-end ya.

6:47Kalau di back-end microservice, kalau di front-end jadi micro. Front-end jadinya.

6:54Jadi ada service-service kecil yang sengaja dikotong-kotong supaya bisa dikerjain oleh banyak tim. Eh iya.

7:05Tim A, Tim B, Tim C, dan seterusnya ya. Ini juga dilakukan sama Spotify kalau nggak salah.

7:11Jadi misalkan ada search team, ada playlist team, ada recommendation team, ada macem-macem ya.

7:18Jadi kurang lebih kayak gitu. Kalau misalkan kita lihat contohnya di sini, di dashboard-nya Peppol.

7:26Yang hijau ini ada tim sendiri. Tim dashboard, ada tim header. Header-nya aja ada tim ya. Tim sendiri ya.

7:35Terus ada quick links, ada activation, ada semua tuh yang dikotong-kotong ini. Ini adalah satu tim terpisah.

7:42Jadi satu page itu bisa ada 1, 2, 3, 4, 5, 5 tim yang megang.

7:48Itu memungkinkan karena micro front-end ini. Kalau nggak, mungkin harus satu orang, satu page atau satu service, satu team kali ya. Karena ada birokrasi.

8:06Sebenarnya micro front-end ini, perlunya apa, kebutuhannya kapan dipakainya, dan kenapa. Mas Irvan bisa kasih jawaban nggak ya kira-kira?

8:22Ya seperti yang digambar tadi ya, sebenarnya kenapa datangnya dia, ya karena bentuk tim-nya biasanya begitu. Tim-nya memang dipecah-pecah berdasarkan domain business-nya misalnya.

8:36Yang tim A sama tim B, itu biasanya back-end-nya masing-masing. Nah makanya karena tim back-end-nya masing-masing, biasanya tim front-end-nya kan juga nempel ke tim back-end-nya tuh.

8:46Misalnya ada tadi tim yang katakanlah yang ditanah tuh tim core-nya gitu ya yang ngurusin header, kadang-kadang dipakai sama banyak tim lain ya.

8:56Katakan tadi ada tim balance-nya yang ngurusin balance, itu biasanya back-end-nya di situ, front-end-nya di situ nempelnya ke tim balance.

9:04Jadi secara scope of work, biasanya nggak saling bersinggungan antara tim itu, nggak direct bersinggungan jadi.

9:12Karena bentuk tim-nya begitu, pingin-nya itu deployment-nya juga masing-masing gitu. Jadi ketika tim balance deploy, pingin-nya ya udah deploy aja.

9:23Nggak usah nungguin misalnya ada changes dari tim lain, tungguin nih kita deploy-nya bareng-bareng gitu. Nggak begitu, pingin-nya kayak independent.

9:31Micro-service di back-end-kan begitu juga ya, ketika tim balance misalnya mau deploy ya deploy aja. Karena tuh nanti akan ada front-end yang menge-orchestra semua API tersebut kan.

9:43Ya, micro-front-end secara komposisi tim memang ngarahnya ke sana gitu. Yang tim-nya tuh dipecahper domain bisnis gitu.

9:53Jadi kalau tim-nya baru satu, misalnya satu tim, pingin larinya ke micro-front-end, sepertinya sih overkill ya, karena harus deployment-nya kemungkinan jadi banyak kan.

10:05Itu makes sense kalau tim-nya memang bentuknya begitu. Kayak tim balance silahkan deploy sendiri, tim yang ngurusin header silahkan deploy sendiri, nggak usah.

10:14Jadi masing-masing ngehendal, maksudnya kalau deploy itu maksudnya sampai deploy komponennya, tuh nanti ada lagi tim yang meintegrasikan itu semua nggak sih?

10:26Kayak the main app-nya gitu, atau nggak?

10:30Biasanya ya, ada core app-nya gitu lah. Kalau kayak di contohnya PayPal kan tadi kemungkinan header-nya ya.

10:37Header-nya akan mengorkestra, at least dia yang punya ini lah, cerebral code-nya gitu. Let's say usernya tuh adanya di header.

10:45Jadi nanti tim balance ya consume usernya dari header-nya gitu. Ada yang di-share, tapi biasanya salah satu yang pingin di-achieve adalah independent deployment-nya.

10:58Biasanya sih ya, naranya kesana. Tapi kalau ngobrolin link yang tak asih mengenai Versal itu, different bus.

11:10Oke, oke, oke. Nah sebelum kita lanjut nih, seru banget nih Pak. Kebetulan malam ini kita kedatangan banyak narasumber.

11:18Kalau Mas Irfan kan dikenal dulu sempat berkiprah di Toko Ijo, narasumber kita yang ini di Toko Orange.

11:29Iya, di Toko Orange.

11:32Siang minggu lalu udah jadi narasumber juga. Dia pengen muncul lagi, pengen ngobrol lagi malam ini. Jadi please welcome Lihao.

11:42Where is Lihao? Where am I? Where are you? Oh there you are.

11:52Welcome, welcome again. Thank you for coming.

11:56Thanks for inviting for me.

12:00No worries.

12:03Please meet.

12:06Good, good. How's everything on your side?

12:14I'm using sunglasses right now. If you're wondering why I have an eye infection on both eyes.

12:25So behind these glasses is very weird looking eyes. Since this is live, I need to use sunglasses.

12:35Okay, cool. Hope you get well soon.

12:39Thank you.

12:41So Lihao, we just talked about why we need microphone and can you give us some thoughts about that?

12:55The pros, the pros why we need to use microphone and probably have opinion because you're using microphone in your job.

13:05Okay, so I think first of all is that why there's this idea of micro front-end, right?

13:13So in my opinion, it starts with maybe 10 years ago or maybe 15 years ago.

13:22So before, long ago I think when we are, all of us when we are very young, the web is not very front-end heavy, right?

13:32The page where you write in PHP or you write in any like Java or anything.

13:41I think what happens is that whenever you visit a page, that page is rendered from the server and then you receive the HTML and then you get to a page.

13:51And when you try to move around, when trying to interact with the page, it will navigate to another page where you get the entire page rendered fully from the server, right?

14:02And at that point, the web is a very simple application, right?

14:08You have like probably simple UI and you even like you have a lot of teams that working on it.

14:15Most of them your front-end is very simple and lightweight. So all this change when we started have more and more complicated web application.

14:27And also powered by more modern web frameworks like React and Vue and all this where we start to build applications that can do more on the front-end.

14:38And even we can do handle like navigations around the pages where you can navigate between multiple pages without actually make another request to the server to get a new HTML, right?

14:53You have SPA, exactly. We have SPAs, right? So with SPA, now we are thinking like actually, you know, if you go to one website, one application, all the pages should be within the same application, right?

15:11So say just, for example, like Shopee, if we think about Shopee has to be an SPA, then from the home page, the product page, the shop page, the checkout, the cards, the checkout, the order, the user login, all is within one same page, right?

15:27One application, right? So it's SPA. And with SPA, it seems like a lot of you're going to have a huge application like covering from all sorts of pages.

15:38And to build that application, it's going to be slow and very hard to maintain if everyone comes together and work on that application together, right?

15:51And we learned that as well, and we learned this experience in the backend as well, right? When you have a backend service that is monolith that does everything from login to checkouts to basic CRUD to a more complex logic, if everything is in one application, it will be very slow if you want to deploy it and also you can't scale it easily.

16:14You know, maybe you know that certain features needs to be high, like people use it more, then maybe you want to scale it up more, but you don't want to scale everything.

16:25So like because not all features are the same within the entire application, it's very hard to maintain. So you split a monolith backend to micro services.

16:37And I think that's the same idea where you split SPA into a micro frontend, right? So from this point of view, you can see that the pros is when you have a monolith that is huge, that is very hard to maintain, that is maintained by a lot of people.

16:58And it's getting harder to coordinate across different people, then maybe it would be much easier if you split it into smaller application, a smaller like split into micro frontends where each team maintains individual components or pages or like depends on how you want to split, right?

17:20We haven't talked about how you actually can split your application, but you can split it into different micro frontends that you have teams to, different teams to maintain it, right?

17:30So the key is that you have, if you have a lot of people maintaining one monolith, micro frontend will be good to, allows you to split them into smaller application, right?

17:43And so that's like in a team size, then also in terms of building, building one application is too slow, then building multiple micro finance individually, like you haven't built and deploy only those applications, those micro finance that needs like change frequently, then maybe it's faster to build that way.

18:05So these are all the pros of like why people want to explore like micro finance.

18:18Is this trend, the micro frontend trend is similar to because we need more and more super apps?

18:35Yeah, I think so. I think like when you have more and more.

18:40Yeah, I agree with you in the point of super apps, right? Not all SPAs are huge and needs to be split into micro finance.

18:48But if your SPA is very complex, have a lot of logics that spans across different teams, then maybe it will be better that you, and maintain by multiple teams, then maybe one way to make it, break it down or make it more maintainable and coordinate across teams would be a micro finance.

19:12So imagine one example, like if you go to say AWS, where inside you have so many different features of AWS, maybe you go into the dashboard and you see that so many, you have so many different features from dashboard, so many different features and each of them.

19:30But when you use it, it feels like one application, one single page application. But then each of these different features, like maybe your S3, your RTS and everything, they are maintained by different teams.

19:43So how does all the different teams build their frontends and then all of them together into one?

19:48So that is when you have something like this kind of situation, then maybe you might want to look out for solutions like micro finance that allows you to split the frontends as how you would split the backend and coordinate and work together into one SPA.

20:11So the need of this micro frontend is more like because the bureaucracy happened because of so many teams and anything at once and we need to separate them vertically or horizontally.

20:33Or there is some other side like you can achieve more performance for user side.

20:44I think from what Lihao mentioned is there is one aspect that I get is development cycle for example. So each team probably have their own maybe sprint, thinking about sprint, their own features to build and the development cycles probably they have.

21:04What we are talking about here is about large team, like one feature. So if you can put up that example again, how PayPal build the page for example.

21:19The balance team, PayPal balance and history probably different, like transaction history team probably have their own team and their own development cycle.

21:39If this is, if eventually the application is too large and each team need to have a dependency to wait for another team, that going to be a lot of headache to maintain.

21:53We cannot like let's say we have two weeks deployment cycle for example, while the other team have faster cycle, while the other team need to have less fast, less quick cycle and how to synchronize them probably very hard.

22:16What do you think Masifan? I guess the challenge on the microphone is the performance right since it is easy to be wrong when maintaining the microphone and you maintain multiple application in two single domain right.

22:40It is pretty easy to be wrong. So I guess the most problematic challenge on the maintaining microphone is about the performance itself.

23:02If your application doesn't really care about the performance, I guess maybe microphone can be your option.

23:15What do you mean doesn't care about the performance? I am very particular in performance, I care about the performance. What do you mean if you don't care about the performance, go with the microphone.

23:36It just easy for you to make a mistake in the microphone. Because everyone like probably use a different version, something like that, different version of application and it's suddenly like piling up.

23:51It's like its application, I mean its component will start to calling their own, let's say JavaScript files and eventually the application itself is bloated. Is that what you mean?

24:07Yeah, you need to have a proper, the orchestration part or the middleware part should be the best part since you will orchestrate multiple services into single domain right. It is not easy for many developers.

24:35Maybe let me give you an example. So you think about performance right, let's imagine like you are on the backend when you think about microservices.

24:47So just now the example that you say that you have three different services, the transactions, the history and maybe the balance right.

24:57So you will have, so you probably have three different teams and then three of them build three different services and for each of these services when you deploy to the backend you own the whole container to your own right.

25:11You can look at the container, you can debug, you can profile your service and see what you optimize and you know if it doesn't go well you can scale it up to more services, you can profile based on looking at CPU and stuff like that.

25:26But if you think about this analogy and you put it to frontend, when you look at the UI that we just saw just now on PayPal, all three micro frontends are run within the same page.

25:38All of them are running together in one page that UI sees. So when you look at it you can't really, but I mean if you want to, if one of this application is not performance,

25:52it's say they maybe have some sort of memory leak or there's something that it's not doing, maybe have a for loop for a thousand times right.

26:03By just looking at this, like the web page, like it could be coming from any of the application right, so it's not as easy as like you have like monitoring to look at just your page.

26:16One service and it's isolated environment you can look at and figure out what went wrong to your application, but in this case all the micro frontends are running in the same environment,

26:27in the same browser, share the same JavaScript thread, share the same JavaScript memory, share the same DOM and anything could happen and it's much complicated to debug and figure out what goes wrong.

26:42So I wouldn't say like you don't care about performance, it's just that it would be much much harder if you want to, when you care about performance in this situation it's much harder to optimize right.

26:52And there will be overheads as well that's introduced by the middle layer right. In backend we think of it as orchestrator is another service that runs independently and like they can also be scaled independently,

27:08but all these pieces are all running in your browser in the same memory and same JavaScript thread, they all share the same single-threaded JavaScript.

27:17So it's much heavier than you know just simply have one application and you know one team that look at everything at once and stuff like that right.

27:30So there will be like some coordination, communication between application and that makes the whole thing much complex and it's much harder to look at when you talk about performance.

27:45I guess the focus is on the development faster right. So how to speed up the development when you have many teams developing a single application and how to deliver it to the user without conflicting each other.

28:10So I guess that's the focus of the microformant.

28:19Eka, do you have any thought or questions?

28:47Let me ask a question, probably what here is what can if microphone and could be a good tools but also could be a good pattern, also could be a bad pattern if it's not orchestrate very well.

29:08So imagine an application use Sphere, Vue, React and jQuery differently on each component for example that means each component will try to download their own compile file for the framework like Sphere for Sphere,

29:36like Vue with Vue, their core app I mean like so that means like even just like a React Core would consume correct me if I'm wrong, last time I know is 72 kilobyte, last time I know probably React 19 is already different now.

29:55But let's say if each component download their own core application that means the application could be bloated with so many library involved.

30:10Is that what you mean Masifan? If it's not orchestrate very well we could end up hurt the performance a lot.

30:21But even though the principle that introduced by microphone is make you unlock the possibility for you to deploy multiple JavaScript demos inside a single application but I guess the real implementation I don't think there is a crazy developer

30:50that developing a single application using multiple framework like you said before.

31:00I have a different opinion just right now a couple hours ago I just code review someone just use React inside the use effect they call jQuery to document selector. Just two hours ago. Can you imagine that?

31:24I have no idea that's why me and... No it's written on scratch it's just like a filter application and I don't know why.

31:39So it's happening. Masifan I guess we can treat jQuery today as a shortcut for the vanilla JavaScript. Yeah some people still use jQuery to document selector they don't know about using the document selector very well.

32:00And use jQuery but they try to call it inside the use effect. And I still like when doing code review why you do it like that? Maybe it's like a plugin jQuery plugin something? No.

32:19They just do it. It's a deadline and it happens that way. But it happens out there Masifan not probably in our world in ngobrolin web community they don't do that but out there there are people doing it.

32:44But the jQuery is not a framework right. jQuery is a library. It's not like you're deploying a few applications with a React application into a single SBA right. It is a different thing I guess.

33:07The real life implementation I guess even though the team or the developer using micro front-end architecture they still use the same JavaScript framework.

33:25Let's say they're using React or Vue just pick one. And the other application is just the implementation in their business use case.

33:40There's actually one use case where a single app can consume components like front-ends in various frameworks. For example you use Astro. That's one very specific case.

33:56Astro can render React components, Swell components, Vue components together. So that's theoretically possible though I don't really see why you would purposefully mix that but maybe you have like all components from another project or whatever.

34:14And then another case if you have custom elements you know web components like you can use it in a Swell project, you can use it in React project with some tweaking so it's technically possible if the micro front-end packages just consists of custom elements and maybe utilities.

34:35I've never actually done any of that but theoretically possible right.

34:40Yeah but you need the helper tools like Astro that helping you to deliver multiple frameworks.

34:52But I don't think it is good for you to deploy multiple JavaScript framework into micro front-end even though it is possible.

35:12Just because you can doesn't mean you should.

35:20Go ahead.

35:24Yeah I think I just want to ask the real elephant in the room right now about micro front-end is about dependencies right because in my experience implementing.

35:37I don't exactly use micro front-end but I did make components into like you know like the I don't know what they call it's like molecule organism in something like atomic.

35:52Atomic design so there's a molecules organism and then atom by itself like button and something like that so I did use deploy this micro micro components all over the place and use that just like a jigsaw like a Lego puzzle just to build an application.

36:15It's not a micro front-end but there was a real challenge for me when the times to upgrade the core library in this case I did like from react something to react something.

36:30So is it a challenge in micro front-end let's say the micro front-end orchestration is already using the best practice we every component use the same library like react in this example when you want to update react from 18 to 19 in the core application.

36:51How about the other like the other teams should they upgrade to the same react as well during at the same time or can we still run some some some components to use react 18 some other component because they are late and they are faster they use or they already use like 19 is there a that would happen in multiple teams some teams are faster than the other.

37:20Let's look at how you did solve this in micro front-end.

37:26I would like to piggyback on your question like what would be the you know what the peer dependencies include both react 18 and 7 like old version and new version for the consuming app or what does it look like like is there a best practice to streamline of that like logically it means the consuming app should have should have yet.

37:54So 17 and should have 18 should have all the versions of react to handle all the micro front-ends right so what would that look in practice.

38:08Okay.

38:12Okay, let me try to start with saying that there's actually two or contradicting goals or aims that we when we talk about when we talk about dependencies and micro finance right so one thing we talk about the benefit of micro finance is that each of this micro finance right in your page.

38:40Each of this page can be developed independently right so you actually have the autonomy of choosing your dependencies and choose the way how you write your code and choose when on how frequent you want to deploy your thing right so the goal of this is to have total independence so that you hopefully the goal is that anyone screw up doesn't screw up your application or if you screw up your micro finance you don't affect other people right so so this goal is actually tries to.

39:09Isolate as much as possible from yourself to be independent and not being affected by anyone else's timeline or anyone else's problems or anyone else's dependencies.

39:23So this is one of the main a lot of people when they think about micro finance this is the main goal right so that's why they want to split that single like one monolith into multiple micro finance but when it comes to performance or when it comes to upgrade dependencies and stuff like that.

39:42We actually have a totally 180 like totally different point of view of what we want to achieve which is actually everyone should come together and coordinate and do the upgrade together right a lot of times we think about react upgrade we want to do it together we don't want to.

39:59You know some upgrade some don't upgrade although it is possible in i remember in i think should be react 18 or 17 where basically this i remember is i think it's really 17 and above actually react supports that.

40:14Within one replication the react sub tree you can have 18 and 17 at the same time, so it is possible in react it's one of the react i think 17 or react 17 feature to allow this because previously they bubble all the event to the root.

40:30Dom element and and basically you can't have multiple versions of different versions in the same place but but this is already possible but but come back to the point is that whenever we talk about things like this we want totally different like totally contradicting to our goal of micro finance which is everyone comes together coordinate let's do a version upgrade together.

40:57Everyone use the same version of component everyone use this dependency don't use everything else it's totally different right and and basically it's like okay everyone needs to agree with this date when we go on and release together.

41:11So so i so my point is that it's it's a totally different philosophy when we think about problems and different goals we are not saying that it's not possible but you find it so difficult because it was actually very it's actually a totally hundred 80 degrees contracting thing with your original goal that you want to achieve with microphone and which is the independence and isolated environment.

41:37Yeah, so I'm not sure that answers your question.

41:42I can't remember what's what's the actual question but yeah I just want to point out this fact that it.

41:49Yeah, this this tool contradicting goals we have when we talk about microphone and and I think in terms of yeah I remember it is so so in terms of dependencies.

42:07We have a concept called module federation, which is basically a webpack feature, if you build with webpack.

42:20Yeah, but actually, yes, so so if you talk about module federation yes you are stuck with webpack.

42:26I think something similar to module federation or the idea of modern fashion you can have it with other bundlers or other build tools is maybe you use something like

42:41this very old thing called UMD or require JS right require JS that you can run on the browser, but basically the idea is that you have some sort of dependency registry.

43:00Dependency registry or like some sort of ways that you can require dependencies in a browser and allows like and and allows like multiple separate multiple different builds different application can use the same registry to require or import

43:22the same module dependency or same instance right so so the idea is the same with module federation is just that with webpack module federation the whole thing is handled by webpack and you can list like

43:36you can in the plugin in the webpack config you can specify like what are the dependencies to be shared across different builds and then what pack will do something similar to require JS where

43:50you will find this in the window in your like windowscope if you have this dependencies is available when you take it if not then you you then import whatever you've bundled together with application and then you can also share the one that you bundle with yourself to other people as well.

44:10That's the idea of module federation that allows you to share the dependencies of a module, but it doesn't solve or doesn't tell you about the problem of coordinating the version right so in module federation and in other

44:32other systems usually when you when you require dependencies or in your application in your package JSON where you define your dependencies you want to have you want to depends on a certain version and above that you support right and basically if there's a new version that's like a major bump or something that may have a breaking change you wouldn't want to use those you want to use those that you have tested and used.

45:01Right so my point so so now becomes like if you want to call in and force everyone use the same version of a dependency then that new version if it's a major version they may have breaking changes to your application and you have to test it right so so there's something that

45:19again it's a contradicting to your original goal of microfinance which is everyone like make sure that it works on their own and isolated and doesn't being affected by other dependencies and other modules.

45:39Okay.

45:44So, I have another question. When we decide to use microphone and it depends on how big the app will be or it depends on how big the team is.

46:00I think if the. Yeah, I was just going to say like, if the app is not big, but you have a big team. Is that a problem.

46:14The problem.

46:31Maintaining the microservice must listen.

46:34Okay, okay, since there is there is many people that following the trend right. Like, like, there is many things that jump in to the microservice without understanding the problem statement or the condition on the on their company right.

46:54I guess it is pretty same on the microphone and you need to understand your, your team and it is, is it your team capable enough to maintain the, the multiple application.

47:09Is there any person or team that maintaining the middleware or the orchestrator of the microphone and is it is the application big enough to be split into separated micro application right.

47:30There is many constant, but I, I, I think one one constant that implementing microphone is not that easy.

47:41That's why there is a plugin module federation to help you orchestrating many complex thing right.

47:49I guess to to to using a microphone and in your company or in your in your team, you need to have at least one.

48:03The engineer that understand the tooling or the infrastructure since you need to set up the deployment, the delivery, maybe it's not that straightforward like we delivering the single application in the single domain right.

48:22There is, there is many hidden, hidden thing that need to be to be tackled first. So I guess you need at least one principal engineer in your team.

48:35Okay. Okay. Okay. Make sense. Okay. So, so let me change the question. So you need microphone and when you don't want to wait for the everyone finish the, the feature building and need to deploy together with one.

49:00Maybe the ops team. So you separate the team every each team will have a separate project or separate dev ops one or two dev ops team in every team.

49:19So the team will will be able to deploy every time they want independently.

49:30Just do not go with micro front end in the first place. Same with the back end right. Go with the monolith first and if you feel the monolith is not good enough for you, it is too complicated to be maintained, then go with the micro service right.

49:50It is the same with the micro front and just do not go with the micro front and in the first place until you really need it.

50:03How we know that we need it? How we know? What's what's the when people start fighting the sign? What is the sign that we need the micro front end? When when each team start fighting, everything is important.

50:20That's in the deployment ceremony right. If the deployment ceremony complicated, you need to wait the other team to deploy your changes or something like that. The delivery become become too slow to to.

50:38Yeah, the delivery become too slow. So I guess that's the sign if you want to try to explore micro front end. But there is many many other aspects also. Just do not do not decide by only one one aspect.

50:56So how about Li Hao? When did your team start to implementing micro front end? When does it happen like and why you just long back then? It start with monolith right. Those time we start with monolith.

51:13Yeah, so when the team becomes when you have multiple teams right. So first of all is when you have multiple teams. I think if you have one team, unlikely you're going to fight with each other.

51:30That's what it says. Unlikely you, I mean you because one team you have one leader and that leader will do the coordination and make sure things goes well. But when you have multiple teams, each team leaders will have their interests and their goals and their directions that they want to go with.

51:48But because everyone is maintaining within the same monolith right. You still have to come to a consensus of what we should be doing right. And maybe sometimes your application or your feature goes faster than the team grows.

52:05And you have more and more people working on the application and you start to hard. It's starting to get very difficult to get everyone's consensus on what is the right direction of the application. Then what's the right way to do the pipeline? What's the right way to do the maintain your project, your repo and request and stuff like that.

52:27Deciding the linter, which linter style we want to use.

52:35That will be the easiest. I mean when you have more and more people, some people will question and say we want to try these things. Maybe they want to try something different. Maybe they want to try say use RS pack to build that thing.

52:58But then because the entire application is in webpack, you can't switch over like that because the application is so huge, so many teams is working together. Everyone has their own timeline and features. You can't do it all at once.

53:12So something like this is very hard to try if you have a huge application. And it would be much easier if you can build maybe just one page. Maybe like one team say that maybe one of my page I can build it separately. I can try to upgrade those things. I can upgrade to RS pack. Maybe I try something different.

53:35And that will be something that what microfinance can actually allows you to do.

53:44So when the teams become, when it's a huge team, we have different opinions and maybe the team is across different location, different offices, then that's where you will start to think that it's possible that actually some of these teams they can build their own page separately.

54:06Then I guess you will think about like, yeah, maybe it's possible with microfinance and then you will try and explore this idea.

54:16Makes sense, makes sense.

54:22So actually Masipan's comment earlier made me realize like you mentioned about like in back-end, start with monolid and then microservice, but in front-end, maybe like the before you go all the way to micro front-end, I don't know.

54:43I think Monorepo in some cases make a lot of sense, especially now like JavaScript tooling like Turbo repo or whatever.

54:53So to some, you still work in one large project, maybe you share tinder or whatever, you share the same Tailwind config, for example, but you can also have some level of independence as for, you know, publish, you have, for example, you may have several multiple packages of UI components that you can publish separately.

55:22Maybe it's one reasonable step before going all the way to micro front-end in completely separate projects, right?

55:32Or does it answer different issues altogether? What do you think?

55:38I guess this is the time to discuss the article from the first. This is the pretty different point of view with the micro front-end that we already know for a long time.

55:58So let me zoom in.

56:12Not this one.

56:16So basically, it's trying to micro front-end but with different perspective. We call it as a horizontal and vertical micro front-end, which we already talking about is the horizontal micro front-end that we deploy multiple application into

56:44separated services, then we orchestrate it into single application. That's horizontal micro front-end.

56:56Then doing a micro front-end with a pretty different concept. They still chunking the front-end application into separated, maybe a folder or separated directory, which you can build by their own, but they didn't deploy it as a multiple application.

57:25They maybe just publish it as a packages or as a library to their registry or their artifact registry, and you just use it as usual library in your application.

57:43So basically, it's separating the code base into several small set, but you integrate it into single build process. So basically, it's just a single application, not like we already talked about micro front-end where there is many application life in the single.

58:12Single main app, right? So I guess what Eka said before is the vertical micro front-end that Farsal already implemented.

58:27There is a picture. Yes, this is the horizontal split and the vertical split.

58:43Can you zoom a little bit? I guess it's too small.

58:50White lights. Farsal is black.

58:56Farsal is black.

58:58Open image in new file.

59:04Abis. Can you open Abis? Web API.

59:21So the horizontal one is you're deploying into multiple application, right? They call it as micro front-end F1 and then docks is micro front-end application 2. There is a sign that you deploy it into separated services.

59:39So you have multiple services in the single URL.

59:44And the vertical split is you just separate it as a shared package. So you have a header package, you have a footer package, which can be reused by other pages for other application.

59:59Let's say you have Farsal home and Farsal docks. Let's say the header is using same package.

1:00:09Yes, there's the explanation there, but because zoom in, the margin is so large.

1:00:16Vertical micro front-ends split by path where each page handled by a single app.

1:00:23One app, one page or one section horizontal split by features.

1:00:31One page, multiple packages, multiple apps.

1:00:38Interesting.

1:00:46This is Farsal, right? Not Next.js, right?

1:00:50Farsal website.

1:00:54Farsal is an interesting example, right? Because Farsal has many like, you know, the marketing landing or marketing site, and then there's the documentation or guide, and then there's the dashboard.

1:01:13It uses Farsal.com. Maybe it shares the header and whatever they mentioned, but of course inside where we manage our Farsal projects, it's different thing altogether.

1:01:31Do you have any comment, Lihao, about vertical and horizontal split?

1:01:37So actually vertical split will be something similar to multi-page application.

1:01:45So you can just think of it as you don't have to have everything in single-page application.

1:01:55Maybe you have ten pages, but maybe five of the pages is one SPA, another two is another SPA, another three is another SPA.

1:02:03And that's where the vertical split comes in, where you split into three applications, three different SPAs.

1:02:12And I think that's what they were saying. So you don't have to split, doesn't have to be application that's in one SPA, then multiple features in one.

1:02:25That's like multiple features in one page that's horizontal, but you have multiple pages in your SPA as well, you can split some of the pages out.

1:02:34For example, in this Farsal, it's like login page or maybe like education page that's totally different that you don't really -- that usually you use this few pages, you usually won't navigate to other pages.

1:02:48So you can actually split them into two separate applications, that's where you do a vertical split.

1:02:56Or in terms of like if you're talking about like an e-commerce page, like there will be one -- the home page and the product listing could be one single application,

1:03:09while the checkout is totally different SPA because checkout has its own flow until it's finished. And transaction history or accounts is another SPA.

1:03:22So it's a vertical SPA because it's also totally handle a different thing, like user account. Probably we can think something like that as well. Is it a good example?

1:03:33Yeah, I think so. Yeah, so when we talk about SPA and MPA, it doesn't have to be all pages into one SPA or like MPA doesn't have to be like every page is one app, right?

1:03:46It can be some of the pages in one, some of the pages in another SPA.

1:03:52Makes sense, makes sense.

1:03:55How long it takes the team -- you said before that before in your company, there is micro -- sorry, monolithic app and then migrate into front-end.

1:04:14How long it takes to migrate to fully functioning micro front-end?

1:04:23I can't remember the actual timeline. So it happens for us is probably like one of the team that decides that they want to split their features out into a separate application, separate build.

1:04:36So to make that happen probably takes maybe a few months, one or two months to make that happen.

1:04:46But I mean they already have existing code and existing component. It's just like separate their build and make it work, make their component still running in our existing application.

1:04:58But it will take another one or two years to actually to see that this is a working mechanism and then like all the other pages or features that start to, you know, fully move.

1:05:16So it's such that almost every team now is running on their own application and stuff like that.

1:05:23Speaking of migration, the first article that we just looked, actually discussed how the process of migrating, like can you open it again?

1:05:33It's pretty, I think it's interesting. Yeah, that one using feature flags. I think scroll up a bit.

1:05:43Scroll up a little more. And scroll up a little more.

1:05:51I think that one intro. Yeah.

1:05:56Oh, scroll up a little bit more until our migration path.

1:06:03Yeah, that's it. So they explain the steps they took.

1:06:10So first they broke down the app into three parts, three core areas.

1:06:18And blah, blah, blah, blah, blah.

1:06:27So I don't know. I've never used that Next.js feature. Next.js multi zones.

1:06:34Maybe it's a feature. So supposedly it supports vertical micro front ends.

1:06:42Oh, they're interesting. They create brand new applications like maybe in the new zone, like in the new each micro front end, they create new apps.

1:06:53Shared components, blah, blah, blah, blah.

1:06:59Continuing with the Monorepo and centering code into packages within the Monorepo.

1:07:08Yeah, they still use Monorepo then.

1:07:15I think we need to see like Monorepo and micro finance are actually two different things.

1:07:22Different concepts, right? Yeah. So micro finance is basically just saying like your code and my code, we can build independently.

1:07:35You go to my own build process, you release your own, I release my own. Something like that. It's like micro finance.

1:07:43Monorepo is more of like something when we call a monolithic code base is all the code is in one Git repo.

1:07:52But you don't have a clear separation between like which folder or where is like team A's code, which folder or which place is a team B's code.

1:08:02So when we say about Monorepo, it's actually saying like, okay, we use package JSON, a folder and a package JSON to basically define the boundary of the folders.

1:08:15To say like, okay, within this folder, this is what package? This is which team?

1:08:21And then we need another folder with a package JSON that says, okay, which team is the boundary of that package? And then also with the package JSON, you can define dependencies.

1:08:33And then you can draw like dependencies between like a folder, like which package boundary depends on which package.

1:08:40Because previously in a monolithic code base, not mistaken with like monolithic application, this is just talk about the code base itself.

1:08:50Any file can, any module can import any modules.

1:08:54Then it's very hard to figure out like all the dependencies between like modules or between teams.

1:09:01Because maybe within this folder is team A's code.

1:09:05But one of the modules inside this folder imports something like some other teams code, like teams B's code in some other folder.

1:09:13But you don't know that there's no way to know.

1:09:15But with Monorepo, you have a package JSON and define all these things and define some constraints.

1:09:21Then it's much clearer that, okay, actually team A depends on team B's like which package.

1:09:27And then team B's depends on team C's which package.

1:09:30Then you have a clearer dependency.

1:09:32Then I think when you coordinate between teams or between packages, it's much, between code owner, it's much cleaner.

1:09:40But it doesn't mean, but they can still be built together in one monolithic application.

1:09:46Or they can also build as a separate like a microfinance application.

1:09:51In short, microfinance doesn't mean multiple repo.

1:09:59It could be just Monorepo and build separately and become a microfinance.

1:10:05Right?

1:10:06Yeah, exactly, exactly.

1:10:10But with monolithic code base, if you do a microfinance, then it's a bit more messy.

1:10:19Because when you build your code, it can depend on any file or any module from any teams.

1:10:26Then if someone changed that code, when you build again, that could break you without you knowing.

1:10:33So it would be better that you already maintain the code base as a monorepo code base or like multiple repo.

1:10:41Then at least it has a clearer dependency of your separations, clearer boundaries.

1:10:48Yeah, when you do your build, then at least it's more on the management.

1:10:53It's not impossible.

1:10:55It's just like clearer boundaries so that you know what happens if something goes wrong.

1:11:01So basically which part, which package depends on which package.

1:11:06Yeah.

1:11:12Irfan, can you give us a simple set up microphone?

1:11:18Or is there any tools that we can learn or we can get it started?

1:11:24Maybe the fastest solution right now to implement the microphone.

1:11:31And we look any work around maybe using the module federation plug-in.

1:11:39Yeah, module federation plug-in.

1:11:42But from the previous link that I put, there is a sign that module federation plug-in in the Next.js will not be supported anymore.

1:11:56So if you're using Next.js for your microphone end, the suggestion is just stay in the pages router or moving from the Next.js.

1:12:13This one.

1:12:16But for some migrate to microphone end, they use space router or they don't use Next.js?

1:12:24No, no, no.

1:12:26They use Next.js, they mentioned.

1:12:28Maybe they use space router.

1:12:30No, no, no.

1:12:31Because they use a term microphone end for a different perspective.

1:12:38Concept.

1:12:39Like we already call the vertical microphone end.

1:12:42If we can call the vertical microphone end as microphone end, then many website is actually maybe microphone ends.

1:12:52It just we don't know how they organize their developer inside their internal team, right?

1:13:01So in a way, microphone end is not a technical term.

1:13:06Like it can be subjective like how Fabcell implement interpret and implement that WhatsApp.

1:13:15But maybe other project don't use to implement it the same way, is that right?

1:13:21There is many feedback on their article because the first idea from the microphone end is to be deployed as separated services and independently and isolated, right?

1:13:38Because my suddenly first released the article and they call it as vertical microphone end, which is they just publish a separate code base to maybe to their accuracy and consume into single application and they call it as microphone end.

1:14:04So I guess there is a shift on the term microphone end itself.

1:14:10I guess if we can call the vertical microphone end as a microphone end, the vertical microphone end is the easiest steps if you want to try to implement the microphone end without changing your build process.

1:14:33Maybe you can use just Next.js build tools or you use your build tools.

1:14:48Basically, there is no changes on your build process and the deployment.

1:14:53You just release some code into registry or in the single monoribu and consume it to the orchestrator application, right?

1:15:09It is easier if we can call it as a microphone end, but if you want to go with the multiple services inside a single application, maybe module federation is the easiest one.

1:15:26Good news, module federation can be used with feed. The link is in private chat.

1:15:40How about swell? Any news for swell?

1:15:46Well, swell, you can use it for swell. You can use it for anything that can use feed.

1:15:57It's just Next.js. If we can categorize vertical microphone end like Versa did as a microphone end, is island architecture can be microphone?

1:16:23Sorry? No, island architecture is used by Astro.

1:16:32Yes, maybe. Since island architecture, but island architecture is the rendering strategy.

1:16:38It depends on whether the island comes from like separate package, like the philosophical approach of the development.

1:16:53How we split the component, maybe it's aligned with the Versa article, right? But since island is about the rendering strategy, it's not about how we structuring the development project approach.

1:17:13What about the wire? If you're thinking about microphone end thing and we have in the back end microservices to handle front end, could it be build the pages based on its microservices?

1:17:38Not a microphone end, but some microservices. I'm not sure. Maybe we can. I'm not sure.

1:17:54So, we can say that the vertical one is not real microphone end because the purpose is different, right?

1:18:03It's Versa. It breaks the purpose of the goal of the microphone end itself, right?

1:18:17Ya, itu biar bikin heboh di akernius aja sih. It's to generate conversation around their product.

1:18:28I don't know we can answer this, but there is one question. How to do microphone end in React Native?

1:18:37Do we need that? Let's say we build super app for mobile using React Native. Do we need micro-content for that? Maybe using the web view or something like that.

1:18:59Many super app is also using web technology for their content. The native is only the wrapper. So many feature inside the super app application is built using web technology.

1:19:21In China, everything is super app and everything are multiple apps within one web view.

1:19:33Ya, everything is super app. When we were in China, if you want to rent a bike, you go to this bike application. It's load a completely different screen, completely different thing because it's written in Chinese.

1:19:53I can't even read anything and it's different UI and different user experience. I thought why this is the same application but different UX, totally different color.

1:20:06One application to make payment, to rent a bike, to pay for subway ticket, to order book, to order faxing. What about Shopee app? The mobile version. Do you have some insight?

1:20:28I'm not sure how much I can share but I guess it's...

1:20:37Ya, but I was just thinking like is it possible? I'm not familiar with React Native but is it possible that you can load or do code splitting with React Native?

1:20:50Like maybe in one page you load this React Native bundle or this React Native build and when you go to a different page you load a different React Native build. Is that possible in React Native?

1:21:06None of us actually familiar with React Native because there will be something like vertical split microfinance for React Native, right?

1:21:28There's one more question, I think. Is it crease or stripe? Oh, this one. Stripe embed with some microphone end. Not necessarily. Maybe yes, maybe no. We don't know.

1:21:44Which one is this? We can create something like embedding when user wants to pay. We click pay and we go to Stripe website or embedding iframe or popup.

1:22:08Then we pay with Stripe or credit card and then we go back to our web, right?

1:22:17I think it's embedding but it's not necessarily. There is another one like an iframe one. Stripe can have an iframe, small iframe popup. It's not necessarily microphone end.

1:22:38No, there is no redirection with Stripe. It's just like... I mean you open their URL, right? Yeah, in Nanaiframe or in Widget or something.

1:22:50Yeah, they set server side cookie to handle everything that when transaction finish you go back to the origin URL.

1:23:00Yeah, I do agree. I think in terms of how it's being implemented, it can be implemented with iframe or it can be a JavaScript SDK that you load from CDN and then you render that component.

1:23:14It can be a red component that you use. Basically, different techniques that you can use or the same technique you can use for how microfinance embeds another or how another microfinance together, right?

1:23:30That's why we are not saying that they are microfinance, right? Even if we redirect, that would be what we call it like a vertical split microfinance. But for this case, we probably wouldn't want to call it as microfinance as well.

1:23:44The only difference is that microfinance, usually when we talk about microfinance, we are thinking about one... it comes from the same company, one huge department, the web frontend team, web frontend department that may have multiple frontend teams and then all of them come together to build one application.

1:24:07But they are from different teams, right? And so they don't build and then they separate their application into separate builds. I think that's the main idea of why we call it microfinance, right?

1:24:23Sometimes when you have multiple, like one, say Shopee, you have Shopee and you have the seller portal for the seller center for the Shopee and then you have like operator portal for the Shopee. But we don't call them separate as microfinance, apparently.

1:24:42Although it feels like a vertical split. Yeah, it feels like a vertical split where, you know, seller go to one page, one build, buyer go to one page, operator go to a different page for vertical split.

1:24:55And I guess the reason why we don't call it microfinance is probably it doesn't... it wasn't start with one application to begin with. Most likely we build them in separate subdomains or domains and they are not one application. They are three different applications, three different domains or subdomains.

1:25:16And probably it starts from a totally different team, three different separate teams. Yeah, and I think that's why we don't call it a microfinance.

1:25:26And so I would say to conclude, microfinance usually will say like, okay, you have an application as a monolithic application. And then when you split them, you call them a microfinance split, right? Yeah. So it will be something like when you have a monolithic backend service, when you split it, it calls a microservice.

1:25:47But when you start with two or three separate services, two or three backend application, then you just call two different applications. You didn't call it like three separate microservices. Yeah.

1:26:03Makes sense. Yeah. So I guess that's where... yeah, that's how you... I think that's what we all usually mean when we think about microfinance. It's not about the technology, it's not about just about... It's a pattern. Yeah, it's a pattern splitting a single application into separate builds.

1:26:24Okay. Okay. Yeah. Thank you, Lihau, for the conclusion. So for that, maybe... What's the applause? Use your songbook. Thank you very much. Thank you, Mas Irfan. Thank you, Mas Irfan, for coming. Thank you, everybody, for the discussion.

1:26:48The main line is don't start with Microphone N until you get it. Start with monolith. What is the sign you want to go to Microphone N when your team start fighting? You have multiple teams and they all start fighting.

1:27:07Yes. If they're not fighting, let them be. Don't touch everything, okay? That's it for tonight. Thank you. If they can work in peace, just don't do Microphone N. Just let them be in peace.

1:27:25Just do Macrophone N. Okay. Maybe that's it for tonight. See you all in the chat next week. Good night. Bye-bye.