Doguhan Uluca is a Software, Agile, and Cloud engineering expert, Author, and Speaker. He joins the show to talk about his book, "Angular for Enterprise-Ready Web Applications". He begins by explaining his book, his motivation for writing about enterprise applications, and many more!

Enterprise Applications with Angular - AiA 392
 

Lucas Paganini (00:01.495)

Hello, welcome to Adventures in Angular, the podcast where we keep you updated on all things Angular related. This show is produced by two companies, Top End Devs and Unvoid. Top End Devs is where we create top end devs who get top end pay and recognition while working on interesting problems and making meaningful community contributions. And Unvoid, which offers performance-based web developments, so clients only pay when tasks are delivered.

 

In today's episode, we will talk about enterprise applications with Angular. My name is Lucas Paganini. I am the CEO of Envoyed and your host in the podcast. Joining me in today's episode is our lovely Subrata Mishra.

 

Subrat (00:48.01)

Hello.

 

Lucas Paganini (00:50.083)

and a very special guest Dohan Uluka.

 

Lucas Paganini (00:56.971)

Dohan Uluka is a principal fellow at Excella in Washington DC, leading strategic initiatives and delivering critical systems. He is an industry recognized expert with technical knowledge in usability, mobility, performance, scalability, cybersecurity, and architecture. Dohan is the author of the bestselling Angular for Enterprise books, speaker at more than 30 conferences and

 

an Angular Google Developer Expert alumni. Dohan has delivered solutions for Silicon Valley startups, Fortune 50 companies and US federal government. Dohan is passionate about contributing to open source projects and teaching. He enjoys building Lego, playing Go, traveling, and just overall being better than me in everything that he does. So, he is here today.

 

Subrat (01:49.804)

Yeah.

 

Doguhan Uluca (01:51.566)

too kind.

 

Lucas Paganini (01:53.691)

so that we can talk about what enterprises think when they are deciding which technologies they're going to use and how Angular fits into that scene. So yeah, Dohan, I think there are multiple different paths in which we can go, but you are the expert here. I mean, you wrote the book on that subject. So I will let you...

 

introduce and then we'll take it from where you take us.

 

Doguhan Uluca (02:28.686)

All right, thank you so much, Lucas. So yeah, using Angular for the enterprise is a topic that I've been engaged in for a really long time now. And over the years, leading teams of developers, my priority has always been.

 

optimizing the technical solution, you know, one, of course, to meet the business need, but also for the developer experience, DevEx. It's an increasingly important topic. You know, recently Google updated their DevOps research program Dora metrics to kind of highlight the well-being of

 

Doguhan Uluca (03:25.794)

factor in the success of a project and as a result of that, the organization. So I think it's really important for technical leaders to pick tools that they can depend on but also that makes their developers, their teams happy to work with. So that's been kind of like my guiding light on.

 

on my journey.

 

Doguhan Uluca (04:01.294)

But one of the things that I always think about is this sinkhole effect. Let me explain what I mean by that. Of course, a sinkhole is a natural phenomenon that where the ground suddenly collapses usually to devastating effects of revealing a giant hole.

 

Lucas Paganini (04:02.697)

Thanks for watching!

 

Doguhan Uluca (04:30.934)

And this can happen right within neighborhoods. Sometimes houses get swallowed up. And the reason this happens is water underground goes and eats away at the material, but leaving the surface intact. This happens especially when we pave over the ground with a road. So it doesn't gradually sink, and you can see it from the outside.

 

but instead it digs a giant hole underground and then when there's enough pressure, it collapses. And I'm not a geologist and not an expert in sinkholes, but I think it's a useful metaphor to explain what happens with long-lived projects, which usually happen in an enterprise context. So, people

 

You know, in general, tend to be passionate about technology if they're, if they're coding and, and our industry, it's kind of a, both a blessing and a curse that there's so much new that happens all the time. So that's, that's why I think most of us, you know, join this industry. There are lots of people who, you know, career switch also into it. And.

 

And it's kind of fun to keep up with everything that's coming out. Every week there's a new framework or there's a new update, or there's a new pattern someone is announcing or pushing out. But where I see where this kind of fast-paced environment can hurt people is

 

When we bring these tools and technologies that are brand new into the project that we're working on for that enterprise. So then, you know, that enthusiasm and excitement over time creates a situation where there are lots of different libraries.

 

Doguhan Uluca (06:55.438)

different patterns on different sides of the projects that are being rolled out. And then once something goes into production and the business is depending on it, you know, the sales are depending on it. The performance of the website is usually directly related to the revenue that the company can generate from it. You know, whether it be, you know, so many milliseconds it takes to load up the page so someone doesn't get bored. And.

 

goes away or you lose a sale or being able to retain customers over time. If your application becomes choppy, slow to render, or the maintenance burden becomes so high that it becomes super expensive to add new features. You know, we're all familiar with, with those, you know, clunky apps we're forced to use at work. And they haven't changed, you know, their feature set for the past 10 years or something like that. And we go scratching our heads, you know, why is this happening?

 

This is ridiculous. So yeah, the reason I think this happens is the single effect. It's basically kind of uncontrolled innovation that happens and then creates this effect. Then once that collapse happens, it's usually you have to rewrite everything. So this is where I've always been a fan of Angular.

 

because, you know, as most people may already know, you know, Google dog foods Angular, which means they use Angular in thousands of apps, you know, internally and externally. So, you know, by the time the framework, you know, gets to us, it's already been through its paces. So there's a level of trust that you can have in the framework.

 

