Modern Full-Stack Web Development with ASP.NET Core

Covering the Full Stack

Albert Tanure: Hello, everyone. Welcome to GOTO Book Club. I'm Albert Tanure, a Brazilian living in the Netherlands, working for Microsoft as a Cloud Solution Architect. Today I'm excited to talk with my friend Alexandre Malavasi about his new book. Alexandre, please introduce yourself.

Alexandre Malavasi: Hi Albert. I just wrote my fourth book about .NET, C#, and related topics, and it's a pleasure to share about my latest work here. I have 17 years of experience as a software engineer and have played many roles in the field as an engineering manager, head of engineering, and software architect. I'm also a Microsoft MVP for five years in a row.

Albert Tanure: That's very cool. "Modern Full Stack Web Development with ASP.NET Core" is very impressive. I saw many great things in the book. Can you give some thoughts on your approach? How do you decide what to cover when there are so many complex topics in full stack development?

Alexandre Malavasi: The hardest part is deciding what to cut. ASP.NET, .NET, C#, software engineering, web development, full stack development—it's a large topic to cover. In my latest book, apart from ASP.NET Core and the .NET platform, I decided to cover React, Angular, and Vue.js as well, which made it even harder.

One thing I've learned is that no single resource will solve all problems or cover entire topics. There are other materials that readers can use to complement their knowledge. I'm at peace with that now.

Albert Tanure: Based on your book, what kind of subjects do you think are most important? Is there anything you'd emphasize differently?

Alexandre Malavasi: I covered backend development for API content and talked about security and many other things on the backend side. I decided to include Angular, React, and Vue.js JavaScript frameworks because I didn't have any idea about how readers would like to combine these in terms of full stack development.

If I were to revise the approach, I would learn which JavaScript framework users like most to combine with ASP.NET Core. I know React is the most popular JavaScript framework right now, but I'd want to get a feeling for what works best. I might focus more deeply on a single JavaScript framework to demonstrate the integration with backend development.

Book Structure and Foundation Concepts

Albert Tanure: One of the great things I really enjoyed about your book structure is how you organized the chapters. We always look at ASP.NET and then we have our UI frameworks like Blazor and MAUI. But most of the time, based on the community where we share knowledge and talk to people, they don't realize the power of integrating ASP.NET Core with frameworks like Vue.js and React. It's possible and not so complicated. We have templates for it as well.

I really like the foundation you built in your book. After Blazor, you move into architecture concepts—building the best Blazor applications using architecture concepts, looking at components and reusability. But the other part that I consider the foundation for the rest is when you talk about REST APIs and REST services in parts one and two. Without that, it's impossible to talk about the frameworks you mentioned before.

This structure is very nice. It helped me a lot, especially with React since I'm not a React person. I've worked with Angular and Vue.js. The integration is very good in ASP.NET Core. Which one do you like more: Vue.js, Angular, or React?

Alexandre Malavasi: About the foundation topics and chapters, one intention I had when preparing the chapters was that since we're talking about full stack development, I wanted frontend developers who don't know or don't have much experience with backend to have the opportunity to learn backend. If the reader doesn't have any backend experience, they would learn it. The opposite would be true as well. If someone is 100% a backend developer, they would have the opportunity to learn frontend.

It's a risky strategy because a book usually has a maximum of around 500 pages, which is a lot of content to include. I worked with the three main JavaScript frameworks, but I prefer to use Vue.js most of the time because of the simplicity of the framework. It's not the most popular among the three, but I've launched many releases to production using Vue.js.

In terms of integration between any JavaScript framework and backend, I think the process is quite similar. But if someone doesn't have any experience with JavaScript frameworks, it's hard to learn all three because the way to create components, manage state, and have good architecture differs a lot among them. I would say React is the most complex, then Angular, and Vue.js is the simplest.

Albert Tanure: I agree. React is the most important JavaScript framework for most frontend work. When you mention the foundation, this is what I like most. Before we start working with technologies, it's important to look at the basics and the foundation. Without that, the other topics won't make sense to anybody.

