This is a transcript. For the video, see Laravel - from the evolution of monolithic applications to the revolution of fully decoupled systems: Challenges with monolithic apps and fully decoupled systems - finding a middle ground.
[00:00:00] Michael Meyers: Hello, and welcome to our Tag1 TeamTalk on Laravel from the evolution of monolithic applications, to the revolution of fully decoupled systems.
[00:00:08] I'm Michael Meyers, the managing director at Tag1 Consulting, and I'm joined today by Laslo Horvath, our senior software engineer. We're doing this talk in three segments. The first segment was an overview of Laravel, which was really awesome. Check it out. This segment, part two, is the evolution of development from monolithic apps to decoupled systems and be sure to check out part three, which is the future of application development in Laravel.
[00:00:37] Laslo, welcome back. We mentioned some of these concepts in the overview at a high level, can you just, before we dig into each and some of the pros and cons, can you just give people, you know you know the difference, what is the monolithic approach? What is the, fully decoupled approach?
[00:00:58] Laslo Horvath: So, I won't go into a huge history or whatever here. So the base, basic differences in the monolithic way, you have everything in one place. So your code is basically generating the output and generating the output that's shown in the browser. So you have, you have the cycle. And this stateless cycle, so to speak, where you just sit and submit something to server calculates, it, spits it out.
[00:01:22] Then, then you get it in your browser. The decoupled way is where you have on one side, you have the front end application, and the other side, you have the backend application and they, they communicate only through, through API endpoints. So one can you could be able to, I mean, it rarely happens.
[00:01:43] This is really rarely the case. I am yet to see it, really see it where you could basically just switch out the front-end with something else and you get it. And also on the other side, you can switch out the back end to something else. As long as the API signature is the same, you basically. It is seamless. So, so this is, this is like the, the whole, the whole thing.
[00:02:07] Again, the fully decoupled way, actually the front end applications are meant to mimic like how a normal applications work on your phone, laptop, tablet, whatever. So all across all devices, it should in theory, work like a normal app, which means it's stateful. So you can just rip around weekly and all the whole experience should be undisrupted.
[00:02:33] So it feels like it's flowing.
[00:02:38] Michael Meyers: So what are some of the challenges or problems with the monolithic approach to application development?
[00:02:46] Laslo Horvath: So for me, the biggest, the biggest thing was that it's such, for me, it was such a huge waste of free resources. So basically you go through this whole cycle, you want to change one checkbox, for example, and do a save.
[00:03:00] It will like send a bunch of things. Then the server will be running and then it will return the response. So this whole cycle like felt cumbersome. Like, especially if you know how it can work. And especially if you're, if you're like used to using like let's call them desktop apps or, or native apps, maybe it's a better name.
[00:03:23] And then you jump into this and then, you have to click and save and then wait for the response. And then, there's nothing on the page, then something comes out. Yeah. It's just somehow it's, it feels very inefficient. It increases the traffic every time you send, get it back, it's, it's kind of, it's, it's also, also feels old school.
[00:03:42] We, as people, always like new things, sometimes we were afraid, but we like trying it out. Then if that's something new and shiny, you get drawn to it. And this just felt like such a huge waste of resources and, and feels like really, really old school for also the second biggest thing for me was that it's, for me, it's really disruptive.
[00:04:02] Because I click and then I have to wait and I can not do anything else because and if the internet is slow and if, if there's some something on the server, ----- flow, I cannot do anything else. I have to wait for the response to come back. And if you're doing a payment or do you need something like every time I need to.
[00:04:19] You need to do a payment. That's not marginal. I'm like, okay, what if something goes wrong? I mean, I know how banking systems work and everything. I know it's it's fool-proof and I know you won't lose your money, but every time, like, okay, now I have to click and then, then processes need to happen. And I have to wait for the response.
[00:04:37] And, when it's non-disruptive and you stay on the same page where you have the same screen before you, somehow you feel safer I'm like, okay, cool. Now just a quick percent. And that's it. The button is disabled. It's enabled. I know it's true. I have some feedback and that's it. And, and the other thing was, I mean, I'm from the generation where you had your native apps and then you had the web pages and these two were completely different things like, and your mindset was okay now I need to browse.
[00:05:05] So I need to browse. I need to, I know what I'm in for. So back back in the day, we, I, I also like turned off images on the web page because I will need like minutes for a normal page render. Especially if the programmers were not good enough to know that they need to compress images, you know? And then I would end up with broken pages.
[00:05:26] You just read the text and that's it. Whereas on the other side, now, okay, I need to. I type something I need to do something on the computer. You had one type of experience and then you jumped into the browser, something else. And it was, it was like always shifting between, between these two.
[00:05:43] So this is also something that I think led to more and more people and generally business moving too, and realizing like, okay, we need to. Maybe do it this way. I'm not sure who started it. My first real great experience with this was with Gmail. So like Gmail changed, changed the way emails were done for me changed the way I think about the applications and basically like the whole experience, but it was much more pleasant than, than anything else I used online up to that point.
[00:06:15] So. Yeah. So this is like basically the distinction for me.
[00:06:20] Michael Meyers: Yeah. It's a really good analogy. I remember in the nineties, early nineties, like those images progressively loading in and, and, and it's, it's an interesting analogy for monolithic applications and user experience. And there's tons of research on, how quickly things happen and user engagement and increase revenue conversions, and, you know in a, in monolithic monolithic applications, often I see like when payment is handled by a third party, that like URL bounces back and forth and you ended up, it looks nothing like your application.
[00:06:54] No. Yeah. The user experience is, is, is kind of off. it's it's Oh, it's off, it's inefficient on the backend resources side. there are, there are benefits to it, but, but there are, there are drawbacks. at, at the same time, there are also challenges with a decoupled approach, right. Um what are some of the issues that frustrate you from that perspective?
[00:07:21] Laslo Horvath: So as with everything, we figure out what's bad with the current approach. And then they're like, Oh yeah, we have the answer. Let's do this. And then we jump into something else. And then over time we figure out, Oh, maybe this wasn't such a good idea. After all, maybe we should rethink this for, from my experience.
Because you know what, and I'll have enough experience in both worlds, like done plenty of working either way. So I can really say from, from my personal experience, I always hate the the complexity that comes with it. So as a, like I hate the expression full stack developer. I think that every developer should know some basic stuff and you shouldn't give yourself a title if, if you know that those things, but now your whole, whole All knowledge stack needs to be like really wide.
[00:08:07] So if I, if I want to do a decoupled, maybe I use Angular on the front end. I used Laravel in the backend, so I really needed to know Angular. And these are completely different development methodologies, but the mindset is completely different. The way you handle things is completely different. So it's not so easy to jump from one to the other, you know okay.
[00:08:25] The syntax is not that different. At least when you get used to it, it's not, but, but really the way like with, with the observables, with the promises, with everything in that you have in TypeScript or JavaScript is totally different to the way you, you work normally in PHP or, or in some backend languages.
[00:08:42] And then this whole thing is, is, gets a bit too much, then of course. The companies that have two teams that do this and do that one team does front end work and they specialized in that other teams. So you have like really a segregated, really separated type of, of developers that you need.
[00:09:01] But then again, for the company, it's a challenge. Okay. We need to find Angular developers, and we need to find PHP developers and it comes at an increased cost. So you have to plan for everything you need to manage all that. You need to manage the communication because. Like every time you have communication between teams, the effort level is up by, I think, 30%.
[00:09:20] That's like the nominal value that you say when you have, when you have, when you have communication to an external interface, you have to factor that in when you are estimating, when you're doing the actual work, it will cost more time because you need to, to build around this fence between, between those two teams.
[00:09:36] So, for me personally, as someone who does all the work, so both front end and backend, I hate to the increased complexity that comes with it because you manage to the repositories. You, you have to take care of front-end code of backend code. The other, the other thing that that comes with this in the front end is that sometimes.
[00:10:01] I ended up with huge libraries, you know? Okay, let me use this. Let me use this. I need the charts I need. I don't know some date plugins. I need low dash whatever. You end up with libraries that are a couple of MB big and I mean, it's fine. We have fast internet, but we need to draw the lines on there and say like, okay, this is now becoming increasingly inefficient because like the browser needs to load up all these things needs to run all these things.
[00:10:31] and like if you check now, I don't know. It, it wasn't like that. Like if you open your, your system task manager, and check like memory usage now Chrome, Chrome is dominating. it used to be like, I dunno, whatever Netscape Navigator or Explorer or whatever we used to use.
[00:10:52] It was at the bottom of the list. And now like Chrome, is using half of the resources and this is due to how things are happening now. And this is some of, some of the downsides of it because, it's. It comes with increased complexity and it adds so much work to the browsers themselves
[00:11:13] Michael Meyers: Technology advantage equal, but more overhead in managing them different skillsets, hired hiring is already complex and a challenge.
[00:11:22] yeah,
[00:11:23] Laslo Horvath: So it's yeah. I have, I have also the sorry too. I have some more, I'm not done.
[00:11:32] So I also it can be something and it can also be very dangerous. I, I was doing a, like a cleanup work on, on one app, which was done in Angular, which had, for example I mean the, the change detection is generally the biggest problem for all the front end frameworks, because they promise you two way binding.
[00:11:53] So basically if you change something on the page in the, in the code on the page, like in your framework, React, VueJS, Angular or whatever you, you are. You are, you get to be aware of that change. So this is what they call it two way binding also to you calculate something. It will be reflected in the browser.
[00:12:09] The user will see that change. And the way this changes is detected is sometimes can be very inefficient. So again, like Angular we will change from Angular one to Angular two , they made a complete change because for this reason, because Angular one was so inefficient and was eating up so much so much of, of browser resources that they had to like change it from the ground up.
[00:12:33] But even in Angular 2, if you didn't know what you, what you were doing, like, I remember I opened the page, it had 2 million listeners on a single page. So every time you type, like you hit the button on the keyboard, it triggered 2 million listeners, and it was, it was really terrible. And this is, this is what's really, what's really dangerous because nowadays there are a lot of experts.
[00:12:54] They are, they are real experts, but then there are experts who, who like, can do something quickly, but don't really understand what's happening in the background. And this is exactly because of this, because you're jumping, you don't even know how we get got to this point and you're just assuming it works.
[00:13:09] And then you end up with something that's, that's really -----. Like I have, I remember I had a table with 20 rows and it wouldn't render . The browser died sometimes. And it's, it's really, it can really be a huge problem. And then this comes again for it to work properly. You need experts and you cannot be really an expert at everything you need to choose your technologies.
[00:13:30] And then it's increasingly hard to find resources because a good people are, are. I mean easy for Tag1 to talk. We have, I've worked with some really great people here, but otherwise, like I really, sometimes I had problems. I did not personally have problems, but I I'd seen people who. Maybe don't don't really know what they're doing in that regard.
[00:13:53] And then that can cause problems if you're not really, really an expert in this field. So this is something that for me, I wasn't aware of this. I have to say I was also on the bandwagon. Like, yeah, let's do it. I love this. I'm an engineer and I don't care about design and things like that. I just want to implement business logic and, and focus on that.
[00:14:13] And then as it started to grow, as I've seen more and more projects, I'm like, okay, maybe we do have a problem here because this is not the first time this happens. Or, or another, another big example for me was okay. how do we separate? What goes, where, like there are some really complicated, I mean, it sounds simple.
[00:14:35] It's but not everything is black and white, so it's not always easy to separate, like, okay, what do I need to do in the front end? And what do I need to do in the backend? Because with the monolithic, it was easy. You have maybe front-end validation and that's where it stops and everything else you do on the backend.
[00:14:50] And then it's clear. So, okay. I will, I design it like this, and now it's like, okay, do I need to move this maybe to the front end? How safe is it? I will certainly save resources on the backend and the server will have less to do, but is it a good idea? And, and do I need to separate this process? Like, I dunno if I do some complicated calculations, is it safe to do it in TypeScript, in JavaScript in the browser or is it maybe a better idea to do it in the backend?
[00:15:17] And then if I do it in a back end that I need to call an endpoint again, and also these sort of things like add up and again, then it leads to like, hopefully. Some, it leads to projects that get canceled. It leads to projects that are in problems because you just don't factor this stuff in. And one of the biggest things that comes from all of this is that projects tend to take a lot longer than, than if you just jump in and do the work and that's it here you have to plan for, for a lot more things.
[00:15:51] So, this is something that we figured out in the meantime, while doing, doing all this work, you just, somehow you, you, you get to be aware of all these negative, all these drawbacks.
[00:16:01] Michael Meyers: Yeah, they're there layer - abstract layers of abstraction, and these tools are really powerful and they enable people that otherwise wouldn't be able to create applications, to do a tremendous amount of work very quickly.
[00:16:15] And that's fine for a certain class of applications. Right. But when you start getting into the, the territory of applications that we develop, I think that's where. A lot of problems and challenges arise that you mentioned, being quick and dirty and fast is super short-sighted and, and leads to a lot of problems and failures down the line.
[00:16:37] And you, you need to have a significantly greater level of expertise and planning and design upfront. to achieve your short-term and be in a position to do your long-term goals. So is there, there, there, there are some significant yeah. Challenges to both approaches and we know there will never be a perfect approach because as soon as we have it, we're unhappy with it.,
[00:17:02] Laslo Horvath: You find something wrong.
[00:17:05] Michael Meyers: Is there some sort of, but these are, these are really great approaches that have a lot of benefits. Is, is there. a middle ground between them that starts to settle some of this out.
[00:17:16] Laslo Horvath: yeah, so I think there's, as with most things there, there isn't an, there is a right answer.
[00:17:25] So for me, first thing is you analyze the, what, what do I need, what do I want to do? It does, it does really my, my, like my application, what they want to develop, have a real benefit from, from doing like completely decoupled approaches? Is maybe a monolithic approach enough for me. Because you get what you need and, nowadays you can, it's not really, I mean, we have fast internet and everything.
[00:17:53] So in some cases it might be just enough for what you need. And on the other hand, like if you need something more complicated, if you really have a, like a B2B application, something that people will open and use the whole day on the screen and. You have really the resources to develop it because you have to be aware that, okay.
[00:18:14] Instead of doing it for six months, maybe you'll need 18 months to develop it, but then you'll know it will work fine. Then you should definitely consider that way. And in the meantime, we have like sort of a hybrid approach, which is, which is in the last, I think a year really starting to pick to gain steam in, in the Laravel community is, is this kind of hybrid approach where they make life easier as a developer for you to create basically single page applications.
[00:18:46] And, and even pro progressive web applications without having to dive into too much front end code. So basically you don't have to use some of the approaches use front-end frameworks in JavaScript or TypeScript and others, like or, you can mostly survive, like with 95% of writing just PHP and still end up with a great user experience.
[00:19:09] So this is like the middle ground between those two. It's fairly fresh, fairly new. So it's still not clear as with everything. if we figured out what's wrong with both to all the approaches still, it's still not clear. Where does, how does this stack up against everything? The early signs are promising.
[00:19:26] I, I did some some I already used both approaches. One of them I use extensively. So I developed work. I even know one of the core developers in one of these libraries. And it's so far, it's, it's really a pleasant experience. I cannot guarantee that it will solve a bunch of problems. I am not sure.
[00:19:46] Where does this stack up on this whole scale of small, middle and huge projects. And how does, how does it behave once we get to that point? But I think this is, this is a neat way. And this is also a nice toolkit to have in this whole, you know, Tug of war between, should we do it this way? That way now we can do it both ways basically.
[00:20:07] So it's, it's, it's nice. And I like it that there's like this third entrant in this, in this game where. as with everything, let's try to take both the best of the both worlds and try to combine them into one and then see, see how this behaves.
[00:20:24] Michael Meyers: Awesome. That's a good segue to part three.
[00:20:28] So let's wrap up here. appreciate you walking us through some of the challenges with these monolithic applications and fully decoupled systems and, and finding that middle ground. if you haven't already please check out part one, the overview of Laravel. Next up is part three, the future of application development in Laravel and continuing this conversation.
[00:20:51] if you like this talk, please remember to upvote subscribe and share it out with your friends. You can check out our past talks at tag1.com/tagteamtalks. As always, we would love your feedback and input on this talk or topic suggestions for future talks. you can email us at tagteamtalks@tag1consulting.com.
[00:21:14] Again, Laslo huge thank you for joining us and thank you to everybody who tuned in. We'll be back soon.