So yeah, this is why I think from a high level technical perspective, when we join companies, it could be a new job or a new project at a job, usually that decision of what technology that's going to be used is made by someone. It's made by a CTO or a technical leader or an architect.

 

Subrat (09:18.166)

Yeah.

 

Doguhan Uluca (09:22.286)

And it always hurts me when these decisions are made, because the CTO just read a cool blog post over the weekend. And they want to go with the new hot technology, just because it's exciting and it promises the world. And I've seen a lot of people hurt because of those kinds of rash decisions.

 

And what I mean when I say hurt, this means people being forced to work long hours to meet business deadlines, the undue stress that's caused. And it can also strain the relationships between your colleagues. And once you enter this kind of downward spiral, it

 

it tends to amplify that negativity. So once you kind of take a step back and realize this all could have been avoided because of some decision that was made by someone who's not even going to work on the project, it becomes a bit disheartening. So this is why I want to encourage

 

you know, leaders, technical leaders to, you know, kind of put their excitement aside and really make decisions based on, you know, tools and technologies that are here today that are mature. Of course, there's always a consideration, okay, is this going to last me the next five years or the next three years, you know, whatever the business planning looks like there. You know, there's that question that needs to be asked.

 

But, you know, once again, just going back, you know, why I think Angular is good from that perspective, because, you know, we can depend on Angular still being there, you know, three or five years from today. Yeah. That's kind of the motivator of why I write my books. They are...

 

Doguhan Uluca (11:43.306)

They're not easy, they're very hard to put together. It's, I think, the second edition, which came out in 2020. It grew to be 900 pages long, which, when you think about it, that's 300 blog posts. But the difference is with blog posts, you can get away with changing your mind every other week. Oh, check out this cool thing. And then, and next week.

 

you know, or the next blog posts, you know, you can be like, yeah, this cool new thing, you know, but, you know, there are some caveats and all that stuff. But, you know, with the book, you know, the whole thing has to make sense together. You know, you don't get to kind of, you know, cheat your way through it. You know, what's being, you know, what you're introducing in chapter one has, still needs to be valid on chapter 10 when you're, you know, deploying your application on AWS or, you know.

 

Whatever.

 

Subrat (12:45.929)

Yeah, I think, as you said about, if someone is deciding about technology, I would just like to go a little deeper on and try to ask you like, can you guide someone like if someone is listening who has a authority to select a technology or select a framework and what all things they should consider if they have a team or if they don't have a team and they will create like hire a team or recruit

 

after they selected.

 

Lucas Paganini (13:17.435)

And just to extend Subrata's question, I think it would be, and first, you said so many interesting things, I think we could spend the entire rest of the podcast just expanding the points that you brought up because they were excellent. But yeah, I like what Subrata asked, but just to be clear, I would love to have your take on just a general approach to decide technologies, not just which front end framework.

 

or something like that, but generally speaking, how to decide which technology to use in a safe way, long-term thinking, right? Because I have seen so many different suggestion of approaches, so for example, I've seen people saying, yeah, just do a hackathon and then divide the developers in teams and each team takes one technology

 

do the thing with it and then you compare and decide which one do you prefer. But I see pros and cons with that. I've seen just, oh yeah, instead of leaving that to the team, the architect needs to decide. But then sometimes the architect isn't so well versed into the actual implementation of the thing, although he is the architect, he's not the one that will be actually using the technology every day. So.

 

Maybe this person can slip some important information and then the developers have to pay the price long term. So yeah, I think there are many other approaches too. So I would love to have your take on that since you are someone that actually studied how enterprises tackle those challenges. And I think that how the enterprise tackles is probably the most conservative way.

 

because they can't afford to make many mistakes. It's just too expensive. So yeah.

 

Doguhan Uluca (15:21.802)

You'd be shocked how reckless enterprises can be. The leadership might think that they're being conservative. But this thing you mentioned that where the architect decides but they may not be familiar with the ins and outs of the technology is quite telling because that is ultimately what happens.

 

And deciding things by hackathon, if you're truly walking into it with no opinions of, okay, we can either go A or B, so let's do a hackathon to decide, I'm not quite sure what you're testing for during that period. There's so many variables. You're at best getting some information about perhaps the...

 

the current capabilities of your team. That doesn't factor into what those capabilities should evolve into. Or it also doesn't factor in the fact that perhaps not everyone has brought their top game that day. So it's really difficult to know what the outcome of a hackathon actually says.

 

Of course, there are sometimes outcomes where if you can do something in one hour using a set of tools and then it takes the other team eight hours, like when you're talking about a huge difference like that, then yeah, it's clear to make a decision based off of that. So yeah, the right tool for the right job. Right?

 

As technologists, as developers, as engineers, our job is not to pick a framework and champion it until our last breath. It's absolutely the right tool for the right job. If we're doing something simple, then Angular is overkill for that.

 

Doguhan Uluca (17:50.106)

your regular HTML and CSS and nothing else. But the factors that go into deciding the technology in an enterprise context is usually a question of scale. Can this scale from one team to be able to host multiple teams at once? And that determines

 

patterns and practices that you employ. And in that patterns and practices you employ, keeping them similar or same-ish within the organization also buys the organization a ton of flexibility, one in terms of hiring new people to those skill sets, but also enabling that staff mobility within the organization. Because if one team is doing something crazy and wild that no one on

 