Your book is structured so that whether you're backend or frontend, you're going to learn. Even if I don't want to develop something myself, I now know how it works because I can integrate better with backend if I'm frontend, or with frontend if I'm backend. This full stack approach is way more important than just thinking about isolated topics.

Planning and Structuring Full Stack Projects

Albert Tanure: I agree. React is the most important JavaScript framework for most frontend work. When you mention the foundation, this is what I like most. Before we start working with technologies, it's important to look at the basics and the foundation. Without that, the other topics won't make sense to anybody.

Your book is structured so that whether you're backend or frontend, you're going to learn. Even if I don't want to develop something myself, I now know how it works because I can integrate better with backend if I'm frontend, or with frontend if I'm backend. This full stack approach is way more important than just thinking about isolated topics.

I want to discuss one specific chapter that's important to me: "Planning and Structuring Full Stack Projects." This chapter is important because it's like saying, "Okay, I know the technologies, I know frameworks, but how can I structure an application thinking like a full stack developer?" Should I design? Should I look into pipelines, repositories, strategies?

This chapter shows that now you have the tools, but here's how to use these tools in a real project to leverage the whole full stack process. Give me your impressions. What are the most important subjects you'd like to share with people related to this topic?

Alexandre Malavasi: I covered many topics and JavaScript frameworks with different approaches for doing many things. I would say the best way to decide the architecture of an application—if I have to choose the most important thing to consider when designing full stack projects or any software engineering project—is to look at the expertise of the team.

It doesn't matter if React is the most-used JavaScript framework in the market or if there's hype for Blazor or any other framework. If your team is specialized and has released many products in Angular, there's a tradeoff to judge when talking about choosing specific technologies, whether to use domain-driven design or CRUD patterns, whether to host the application on the cloud, or whether to use microservices. The skills of the team are the most important thing to consider when deciding which architecture and technologies to use.

In the book, I put this in the last chapter because I wanted to mention specific things from my experience managing teams and making business decisions for engineering projects. I would say knowing really well the skills you have as a developer and what your team has is the most important part when deciding which technologies to use. It doesn't matter which technology you use—if you have high skills in it, there's a high chance that project is going to succeed.

Another thing I mentioned in the chapter is the second most important point for decision-making: good architecture involves making something that facilitates the engineering team to change requirements. The only thing we're sure about in any software project is that it's going to change. That's the only thing we know will happen.

We don't know if the project will succeed, if the company will make huge revenue, if the product will meet user requirements or needs in the very beginning. But one thing we have to be sure of as software engineers is that the project is going to change. If we know by experience that the project will change over time, we have to create and build an architecture that facilitates the engineering team to make changes.

There are many good practices about how to make reliable projects, high-performance projects, and other good practices related to technology. But I would say a good architecture decision is one that facilitates the change which is going to happen in the future, in any case.

Albert Tanure: You said something important. You showed how to use three frameworks—or four if you consider Blazor. What's the best one? It depends on your team. It depends on the challenges you have now. Maybe all frameworks fit well, but sometimes one doesn't work for some reason or stakeholder preference. But also considering UI, UX, architecture approach—whether you want to use a monolithic approach or microservices—every decision has tradeoffs. How to manage that and build your application according to requirements is a great mindset for full stack development.

We're not always just delivering an API based on HTTP or a component in the frontend. We're thinking about the entire solution. In my humble opinion, this is an important message for developers because we don't work in silos. When you look at your book, you can navigate into different areas and understand how to collaborate, how to consider the best technology and architecture design. You're preparing developers to look at things this way instead of just learning technologies. As an architect, I can see that sometimes I'd like to use C#, but in some cases, a different language fits better because of requirements. This chapter touches on these items, including project planning and agile methodologies. We're missing content like that.

Design Patterns and Avoiding Over-Engineering