has heard of and has seen, that's going to be really difficult to move people in and out of that project. And same goes with hiring people, whether you're trying to bring in a consultant or you're trying to hire a full-time employee or a contractor. If you're working with something super niche and bespoke, I usually try to give the example of...

 

If you're trying to hire a Ferrari mechanic versus if you're trying to hire a Toyota mechanic, right, the hourly rate of that Honda mechanic or Toyota mechanic versus Ferrari mechanic is going to be slightly different. So I try to, you know, with every project I kick start in a new organization, I try

 

That's the example I try to give. I want to first and foremost deliver you the best Toyota I can. First and foremost, let's nail that down. And then if there are parts of this that needs to look like a Ferrari, then we can get into that. But usually a lot of people are...

 

Doguhan Uluca (20:09.942)

kind of tricked by that allure or the excitement of that, you know, flashy thing. And they've spent, you know, so much of the initial project time, you know, working on that aspect of it, which then leads to, you know, that burnout or it leads to, you know, undo scrutiny from management or, you know, leading up to project cancellation.

 

There's nothing worse than working on a project for a year, a year and a half, and then it just gets canceled. And then all that work and planning goes to waste. So

 

Doguhan Uluca (20:54.798)

So matching these requirements with the right technology is the challenge, right? So there are sets of technologies that are easier to work with that cater to a more inexperienced technical team, so to speak. A good example is

 

Uh, you know, I'm, I'm a big fan of, uh, you know, no JS in the, in the, in the backend, because it's easy to set up. Uh, you can, you know, it's all has very small, uh, you know, memory footprint. It starts up quickly. So it means you can take that code and put it into a serverless function in the cloud. You can put it into a tiny container and, uh, you know, for example, you know,

 

my various websites, I host them all in a single digital ocean server that uses Docker with like seven or eight containers, and I just pay $5 a month for it, right? Because it's right-sized. It's the right tool for the right job. But, you know, of course, leveraging these cloud technologies, then these, you know, small footprints.

 

servers or serverless functions then can scale up to handle thousands of concurrent requests all at once. So I like that flexibility. And I know others like Python for similar reasons, because of its dynamic nature. If we take that and contrast it to, for example, Java. Or the.NET framework.

 

those frameworks are really strongly typed. And also, you really have to know the libraries that ship with the framework to be able to develop within that framework. Whereas with, you know, with Python or JavaScript, you're kind of getting these packages and it's easier to explore and implement things. Whereas...

 

Doguhan Uluca (23:20.87)

You know, looking at the rigid structure of a piece of Java code or.NET can be a lot more difficult. So, but if you have a team who's already really great at those technologies, you know, perhaps, you know, you pick a set of technologies that are compatible with the capabilities of that team. Or if you have a, you know, team that's more, you know, green,

 

Uh, and, and they have a lot to learn then. Yeah, absolutely. You pick a set of technologies that will more suit the, the capabilities of that, of that particular team.

 

Lucas Paganini (24:05.788)

I like the many different approaches that you brought up. I remember doing some interviews, some system design interviews, and the interviewer, whenever they were like, okay, now this is the project, how would you architect the solution? Which technologies would you use? My first question,

 

to the interviewer was always

 

Do we already have a team or are we going to hire the entire team from scratch? Because if we already have a team, then what have they used in the past? And how fast do we need to deliver this? Because I think this is a great point. You need to consider the things that your team is already proficient at. Because at the end of the day, like...

 

we're thinking, oh, we have bun version one. So let's start using bun and get rid of node because bun is faster, is like significantly faster. Okay, but you know what? If you really wanna go faster, why would you use bun? Why not just go directly to Rust, for example? If you really want fast, why not go to Golang? So, you know,

 

And also, how fast are you going to actually deliver those features? Because the end users, they are practically not very concerned about one second differences. And one second is big, one second it's significant. But still, it's not the end of the world for users.

 

Lucas Paganini (26:06.295)

choose between having a feature released in three months and then it's like sub millisecond or having it released in two weeks, but for some reason, some parts of it are taking one or two seconds to load. Like I would go with the two weeks route, especially because then you can actually present something to the users and pivot from that. Because in the first off,

 

alternative, you just optimize a lot, something that you don't really know if the users want. So I really like that path of being mindful about what the team is proficient in. But I think it's also a balance. Like you can't just 100% go from whatever the team is most proficient in. Because what if the team is...

 

super proficient in the LAMP stack, for example. So, PHP, Apache is like, I'm not saying that these are bad technologies, they are not, they are just not the greatest thing at the moment. And they are probably gonna show some issues in the long run. And you won't be able to stay.

 

up to date with what the entire ecosystem is using because they are in a complete different path. So if you're choosing between React and Angular, they're very similar in many ways. But if you're choosing between PHP and a single page application, then that's big. So I think it's definitely a balance. But how far would you take that balance? Like...

 

Is there any rule of thumb that people can use to try to make better decisions? And let's even take it to a smaller level, not because I think PHP versus single page applications was a very big example and I don't know.

 

Doguhan Uluca (28:18.392)

You just officially declared that it's that it's not bad

 

Lucas Paganini (28:22.603)

Yeah, yeah. I mean, I'm trying to not be aggressive here.

 

Subrat (28:28.173)

I think the one thumb rule, like if you are not getting new developer and if you can't have them, you should throw that tech away. I'm just saying.

 

Doguhan Uluca (28:41.794)

Yeah, I mean in 2012 I you know, I was hired to work on a project a system that's been live for 30 plus years based on mainframe technologies and the various developer team was due to retire in the next three to five years. So they wanted to replace the system before.

 

Subrat (29:04.569)

Hahaha.

 

Doguhan Uluca (29:07.562)

that happened so that all that detail and knowledge, you know, otherwise would disappear. But you know, of course, that's another extreme concept. So one, you know, principle here that I talk about is a shoe hurry. So that's a Japanese concept that, you know, first lets you master the basics of technology or anything really.

 

You know without worrying about the underlying theory so much You know, that's the shoe part and then the hot part is then you know master that theory and then the re part is then adapt what you mastered to your needs and The thing is when adopting new technologies people usually skip that, you know, they kind of get into it you know without underlying the The you know understanding the underlying theory

 

And then they skip to the, okay, now I'm going to adapt it. I'm going to change the way this works to fit my needs. And that leads to kind of irresponsible adoption of new technology. And so in terms of timeframes, I challenge people to, okay, you know, let's, you know, it doesn't mean.

 

Sometimes it doesn't even matter if it's brand new. Okay, we pick something brand new But we have to agree to commit to this for the next two to three years, you know, we can't be just jumping around Uh to you know to different things all the time. We have to take our time We have to master this and we have to push it up after those two three years. We decide this is good Okay, let's dive deeper into it. Let's bring more of it in let's become experts in this but

 

And it may turn out, OK, this really was not good. We thought this technology was going to enable us to do all these cool things. But turns out the promises that are made on the landing page does not really pan out when you actually, the rubber hits the road and you actually try to execute it. So and that bun example is a great one

 

Doguhan Uluca (31:26.418)

you know, people were even, you know, heralding the death of node when, you know, button one that was 1.0 was released, where, you know, because most of those people, you know, haven't bothered to, you know, go beyond that, you know, basics of it, and really trying to master, you know, why node is, why it exists.

 

how it exists. So yeah, basically, when you pick something, you first gotta take your time. So this is why I encourage bringing in new technology into side projects first, kind of throw away things, proof of concepts, and practice it and work on it. And then after you...

 

you as an organization, you've gained some confidence with it, and then merge it into the mainline development stream as a real idea. Because with the balance you mentioned, of course, we can't just cater to the current state of a team. So there's this idea of elastic leadership, where teams don't magically happen.

 

You know, they need to be, you know, fostered. They need to be grown. You know, they go from a state of chaos to, you know, all the way to kind of self-learning, self-sustaining team. And, you know, from a leadership perspective, you know, this means when a team is new, you have to be more directive. You have to tell people what to do. And then, but over time, that becomes.

 

Uh, then you are a more of a servant leader and you're enabling people, uh, and the people are actually driving, uh, the team members are driving the decisions. Uh, so, so the, you know, uh, so there's that, uh, journey of, of the team, but then there's also the architecture itself, uh, also needs to be elastic. Uh, you know, uh, and, and this is where kind of the tools we pick, uh, you know,

 

Doguhan Uluca (33:48.242)

come into play, for example, you know, if you pick rest APIs as your choice to build out your API surface, you know, how that API surface needs to be designed and maintained over time is going to be different versus if you choose GraphQL. And because with GraphQL, you buy a ton of flexibility, you kind of, you know, build around your major data entities and...

 

And then the consumer, the client gets to choose, you know, how to consume that API. Whereas with REST, right, you have to implement the same, you know, way to get a data entity, you know, 20 different ways so that every screen can get the most optimum kind of, you know, result out of that. So, you know, this...

 

You know, it gets into the core of the idea of, you know, picking the right tool for the right job is, is that, you know, how much flexibility, you know, does it buy you? And, um, and, you know, for example, uh, you know, we're talking about, you know, say a team has, uh, right, you know, a ton of.net experience, uh, for example, a typed system, et cetera. Uh,

 

You know, if you bring that team into a native JavaScript project, you know, they're going to struggle big time because they're used to the tooling, you know, giving lots of information to them right within their IDE. But, you know, if you use TypeScript, you know, as a bridging solution, then, you know, people are going to feel a lot more familiar with that. So, that's another way to evolve from technology.

 

uh, to, to different technologies, uh, you know, with the, you know, same set of people, uh, because, you know, we can't just, you know, fire entire teams and, and hire new teams every time, uh, you know, we want to release a new project or a new product, uh, you know, we have to, uh, be able to transition them. Uh, and, you know, retraining an entire team or re-skilling an entire team with a completely new technology is an expensive, uh, proposition, but

 

Doguhan Uluca (36:08.11)

finding those technologies that will bridge that gap, that will make people more comfortable with the same ideas. So yeah, if you take a team who's worked on.NET for years and years, and they've only developed REST APIs, and they've used ASP.NET and all these cool technologies, PHP,

 

And then, you know, throw them into a situation where everything is new. You know, all the tooling is new. You know, you're using GraphQL versus REST and you're using, you know, React or Vue or Angular or whatever, you know, if you change everything that's going to be a really difficult transition. So, yeah, sometimes we have to make compromises in the architecture.

 

but it is possible to gradually evolve things more iteratively and incrementally to find that balance.

 

Lucas Paganini (37:14.063)

Gotcha. So basically, use your best judgment to make the technology decision in the first place. And after you've made that judgment, then attempt to use that in a side project to actually put it into practice before rolling it out to the entire rest of the application. Okay.

 

Subrat (37:35.101)