Alexandre Malavasi: This chapter deserves an entire book just about tradeoffs and mentioning real projects and experiences I've had over the past 17 years working on complex projects and facing many problems. In two of my books about design patterns, I included hundreds of disclaimers saying that a pattern needs to be used to solve a specific problem. If you don't have this specific problem, you shouldn't use it.

When I was learning design patterns many years ago—and I still learn because we have many new patterns every year—when I started learning design patterns, I made mistakes as a developer trying to include patterns where the problem didn't exist. I created problems just to have an excuse to use the pattern, or I mixed many patterns because I wanted to use what I'd learned.

This same mistake needs to be avoided by someone who is a backend developer trying to learn frontend development. It's not recommended for someone who doesn't have any frontend experience to learn all three main JavaScript frameworks altogether. It's better to specialize and choose one based on your context.

I mentioned all three because I didn't know the real audience for the book. If readers follow the chapters and do all the step-by-step projects included, they'll be able to create React, Angular, and Vue.js applications. The applications will be running without errors, but it's different from creating real applications to go to market or to production.

DevOps Mindset and Beyond Development

Albert Tanure: I'd like to highlight one topic based on what we've discussed. In the last chapter, you put some important topics that as an architect, I look at and think, "This is very nice." For example, disaster recovery—nobody looks at disaster recovery because it sounds catastrophic. But disaster can be if you deploy something to the cloud with mistakes and break the API so nobody can pay anymore if it's an online store. That's a disaster as well, whether it's cloud or data center.

Also, when you talk about pipelines, deployment, monitoring, and continuous optimization, we're changing minds here. We're changing from a simple developer to looking at the bigger picture. We're not just completing a task and pushing code—we're taking care of our application. Based on data and monitoring tools, you can optimize your application and take care of the whole process.

This chapter is very important. Whether you're frontend or backend, you're creating a DevOps mindset. This is an important topic and we should talk more about it. You could write more books related to it, just on architecture, design patterns, monitoring, and continuous optimization.

Alexandre Malavasi: The main reason for any software engineer to work on projects should be to bring value to customers or to real users, whether internal or external. That should be the mindset for a software engineer. Because of that, I think today there's no space for a developer who doesn't want to learn anything else apart from their specific specialty.

I'm a backend developer, but I know frontend development, DevOps, databases, cloud, and software architecture. I think that's the way to go for any modern software engineer. If you don't know a little about many topics, you're probably missing something that's going to be problematic for projects.

For instance, if by mistake your lack of frontend knowledge leads to making way too many API calls for something that doesn't change often, or if a React application has 45 components on a page with the same data being shared among all 45 components, sometimes you see developers make 45 API calls. That developer isn't thinking about bringing value to customers or about application performance.

There are ways to share data between components to avoid making too many calls. Sometimes frontend developers make these kinds of mistakes because they have no idea how backend works, how expensive it is to process API calls and database queries, and to scale up servers.

It's important to know the whole process of software development from the very beginning—the concept phase, requirements, software architecture, infrastructure decisions—until the point when it goes to production, including disaster recovery and observability. Our responsibility as software engineers isn't just finishing sprints and delivering features. Our real responsibility is to make users happy. That's the way to reach business goals.

Our responsibility doesn't end when we make a release. It's when the application goes to production and we validate that features are making value to customers. Topics related to observability, monitoring the application, and understanding how deployment works—it's not about learning Angular, Vue.js, and React. It's about being a good software engineer with great soft skills as well.

Albert Tanure: I agree completely. There are a lot of things that happen after the push. I wish we could talk about these topics longer because these are way more interesting discussions. But I really enjoyed the book and having you here at Go To Book Club. I'd like to thank you for the book and for joining this session. Please feel free to say your last words.

Alexandre Malavasi: Thank you so much for the opportunity to talk about the book. It's always great to have technical discussions with you, Albert Tanure. I really hope the book adds value to the readers. If you buy the book and enjoy it, please leave a review on Amazon with your opinion because that feedback will facilitate the second, third, and fourth editions of the book in the future. Thank you so much.

Albert Tanure: Thank you.