Yeah, like when... Yeah, sorry, go ahead.

 

Doguhan Uluca (37:39.662)

I don't know. Yeah, I was just going to add. And it doesn't have to be a black and white. We picked this, and we're married to it. Because Lucas, I think earlier you were saying that the speed doesn't matter for certain things. And that's very correct. Not every screen of every application is the most important.

 

There is actually usually only a very few amount of screens that needs to be very high performance, because those are the ones that are used for intaking the users into the workflow. Or there could be one workflow in the application that's used by tens of thousands of people and is used by many, many times a day. So that workflow needs to be absolutely optimized. Right?

 

And that workflow can be then by the more experts in the team can use different technologies and tooling behind the scenes. So it doesn't have to be one, you know, one solution fits all because the rest of it, the 90% of the other things could be admin functionality that's, you know, seldom used where the performance doesn't that much matter or the, you know, screen loading layout or design doesn't have to be optimized or.

 

or it doesn't have to be super fast. So, and those can use, you know, a different set of practices. So, that's why, you know, I'm mentioning that elastic architecture in that sense. You know, if one page needs to be, because that's what Facebook did or does, you know, one of the reasons.

 

why they were so much into PHP and all that when they first started, uh, and then later on react with server-side rendering is because they could do the expensive, you know, uh, rendering work on the server side and then, uh, send it down to these phones that are, that are years and years old, uh, you know, on all continents of the world, uh, with, you know, poor internet access.

 

Doguhan Uluca (39:57.974)

Uh, you know, it's, uh, slow speeds or limited, you know, data packets, uh, or, or data plans that people have to buy. Uh, so, so that's a, that's an entirely different, uh, kind of, kind of scenario, uh, where, you know, they had to optimize the way they built and delivered their solution, uh, to the needs of their, of their audience. Um, and your project might have, you know, a sliver of functionality that is like that. Uh, so, you know, for that, you know,

 

Do things differently. But for the rest of the 90% of the things, do it cheaper, right? Just use the defaults, use the out of the box stuff and make it look ugly. You know, because at the end of the day, that's not your value driver for your business.

 

Subrat (40:46.397)

Yeah, I think when you say right technology for right thing, one question coming to my mind, I think it might be a question for a lot of Angular who loves Angular and why a lot of companies are selecting, like maybe React or Vue than Angular. Why I'm asking is I witness a lot of companies who have developed application in Angular for three, four years.

 

they are moving out from Angular to React or Vue. So what might be the reason? So one reason which came to my mind is which is Angular solving now by standalone components and all the new thing, control flow and everything. But what do you take on it? What the enterprise or why these big companies are moving out of Angular?

 

Doguhan Uluca (41:39.858)

I am not sure about the real metrics on that.

 

Subrat (41:48.246)

Hmm.

 

Doguhan Uluca (41:52.322)

So it's tough to comment on if there is indeed a big shift that is happening, or if it's just because people love to kind of do pit technologies against each other and cause controversy and all that. But the concepts, so.

 

The way Angular is designed, it allows for a lot of different concepts to be implemented within it, which comes with its pros and cons. Those teams of engineers that are used to dealing with rich concepts like dependency injection and all these things, they love Angular because it allows them to implement a mental model that they already have that they're good at to implement it.

 

But with React, it's easier to get started faster. But ultimately, if you take two projects, two teams that start one starts within one starts React, and they're both approaching it from that superficial level without trying to dig into it, two, three years down the line, they're both going to end in the same spot, where it's going to be a mess of a project.

 

where everyone is complaining about everything, screens are loading slow, nothing is working right. And then the desire is going to be to flip-flop, oh, we've selected React, it's not good, let's switch to Angular, or we select Angular, it's not good, let's switch to the other framework. So of course, Angular has...

 

You know, under immense load, Angular doesn't perform well. So if you're building an application with 1,000-plus components and really complex screen layouts and all that, just the way the change detection is architected or implemented doesn't

 

Subrat (43:51.231)

Mm-hmm.

 

Doguhan Uluca (44:13.738)

performance rendering of the screen. So that can frustrate a lot of teams when that happens. Because getting yourself out of that is very expensive. So the framework is evolving in the right direction with introducing the concept of a signal.

 

Subrat (44:40.193)

Mm-hmm.

 

Doguhan Uluca (44:43.166)

a few versions rolling out signal-based components, which allows for surgical updates of the DOM without having to run expensive change detection cycles. Because these features are now part of the native JavaScript language. So ECMAScript 2022 has these.

 

you know, basic operators that are built into the language that allows this to happen. In fact, there's a really cool project, Aero.js. I think it's aero-js.com. It's a, I think, a one or two kilobyte-sized library where you can build, you know, super modern reactive applications, you know, using extremely simple concepts.

 

Subrat (45:39.349)

Mm-hmm.

 

Doguhan Uluca (45:44.23)

So Angular is kind of moving in that direction. Also, especially with the standalone projects and the standalone components, it's just removing those kind of unnecessary concepts that make it easier to get into the framework. So yeah, React from the get-go does allow easier.

 

entry into it. So I think that is why it's more popular. But in the long term, a team that's not willing to go beyond the surface level to understand what's really going on with these frameworks will all inevitably run into major issues, whatever tool they pick.

 

Subrat (46:32.653)

Hmm. Yeah, hope Angular will like, will raise again like 2012 when AngularJS was there.

 

Doguhan Uluca (46:45.534)

Yeah, and of course, people always remember the more sensationalist headlines and stories. And that transition from Angular.js into Angular 2, that was a mess. I'm kind of glad that it even survived that transition. And then this transition into standalone.

 

Subrat (46:54.848)

Mm-hmm.

 

Subrat (47:08.927)

Yeah.

 

Doguhan Uluca (47:15.062)

uh, and signal based components is actually as big of a transition from Angular.js to Angular 2. But, you know, the benefit now is, of course, you know, they can slowly introduce that because that mechanism of being able to upgrade every six months and all that exists in place. But, you know, from an architectural perspective, you know, if you're already

 

Subrat (47:23.614)

Yeah.

 

Subrat (47:32.884)

Mm-hmm.

 

Doguhan Uluca (47:42.382)

built your application in the current way of building Angular apps with your observables, behavior subjects and modules and components, switching to standalone and signal-based means, rewriting a ton of code. And I don't think a lot of existing projects are necessarily going to go down that path, unfortunately. So, yeah.

 

Subrat (48:08.091)

Mm-hmm.

 

Doguhan Uluca (48:11.302)

But, you know, we cannot, you know, I can only take a step back and look and be really encouraged with the overall direction that's being taken. But if you need results today, you know, earlier in the year I gave a talk on QUIC, QWIK, and you know, that's a framework, you know, that was invented by Mishko Hevery, the

 

father of Angular. And if you want to build really fast websites or really fast tools today, yeah, pull that. And work with that. But will all that tooling scale up to multiple teams delivering code with it? That's the question.

 

Subrat (48:42.239)

Mm-hmm.

 

Doguhan Uluca (49:10.342)

You know, with Angular, we know it's proven. And with React, we know it's proven that massive teams can deliver software using these tools. So it's basically what's new and exciting versus what's been proven to work, and especially at enterprise scale, that it's been proven to work.

 

Lucas Paganini (49:36.451)

Dohon, I think we could keep talking about this for a while, but just because we're already 50 minutes into the show, I think we should start wrapping up. But before wrapping up, before we even started recording, we were just chit chatting and you mentioned a take that you have on testing. And I think...

 

it would be useful to talk a little bit about that. So I know that we won't be able to dedicate an hour to this subject, but I think it's an opinion that I've had for a while. And it was interesting that you brought that up that I thought, hmm, maybe we should indeed share that with the audience because that might be valuable to others. So yeah, let's talk a bit about that.

 

Doguhan Uluca (50:26.802)

Absolutely, yeah. Yeah, so and some of these insights you only get with time. So there's that testing pyramid that has the unit tests at the bottom, and then you have integration tests, and then you have UI tests at the top. And you know.

 

The idea is unit tests are cheap and fast, so you should develop lots and lots of them, thousands of them, but UI tests are fragile and expensive, and you should use that sparingly, so to speak. So I've known kind of, you know, ever since I've dug into Angular unit testing, is, you know,

 

Angular unit testing is not really unit testing, because unit testing would be really testing just what's in the function. That's not trying to reach out to a network, or that's not trying to manipulate a DOM element. With Angular, with the test harness, you're actually testing the class behind the component, and then the presentation.

 

coupled together. So, and, you know, the setup of the test harness sometimes can be so burdensome that, you know, what you end up actually testing is have I actually correctly configured the test harness or not? You know, versus testing something useful about that component. Because just getting to that, like, does this component render a test?

 

It requires so much time, energy, and configuration. And on top of that, it's actually slow. So if you have thousands of tests, running those can take 10, 15 minutes, which is an eternity if you're trying to do a fast turnaround on a small change. Of course, there are tools like.

 

Doguhan Uluca (52:47.878)

NX that can cache build results or test results and then basically hack around the shortcomings of the actual framework or what you're trying to do to make things faster. But at the end of the day, you're spending development time pouring yourself into trying to get this thing to work. So recently or...

 

As I've been kind of going through, looking at the teams that I work with, what they're going through, and as I'm going through updating my book for the third edition, I really started questioning the usefulness of these so-called unit tests. They're not unit tests by the actual definition of what a unit test is. But I've also started using a lot of different tools

 

GitHub Copilot as an experiment. And then I wanted to generate some UI tests for my sample projects that support the content of my book. And I was shocked as I was using Copilot how quickly, using Cypress, I was able to pump out these UI tests.

 

that reached near a hundred percent coverage of the code base. And they were really easy to implement. And especially with the copilot, it can give you chunks and chunks of tests automatically. It can write that for you. It can even understand the test IDs that you embedded in your HTML and it can automatically pull them for you in the suggestions.

 

And, you know, I was just shocked how quickly I could, you know, get coverage that actually tests what I developed. Uh, you know, not some, uh, you know, mid step representation of it, but no, the, the actual real thing, I mean, you know, just testing, does it render is, is one line of code like with no setup required. Uh, so, uh,

 

Doguhan Uluca (55:14.106)

I am more and more convinced that we shouldn't be wasting our time with these component unit tests. There is a place for them. So, if, you know, first off, if you're kind of breaking architectural patterns and you're implementing business logic within the client-side code, that should definitely be like that service code or that particular function with those if statements in them.

 

That should be unit tested separately and properly, not with the test harness and all those things. That should be just basic unit testing of that function. And then also if you're shipping components for other developer teams to use, or it's your product, absolutely, test that component until there's no testing left. But if...

 

If your end user is the person who's using the website, not the components, because the people who go to your website that you built, they're not using your components, they're using your website that you built. Then that test it, or let me put this out there as a challenge, experiment with using Cypress more and more. There are ways to get coverage metrics out of.

 

using Cypress as well. And see just how much coverage you can get, real useful coverage you can get versus compared to those unit tests where, you know, as a challenge, perhaps, you know, pull out your unit tests with your team and go through them and really question, okay, what is this actually testing? And like, do we really need to be testing if ngif works or not? Because, you know, at this point...

 

like your unit test should never be testing the underlying framework. Right. We shouldn't be testing, you know, does, does Angular work? Does ngif work? Does, uh, you know, um, yeah. So that's my, that's my hot, hot take.

 

Lucas Paganini (57:25.855)

And I agree with that. I think people spend too much time, we used to spend. I think this migration has already started a while ago, but just nobody talked about it for some reason. But yeah, if you look at the Angular docs, you're gonna see an entire section for testing, and it will explain the testing module and et cetera. And I think there's still a place for that, especially if you're testing,

 

I do a lot of state management tests. So how your data stores are reacting to the requests that you're making to them, if they are using the cache or if they are updating the cache, like all those behaviors, I think it's correct to test them using the testing module that Angular provides.

 

because if you try to test that with Cypress, then it would be awful. Also, if you're just testing pure functions and things like that, definitely. But yeah, I don't know why we'd spend so much time like testing component interactions that way. Like component click should change this property in this class and then you should be able to see this element. It's like, dude.

 

Doguhan Uluca (58:53.178)

Yeah.

 

Lucas Paganini (58:53.483)

Why not just use Cypress and run a click command and see if the element is there afterwards? It's so much easier and most importantly, I think, it's much more future proof because I love Angular, but you never really know how long a technology is going to last. I mean, React, I don't know how long it's going to last.

 

So the more you can make things work without depending on other technologies in your stack, the better you are, I think. There's also a downside to this, of course. Like if you have more integration, sometimes you can get away with doing less because it automatically integrates with your stack. So that's good, but I think it's...

 

It's a difficult decision and I lean much more towards using technologies that can work with whatever tech stack I choose. Yeah, exactly.

 

Doguhan Uluca (01:00:01.342)

It buys you that flexibility, right? And also if you ever have to rewrite that app, you can copy paste your Cypress tests and run it on the new stack that is being developed for to verify its functionality, right? So flexibility is king.

 

Subrat (01:00:04.257)

Yeah.

 

Lucas Paganini (01:00:19.24)

Yep, I go as far as for example, if I'm testing an API, like a REST API or a GraphQL API, I don't like to use tools like Supertest that you just expose the Express application or even the Node.js HTTP server class. I don't like that because...

 

I don't think that the tests should care if I am using Express. I don't think the tests should care if I'm using Node. If I want to switch from Node to anything, I should be able to do that and the tests should not care. If I'm doing tests for an API, I am literally going to call the... going to make HTTP requests to the server.

 

Doguhan Uluca (01:00:50.734)

Absolutely, yeah.

 

Lucas Paganini (01:01:11.855)

I put all my backend in a Docker container, I spin up the container and I just make requests to it. It's just a black box. It doesn't matter which technology is using. Yes, the test runs slower, it takes longer. Sometimes it's a pain in the ass when you're waiting for CI to conclude, but I really appreciate the flexibility of it.

 

Doguhan Uluca (01:01:20.374)

Yep.

 

Doguhan Uluca (01:01:36.19)

Yeah, and you know once again your service layer that contains your actual your business layer. Of your back end, you know that contains your actual business logic. You know test those with you know real unit tests that actually you know because you know you can iterate through so many options so quickly with that. But but yeah outside of that I mean I you know in all my projects I disable the controller layer.

 

Subrat (01:01:51.611)

Yeah.

 

Doguhan Uluca (01:02:05.486)

code from code coverage metrics because I don't want anybody to test the framework's ability to dependency inject or route requests. So that's why we're using a framework and not implementing this stuff from scratch.

 

Subrat (01:02:22.781)

Yeah, I think this also makes sense. Like if you're using sonar and not configuring pretty well, and it tried to cover everything that, okay, 90% is not covered and people are trying to do as best they can to like go and each click a button, take, check the text of the button just to cover everything.

 

Doguhan Uluca (01:02:41.598)

I love executives who love to look at metrics to determine success, but I, you know, once again like to challenge, you know, both the people who are trying to achieve those metrics and the people who are asking for those metrics to really think about what that metric is actually measuring.

 

Lucas Paganini (01:03:01.343)

Yep. All right. So thank you, Bohan, for being on the show. I hope you come back more because I think it was really valuable and we definitely have some 50 plus hours of content to extract from you. So feel free to come back anytime. It was a pleasure having you. And yeah, oh, and before we really finish the show,

 

Doguhan Uluca (01:03:07.395)

Thank you, Lucas.

 

Subrat (01:03:09.141)

Yeah.

 

Lucas Paganini (01:03:31.935)

Do you want to promote anything? I mean, you have a lot of things that I believe you would like to promote.

 

Doguhan Uluca (01:03:38.09)

Yeah, I'd like to promote the upcoming third edition of my book. You can sign up to get updates about it on angularforenterprise.com. And it's been completely overhauled to showcase both established and cutting edge patterns side by side, including creating standalone projects with the new router.

 

uh, change detection and state management signals, uh, using both rest or, uh, GraphQL APIs, uh, so it should be coming out sometime in November, hopefully. Uh, yep. angular for enterprise.com.

 

Lucas Paganini (01:04:20.339)

Awesome, okay. So Brett, what would you like to promote?

 

Subrat (01:04:26.249)

Yeah, as usual, I think I would like to promote my channel, which is fun and heuristic. So guys, please go and have a look. I had just started doing on NestJS. So I thought, like, it's a framework built for Angular developer if they want to learn anything on back end. So I was thinking long back, but I thought to start now because I don't have much.

 

things to do like I think I almost cover a lot on Angular so it's now time to go for Nest and I'll try to do both as a full stack development so just go and have a look on that

 

Lucas Paganini (01:05:11.543)

I actually saw that video. I'm gonna be honest, I didn't watch it entirely, but just because I already knew the content, but I saw the thumbnail and I was like, oh, that's interesting. Subreddit is talking about NAS. Let me have a quick look. But yeah, man, I've been using NAS a lot in the past months.

 

Subrat (01:05:20.563)

Yeah.

 

Lucas Paganini (01:05:38.027)

And my first reaction was that, oh, that looks super complete, very interesting. And then started using it and I got a bit pissed off that I couldn't use my functional programming paradigms in the backend as much because it depended so much on object oriented programming. But then I eventually came back to it because I found ways to still use my functional programming patterns and...

 

Subrat (01:05:56.546)

Hmm.

 

Lucas Paganini (01:06:06.607)

still adopts Nest because I looked at the alternatives and I saw none that there were as complete as it like it's really well thought out I even I took a look at marble.js which has a more functional programming approach but it's not even very well maintained I think the last commit was almost a year

 

So I got really scared about choosing a technology and then finding myself in that situation. I think that aligns well with what we were talking about in the show. I got really afraid of choosing a technology and then losing support for the entire framework that I chose to use. So I am just 100% Nest. For every project in which we have power to the side we are using Nest.

 

Subrat (01:06:43.717)

Hehehehe

 

Lucas Paganini (01:07:04.771)

for everything at Unvoid. So of course, if there's a project that the client wants to use another backend technology, no problem whatsoever. But if we have freedom to choose, we're using Nest for everything. And it's just so good when you have everything using the same framework, you can reuse a lot of your knowledge, a lot of patterns. Some companies even get afraid of like,

 

Oh, but are they going to reuse the code for my codebase and other client projects? But like, no, and we don't need to because it's about reusing the patterns. It's like your business specific code isn't even reusable for other projects. Like don't get afraid about that because there's nothing to use there. But the patterns about how the code is organized and how the responsibilities are isolated.

 

that is extremely valuable and makes us really more proficient for other projects. But yeah, so I'm going to promote my company, Envoyed, as I said in the beginning of the show, and we offer performance-based web developments. So it's a very simple concept. Clients only pay for the tasks they're delivered and approved.

 

So we don't just deliver the tasks and say, give me the money. No, we deliver the tasks and we ask, hey, is that what you were expecting? Is that aligned with what you need? Does that comply with the requirements of the task? And then once the tests are approved, then we mark them as billable and then we received based on that. So we are basically taking out every risk

 

there is in outsourcing. If you have a company and you either need staff augmentation or you want to completely outsource a project, there are so many doubts about how to make that work, how to find the best partner for your business. And we are just doing everything in our power to remove those doubts 100%. So if we go over time, you don't need to care about that.

 

Lucas Paganini (01:09:27.103)

you're just gonna pay for the value of the task that we are doing. And if that took us more than we expected, that's our problem. And yeah, so we're just trying to become the best partner for companies because we think a lot of companies are choosing to go 100% in-house and doing everything in-house. And that's coming a lot from an insecurity of...

 

If I try to outsource, it's not gonna work. They're not gonna do quality work. They're not gonna deliver things on time. And the truth is that happens a lot when you try to outsource a project. That happens a lot when you try to hire freelancers. But we can't just say, hey, this is not gonna work with us. We need to actually give you guarantees and that's what we are doing. So if you're interested in that, or if you...

 

know somebody that is interested in a staff augmentation or outsourcing a project or a side project of your company. And you want actual guaranteed results, then take a look at unvoid.com. We might be a perfect fit for your needs. So that's it. This was a very long episode and I feel like,

 

It was just five minutes because time flew so fast. It was great, really. So Dohang, again, thank you so much for being on the show. Please come back whenever you want and congratulations on all your books. It's really amazing the amount of content that you produced. And for everyone that is listening to the show, it doesn't matter if you feel extremely proficient

 

I highly encourage you to check out Dohan's books because they are gonna give you a more complete view of how to be valuable in your company, not just how to be an excellent Angular developer, but how to really understand how the business thinks about technology and how to talk the same language as the...

 

Lucas Paganini (01:11:43.451)

on the directors of your company and they will be able to see you as a much more valuable developer because of that. And that might take you into a very interesting career. Maybe you become an engineering manager, a CTO, or even a founder yourself in the future because you started learning how the business side thinks about technology. So I highly encourage Doha, again, what's the link?

 

Doguhan Uluca (01:12:09.383)

angularforenterprise.com.

 

Lucas Paganini (01:12:11.731)

angularforenterprise.com. Okay, that's it. Thank you all for sticking with us for so long in this episode. Have a great week and I'll see you in the next one.

 

Subrat (01:12:24.941)

See you guys, bye bye.

 

Doguhan Uluca (01:12:26.882)

Thank you.