The Modern .NET Show
A blurry image of source code, too blurry to read, take the place of the background. Layered over that are the headshot of Irina Dominte and a purple robot holding a microphone; these are on either side of the centre of the image. Above both is the heading 'THE MODERN .NET SHOW' in bold, white text.

S06E02 - From Junior to Jedi: Navigating the Web Development Galaxy with Irina Dominte

Embedded Player

S06E02 - From Junior to Jedi: Navigating the Web Development Galaxy with Irina Dominte
The .NET Core Podcast

S06E02 - From Junior to Jedi: Navigating the Web Development Galaxy with Irina Dominte

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

Irina Dominte, who has taught .NET to individuals transitioning careers or domains, emphasizes the importance of focusing on the basics and avoiding overwhelming beginners with too much information. Drawing an analogy to language learning, Irina highlights the need for a gradual approach that doesn’t discourage learners. Building a solid foundation is crucial, just like a house requiring strong foundations to stand tall.

One major challenge faced by junior developers is the fear of making mistakes or incurring high costs when experimenting with cloud providers. To address this, both Irina and Jamie propose the concept of a “playground” or safe learning environment where developers can freely explore different cloud services without any consequences. This approach would create a space for hands-on experience, thereby boosting confidence and encouraging learning.

The conversation shifts towards the evolution of technology, specifically the transition from .NET Framework to Modern .NET. We stress the importance of staying updated with modern technologies rather than focusing on outdated ones. We also aim to change the perception that .NET is solely for Windows by highlighting the cross-platform capabilities of Modern .NET.

Irina recently published a book on web development and API design, in which she covers essential topics ranging from setting up the development environment to advanced concepts such as model binding, API versioning, and testing. The book takes a simplified approach to make the content accessible and avoid overwhelming readers. It focuses on HTTP as the protocol for APIs, as many developers fail to leverage its full potential.

We stress the significance of guiding beginners towards a specific solution rather than overwhelming them with numerous options. They liken this approach to using Google Maps, where users prefer a clear route to their destination rather than being presented with multiple routes to choose from. Thus, the book focuses on presenting the author’s preferred methods and approaches, providing readers with a clear understanding and contextual knowledge of the concepts.

Episode Transcription

Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie “GaProgMan” Taylor.

In this episode, I spoke with Irina Dominte about web development and API design. Irina offers valuable insights for beginners, the conversation covers topics such as building a strong foundation, learning cloud technologies, adopting modern technologies, API design and development, the importance of testing, and choosing the right approach. With practical tips and a simplified approach, this episode provides a wealth of knowledge for those looking to excel in web development and API design.

Yeah, so I never done a fully Rest API in production. To be fair to me and to the book, a real Rest API is the API that actually respects the REST constraint - the four of them, not the six of them. So it has the first constraint as being the client server architecture. There is two entities involved, the client and the server that need to talk to each other. And then we have statelessness like we’re using HTTP we shouldn’t keep state as we used to do with older versions of .NET. So everything should be self contained in that specific request or response. Why not? Okay, so then we have the cache. Your resources should be able to be cached like the server marks the response as being cachable, the client understands and looks at the header and so on. So state machine-wise using the right verbs, right?

- Irina Dominte

Plus, we discuss the recent release of Irina Dominte’s comprehensive book on the subject - Web Development for Absolute Beginners - and why it’s an essential purchase for anyone wanting to learn how to create web-based APIs with Modern .NET.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So, Irina, thank you ever so much for spending some time with me this afternoon. I really, really appreciate everyone that comes on the show to talk about some stuff, and we’re in slightly different time zones, as is always the case with me, but that’s fine. I’m the one who has to deal with that. That’s not a problem.

But yeah. Thank you very much and welcome to the show.

Irina : Thank you for having me. It’s pleasure.

Jamie : You’re very welcome. You’re very welcome. So I wonder, would you mind telling the listeners a little bit about yourself? Like an elevator pitch or something, just to get us started, just so that then everyone knows a little bit more about Irina.

Irina : I’m a software architect working as a consultant with a passion for teaching and public speaking lately. And of course, I love everything around .NET. I’m a Microsoft MVP for developer technologies, and for about five years I discovered that I like to public speak and write articles around .NET. Not as often as I would like to, to be fair, but I have several drafts, 100 of them, that are waiting still to be finished and published. But it’s not an elevator pitch. I don’t like to talk about me, but I think this sums it up.

Jamie : Sure.

I know the pain of getting a blog article finished and ready to release is real. It’s very much like software in that it’s never finished. My own experience is 2015 through to 2018: I used to write about .NET things, and then .NET core started to be a thing. So I pivoted started writing about that. And the main reason why this podcast started was because in the early months of 2018, I was like, staying up until three and four o’clock in the morning going, “should that be a comma or should it be a full stop? I don’t know.” And so I didn’t want to do that again. That’s what I’m saying.

Irina : So true. It’s hard to find first to find your right words to explain a concept and then just find the right phrasing for it and the code to exemplify it and so on. It’s not easy.

Jamie : It’s not. And the people who can do it on a regular basis, thumbs up, all power to them, because I just can’t. I found that I was writing like one and a half thousand words every two weeks and code samples to go with it, and I was like, “It’s not for me, I can’t do this.”

Irina : Yeah, I guess that’s why I have so many drafts. I start, that could be a good article, interesting for someone, but then I just stop. Or I don’t have the time to get to it, or I will have to admit it, or I don’t find it to be as, quote unquote, perfect as I would like to be. So it never gets published.

Jamie : No, I fully understand that, absolutely. It’s not something for me, that’s for sure. I find it easier just to talk and then hire an editor, and then he can make what I say vaguely sound human. It’s fine.

Irina : I guess that’s why I have 100 drafts, because I never find the right form for an article or I don’t find as I like it to be. And then I say, “okay, this won’t be published anymore,” so it stay and dies in draft mode.

Jamie : Sure, I understand that. I also feel as though it’s probably more of a thing from maybe two, three years ago, but I felt like there was this big push before everyone was sent to their rooms. We don’t talk about the events that happened over the last few years. We just use metaphors.

But before “the event when everyone was sent to their bedroom,” I found that there was a lot of, like, “oh, you must create loads of content, and it has to be out there because otherwise no one will know who you are.” And there was this big drive for “just create the stuff, create the stuff, create the stuff. I don’t care if you’re staying up till 03:00 in the morning, create it.” And it’s not for me.

Irina : Indeed, it is hard to publish a piece because it’s not meant for everyone to do it. I mean, let’s face it, there are some people good at, I don’t know, talking and stuff, presenting and writing a thing. It’s a totally different area.

Jamie : Totally.

Irina : And we’re not supposed to be good at everything, right?

Jamie : Absolutely right. We’re supposed to be the specialists. That’s what we are. We’re the experts. Right? That’s that old YouTube video, The Expert, that comedy sketch. That’s what we are. We’re not the generalists, but what do I know?

But speaking of which, you’re saying that you have trouble with getting things published. I mean, you’ve just written a book, so you can’t have that much trouble.

Irina : Yeah, well, I said to myself that I’m going to do something important while on my maternal leave. I have a small kid, two years old, little girl. So I said, I’m going to try to combine the career and the motherhood and stuff like that. And it has always been on the back of my mind that maybe since I teach and one thing that I didn’t tell about me is that in my spare time, I’m also teaching .NET to people that are trying to switch careers and get into IT. And I teach C# and well, .NET because that’s what I like to teach about.

So twice a year, five months, I’m doing these classes. And I said, “why wouldn’t I do something that is useful for these people or to people that are trying to, I don’t know, switch domains? They’re working in It, but they did mostly desktop apps. I don’t know mobile whatsoever, and they’re trying to learn Web.” So then is when I decided that, “okay, I’m going to write a book on this,” and I proposed it to my editor and they agreed that it’s a good idea.

So I’m looking forward to see if indeed it’s a good idea and if people are actually I’m looking forward for the feedback on that.

Jamie : Excellent. Yeah, I have full respect for anyone who finishes writing a book. I’ve had a couple of different ideas in my head floating around but I’ve never actually been able to find the discipline to actually sit down and do it and I don’t have small little ones who demand my attention all the time. So full respect to you.

Irina : Oh yeah, I’ve been spoiled to be honest, because I had my in-laws, I had my husband help me, and since the beginning of the year I had the little one going to daycare. So I had like a full job, eight hours for me to write the book and indeed it was a task that I heavily underestimated. So if someone would come to me and say, “hey, write a book on this, I would never do it again."

But yes, I finished it because I don’t like to leave things unfinished. But it wasn’t an easy task since I underestimated everything.

Jamie : Sure, yeah.

I have been told that it’s not something you do with I can’t even think of the word with a lack of respect for the amount of work that goes into it. Right.

Because unlike in software, there is an actual deadline, right. We can always sort of grumble about “oh well, maybe we need another few weeks to fix this and there’s a little bit of tech out there.” But when it goes to print and it will be printed onto dead trees, there is no software patch you can fire out there and release. So yeah, it’s a monumental task of getting stuff done.

Irina : Exactly. And it’s there to stay. So it’s on print, your words are there written.

Jamie : That’s true. But then of course you can the say to the family," look at what I did and show them the thing that you did," right?

Irina : And I’m going to frame it on my wall, across my desk.

Jamie : Don’t blame you at all. Don’t blame you at all.

So what is the book then? And what does it cover? Because we’ve talked a little bit about it and we’ve talked about how you do teaching in your own time and help people get started with .NET, is it .NET? Let’s start there.

Irina : Yeah. So basically I’m trying to provide step by step path into learning web and web API.

So I’ve taken an approach that I’ve used previously with my students. I’m trying to keep it just bare minimum, not overwhelmed the reader in this case. And I tried and I hoped I actually managed to do that in the book. I tried to keep everything as simple as I could with simple examples easy to understand because switching careers or switching into web from other sides of the IT world, it’s not an easy task to do. And to be honest, whenever I’ve seen, I don’t know, 1000 pages books, IT books. It’s daunting to see them. I mean, it’s like a chunk of paper. Like, okay, go ahead and read that. Well, I might start, but I might not finish. So that’s what I’ve tried to avoid, basically - heavily written, I don’t know everything.

Jamie : Sure.

Irina : And I’m covering the basics like Web API, introduction to web, how you set up the environment with everything in .NET.

And then slowly I’m speaking about what are the Web APIs building blocks. Then we’re moving into working with an ORM what it is, stuff like that. Then slowly organizing our code. We’re talking about routing middlewares. And then we’re slowly progressing to, let’s call them advanced concepts. But those concepts are not advanced. I don’t know. With 15 years experience in IT, those might not be advanced, but in the book there are advanced for people that are just trying to learn a thing. We’re talking about model binding API versioning, documenting your API and testing the API, which is a thing that I’ve seen it very often as being “not important” in the projects I’ve been through.

Jamie : Sure.

I fully appreciate - sorry to interrupt you there. I fully appreciate the idea of “let’s not write a book that’s a million pages long and that is a foot thick,” right? Because it’s very daunting as a beginner of anything to be presented with this textbook and say, “read this from cover to cover and you’ll get it right.” We each have a whole bunch of experience with programming and programming languages and all sorts of stuff. So we were able to apply the knowledge from one framework and one language to another pretty easily.

But I remember at university I took Japanese language and the very first day, the teacher plonked down this massive textbook and said, “right by the end of the second year, we’ll have covered all of that.” And I’m like, “this is scary. This is a thing that I could hold open a door with this book. It could be a doorstop.” It’s not good to receive a huge amount of information all at once and say, “just work your way through it.” So what I’m trying to say is I really appreciate that you’re thinking about the reader, thinking about the amount of time and effort that someone can realistically put into this and saying, right, “how do I produce something that is the right amount of information, but in a format, I guess, that is accessible and easy to make their way through?"

So I just wanted to say that, right? Because that’s something that I feel like a lot of tech writers forget about. They’re like, “I’m going to brain dump all my stuff. It’s going to be 5000 pages and you’re going to love it.” And then people pick it up and read the first ten pages, then put it back down and never read it again.

Irina : Indeed, I’ve seen books where each chapter could have easily been another book.

So one thing I learned from my students is the amount of information that you give them so they feel overwhelmed whenever they’re finding, I don’t know. Some of them told me, “hey, I started uni. I didn’t want to continue with uni, but then I started to learn on my own and I started to find resources on the Internet. And I clicked around and clicked around and it seems like I would never stop. So I don’t know which information I have to keep and which information is like, I don’t have to know that and so on."

One thing that I learned from my students is that you do not have to know everything. So if you’re focusing on learning Web API, in this case, you might as well just focus on that. Any other thing around that can be like a building block to use afterwards. So I don’t know. I do not need to know maybe about Blazor if I’m learning Web API right now, when I know about Web API, yes. Then I can choose another path and learn about Blazor or [.NET] MAUI or any other thing that is connected to it. But until then, let’s just keep it simple; focus on the minimum things that we really need to know.

And at the end of the course, my students have one goal: either to get a job in IT, either to manage very well into the IT world, like get a job, or switch jobs and stuff like that.

So some of them have told me, “hey, it has been very easy for me to learn all the things that you gave me when you taught me, because I know for sure, I don’t have to worry that you need to know about that. And that might be a good candidate for me to know because you know exactly what people will ask at interviews."

So for C#, right? So you need to know the language, the basics. Okay. Any other syntactic sugar on top of it can be learned after, you know, the basics of C#. Basic instructions like, I don’t know, operator if else, loops, stuff like that. If you want to know, I don’t know, pattern matching stuff. records. Yeah, you first need to know some object oriented programming, right? And then, I don’t know, sprinkle some sugar on top of it. But the basics needs to be there. And that’s what I tried to do in my book, just the basics.

Jamie : Sure. And that makes sense, right? Because you can’t build a house without good foundations. And I’m a bit of a metaphor person, long-time listeners of the show will know this, but yeah, if you don’t have good foundations for your house, your house will collapse and everyone will be upset. And you can’t have a knowledge base to work from without good foundations.

And so you’re right, if I want to learn patent matching, I’ll need to learn some other stuff first because I need the background context to learn the other stuff, right? It’s like learning any language, right? Because effectively you’re learning the language that the computer speaks, right. Once you’ve learned the grammar, aka the syntax, if else if switch that kind of thing. Once you’ve learned that, you can literally do anything. It’s just a matter of learning the vocabulary. And I feel like pattern matching is kind of like a vocabulary more than syntax. But what do I know? I think I’m stretching a metaphor a little bit too far here.

Irina : Another thing that I want to add in here is that there is this side in .NET where you are using a repository pattern or you’re using the DB context, you’re using underscore notation for fields or are you using this? So there is like, “my way is the best way and your way is the wrong way.” So I chose in this book to use my way and to not care about what different side of IT are saying, just because I realize there is method in my madness.

So I’m trying to use this across the book and I keep using this pattern, for example, just because it gives the reader a context awareness that the underscore notation doesn’t: if you use this, so it’s a state that’s inside the class and that’s why I keep using it. So during the writing of this book, I kept having polls on Twitter, “hey, what do you prefer? This or that and this or that?” So I did a market study, but I chose my way in the end just because it helps people learn step by step. So if you’re using this, it’s very easy afterwards to use the underscore and so on.

Same with are you splitting your project into libraries or are you using just single project and you’re having folders? Well, what if we start from the basics, have plus libraries, each one of them on its own boundaries and stuff like that, and then knock yourself out, right? Have one project, folder and so on.

Jamie : Sure, yeah.

I’ve recommended in the past a number of tutorials for people who want to get started in development. And then they’ve come back and said, “but it’s too complex,” because these tutorials that I’ve recommended have said “they’ve gone down a path and said, okay, let’s learn this. But now let’s take a step back and say, but actually, you could do it this way. And then take another step back and say, but actually you could do it this way. And then another step back and say but you could do it this way,” then another one and you could do it this way." And I’m like, it’s great to know that there are other ways to get there, but the important thing when you’re learning something is to get there, right?

If I pull up Google Maps, I don’t want it to tell me there are 450 different routes to the place I want to go to. I want it to help me to pick a route and help me get there. Because I feel like it’s very complex, our industry. And it can be complex to sort of learn it, especially if there are twelve different ways to achieve the same solution. And for some reason, the person teaching wants to teach you all twelve ways. Well, if you’re right at the beginning, you don’t have the knowledge and the experience to figure out, “well, why are there twelve ways and which one is the best?” Right? Because there isn’t a best.

Irina : Indeed.

So I recently got a question from a young developer, like junior developer, two years experience, and he asked me, “hey, could you host API, like a full API itself in Azure? Is it hard to do that?” And at first I was baffled. How could he ask me that? But then I realized that poor guy had worked only with Azure functions and he had no overview about how things work. So, like, the bare things, like have an API deployed somewhere, and then Azure function being a smaller API that, well, has different things. I don’t know, like consumption plan when it runs, stuff like that. So the bare thing, the minimum thing was, okay, you have an API, you developed it. How do you expose it to the outside world? So Azure or a virtual machine or whatsoever.

I was lucky enough to be able to, I don’t know, grow a bit with the industry in the last 15 years. And I hosted in Windows machines and I got into RDP on those and stuff like that. But the young people didn’t have that. So they might have an incomplete picture about how things work in a system, in a distributed one. It’s hard for them to understand, especially when the are given just small pieces of work. Like, you do this, you need to implement this to do that. Okay, cool. But the complete picture, they won’t ever have it because there will be no one to tell them, “hey, look how you do this, how you implement that, and how in the end, your code will be up and running in Azure or whatever, AWS.” that’s what I tried to follow in the book, step by step. This is how you do it. If you sprinkles on your code, yes, you’ll be able to do that.

Jamie : Yeah, yeah, I appreciate that because who was it? It was Maslow, the same Maslow who came up with the Maslow's hierarchy of needs. If listeners are into psychology and things like that, he was the person who said that, “when everything you have is a hammer, everything looks like a nail,” and it sounds like this person you were talking about because they only had the experience doing Azure functions. “How do I turn? You’ve given me this thing with 4 million files in it, and azure function is one file with one method. How do I go from this to that?” I totally, fully, 100% appreciate that.

And I think that, like you said, I think that we are lucky in that we’ve been around for long enough that we’ve seen things evolve to the point where we know where things need to split off. And because of that, we’ve been to conferences, we’ve watched the training videos, we have the background knowledge that you’re trying to impart that will infer within the person: this needs to be an Azure function, this needs to be a web API, this needs to be X thing, all that kind of stuff. But that’s because we also have the experience of going, “well, let’s go to Azure, let’s go to GCP, let’s go to Linode or whatever and click around and let’s see what I can make.” Whereas I feel like perhaps, maybe and I might be casting aspersions here and making things up, but I feel like maybe when you’re at the beginning of the career and you’re still learning it and there’s so much to learn, there might be this fear of, “if I start clicking around in the cloud provider that we’re using, I could run up a huge bill and get into loads of trouble. Or I could get into a position where I break things."

And I feel like that’s a little unfair to put that situation on our juniors and the people that we work with. And I feel like perhaps it’s a different discussion for a different time, but I feel like perhaps there should be, like, almost like a playground. Wrong word, but like a place that developers who are at the beginning of their career or who want to learn a new thing can actually log into it and just click around and just I want to push loads of buttons and there’s going to be zero consequences.

Irina : And see what happens.

Jamie : Absolutely, yeah.

Maybe I have a different learning style to the people that you are teaching. I don’t know. But I do know that with some of the cloud providers they do offer training systems. This is more to do with like Linode and things like that, where you can literally sign up. Linode isn’t one of them. I’ve said them about 15 times now. I do apologize, but you can sign up to it and they give you like a virtual machine to connect to and they say, “right, follow these instructions and learn the thing. And now that you’ve learnt it, let’s just play around and see if we can break the virtual machine. Don’t worry, we can’t break the virtual machine, but if you click over here, this will happen. If you click over there that will happen.” Which I think is really quite useful and I think perhaps that’s missing from the training stuff that is created for juniors.

Irina : But I think also that is more related to, I don’t know, the core concept. I mean, the junior developers are using tons of cloud services. They know about cloud, maybe a thing that maybe I didn’t knew when I was their age, but they do not know the basics. Like, okay, you have this thing how this thing magically goes there and runs and stuff. So, like, low level maybe knowledge or experience, not necessarily knowledge around the things that we do. And it’s core to us. Right. We do not think about those things when we’re doing those because we know them by heart.

Jamie : Sure.

Irina : But they don’t know.

Jamie : Sure.

Yeah, you’re right. I think there’s a difficult decision for people who are way smarter than me. And that needs to be a decision of, “how do we help these folks to do this?” Because things have gotten so easy. I remember the first time that I published anything to Azure, it was a case of, right, I need to do all these hundreds of steps and get permission from this person and drag this thing in and do that. And actually now inside of Visual Studio - I don’t use Visual Studio these days, but if I’m using Visual Studio, I can right click and push a button and then 30 seconds later, a minute later, my app is there, which is great for that first initial getting started. It’s not great for the whole DevOpsy pipeline stuff, but that’s stuff that you can learn later, being able to right click and get it running in front of you and be able to send a link to someone and say, “hey, check it out, I made this thing.” That’s the best feeling. Right?

Irina : The tooling is awesome nowadays. I mean, I remember a time when I logged into the server and I keep moving DLL files to the machine and restart IIS and stuff like that because well, those were the times.

Jamie : Yeah, those are still the times with some companies. I won’t name names.

And you know what? Whilst it’s not brilliant compared to how we do things in more modern paradigms, if it still works, then and if you’re still happy to take the risk of what if someone deletes the wrong file and is unrecoverable, then that’s totally fine. You do you, it’s just not for me. Excellent.

Okay, so you want to get people started with Web API in .NET. So I guess the important question is, are we talking .NET Framework? Are we talking .NET core? Are we talking .NET 6, 7, 8+ - the thing where I’m calling Modern .NET, where does it sit?

Irina : It sits with .NET seven. Because I do not wish the .NET Framework to die, but it’s old and we evolved so much since the first release of .NET Core. So now, to me, .NET Framework is just an old reference that we have to talk about whenever is the case. But the modern apps should be using .NET Core, whatever the version long term support being. It it should use .NET modern version.

Jamie : Sure. And I suppose for someone jumping in, learning the slightly older technology would not be a great first step, right? Because if I do a Google for “how do I do model binding in .NET?” it’s not going to be .NET framework that comes up, is it?

Irina : No, the is no point learning something that won’t be used. I mean, it is used, but it is used in a few companies that have big projects, expensive to change and stuff like that. And I mean, C# is an older version with .NET framework, the tooling won’t be so great. So why not start with something that it works in a browser. You can play around in the playground, Try .NET and you’ll have there the C# console running.

Jamie : That’s one of my favorite things to do is to point people try.net. Try .NET. Yeah, right.

Irina : Drop the dot.

Jamie : Yeah, I think I dropped an extra dot in there. But yeah, try and then a period dot, period .NET. And it’s fully working in your browser. There’s a lot of things you can’t do, but it’s a great place to actually try something out and you don’t need anything other than a browser. And guess what? Almost every operating system ships with a browser. I had to say almost there because there’ll be certain Linux distributions that don’t. So I don’t want to get the pedantic people upset, but yeah, almost every I’m pretty sure it’ll work on your phone too. So you don’t even need a computer. So that’s pretty cool.

The thing is, I feel like much like with what you were saying about syntactic sugar, you can learn the other things once you’ve got the basics right. C#, it has evolved quite a lot since the .NET framework days. And .NET Framework, as far as I’m aware, I mean, I am an MVP, but I’m not on the inside track. As far as I’m aware. .NET framework isn’t going anywhere, right? It is still here to stay. It’s not being killed off, it’s not being jettisoned, it’s not being anything like that.

I actually side note, I actually talked to Scott Hunter at MVP Summit this year and apologized to him because there was an episode of this show that went out where someone took a quote out of context and said, “the sky is falling, .NET framework’s going away!” And it’s like, no it isn’t. And yeah, he got a lot of flak for that. So I actually went up to him and went, “look, Scott, I’m really sorry. This is what happened. It was four years ago, but I’m still upset about it and I want to apologize to you.” He was like, “dude, it’s fine. So that’s pretty cool."

But yeah. So the point I’m getting at is that you can totally, in my opinion, learn modern .NET and then if a project comes up where you work, where you have to do some .NET framework stuff, it’s a case of cool. I know the modern .NET stuff. How do I learn the retro .NET stuff?

Irina : Sounds very good. Retro .NET?

Jamie : Yeah.

Irina : To be honest, I’m still preaching the fact that .NET it’s not just Windows any more. I don’t know how long it will take to teach people in I don’t know, the IT world that hey, “when you say .NET, you’re not saying implicitly Windows.”

Jamie : Yeah. I think though, that’s maybe a thing it will take a time to change, I think. But I think that’s more because how many things do you have to do at work? We got to do a whole bunch of stuff, right? And I feel like you and I are a little bit different to most devs in that we’re creating content, we’re putting stuff out there, and we’re relying on the people who are excited about it enough to learn it in their own time to then know what the new stuff is.

So I fully appreciate that there’s lots of people who don’t know that .NET is cross platform and that’s totally fine. But that means that I can then go to them and say, “cool, come over here and check this awesome thing out!”

Irina : Let me tell you a story.

Jamie : And it’s on Linux. Yeah, right. Let me tell you something.

Because I remember one of the first builds of .NET core that I was playing around with. I was doing something on a Windows machine and I was like, “cool, I don’t get the point. It runs on my Windows machine.” And the I copied the files onto a USB, moved over to my MacBook Air. It was a 2011 MacBook Air, so it was an intel chip and all that kind of stuff. Plugged the USB in and I was like, try and install it and see what happens. And I was like, “holy moly, it runs like this is .NET on a Mac. And I’m not doing anything with mono. This is just weird."

So yeah, I totally appreciate that. That’s because I was excited about doing that. Some people don’t have the chance to do that outside.

Irina : About that, it was very interesting to me and I kept talking about it when I hosted APIs as Linux services. I was like, “oh my God, we’re able to do that. Look how it works.”

Jamie : Yep.

A Request To You All

If you’re enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I’d really appreciate it if you could indeed share the show.

But if you’d like other ways to support it, you could:

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let’s get back to it.

Jamie : Well, I mean, I’m going to bring him up again, but hopefully this will get his attention. He’ll be on the show. But Scott Hunter, in the very first ASP .NET stand up that they did back in 2014; it was Scott Hunter, it was Damien Edwards, it was Scott Hanselman - I nearly said Scott Pilgrim then - Scott Hanselman and the were talking about, we’re going to try and get this .NET vNExt it was called. We’re going to get this going. This is the thing we’re working on. And I believe it was Hanselman said, “but why? Explain to me what we’re doing, “right? I mean, obviously he knew he was using the Socratic method. He was pretending to be the audience. And I will remember it, I remember it to this day. Hunter said, “Linux servers, linux servers. I want you to be able to run your apps on Linux servers."

And that’s where we are now. And it makes perfect sense, right? Azure has a whole bunch of Linux servers. Why can’t we run our .NET apps on them? Boom, now we can.

Irina : One of my top performing articles was about running an API as a Linux service. I was amazed how many people have looked that up.

Jamie : Fantastic. Fantastic.

Okay, so if we come back to the book for a moment then; you said earlier on that eventually in the second half of the book, I believe it was, you get onto ORMs. So does that mean that you’re going to cover databases as well? Or is it just a case of, “hey, put this code here and magic and then database”

Irina : I didn’t wrote about, okay, what’s an actual database? Like how to normalize databases, stuff like that, that DBA is supposed to do. But I’m talking about Entity Framework Core. Of course. And we’re starting with a database already made and we import it in our code and then we do the other things around and stuff. So just to show how things would look into a real environment.

But I’m not talking about our foreign keys and concepts whatsoever, but I’m showing that, “hey, since you’re having an API that you’re exposing, you might as well have a storage to store data somewhere.” And I’m using SQL Server because it’s easy to do. And once you have Visual Studio installed, you have everything you need in there. The default instance is there. You will be able to access it and you don’t have to install too many things and to configure.

Jamie : Sure, that makes sense.

And the I guess it then becomes an exercise for the reader. “Hey, you finished the book, you’ve learned some stuff. Let’s move your app to a Linux machine or a macOS machine and we’ll talk a little,” this can be an exercise for someone once they finished the book, they can be like, well, how do I move it? Well, guess what? If you learn a little bit, just a little bit about Docker, you can then put a SQL Server container inside of inside of Docker and then run your app on. Or, you know, if you want to change a few lines, if you want to take the time to learn which lines to change outside of the book, you can change it. So you’re running against a SQLite database or a MariaDB or some database on the cloud or whatever.

So I guess you’re right there. It sets people up with the here is the base level of knowledge that you’ve got to pick one technology. You’ve got to pick one out of all of them. So we pick the one that has the most support the most documentation, and then if things go wrong, you can go to look that up, and then it’s, “hey, you could do it this way, or you can do it that way. If you want to go over there after you’ve finished, you want to go learn how to do MariaDB well, guess what? There’s a whole page of the stuff that you will now understand because you now understand all the content in the book."

Yeah. I like it.

Irina : Because all of the concepts can be reused, or most of them at least. So you’ll need a connection to a database. So no matter the database, there are a few things that you’ll need. So how to configure in the API or how to access connection string and stuff like that. Those are reusable, so it will be very easy for the reader to look it up. “Okay. Maria DB, RavenDB, or whatever, DB will be modern at some point,” so it’s easy for them to do this exercise.

Jamie : Sure, sure. So we’ve got an API, we’ve got a database. Are we doing unit testing?

Irina : Yes, we are doing unit and integration testing.

Jamie : Okay.

Irina : Yeah. So during my lifetime as a developer, I’ve seen a lot of projects where the unit tests weren’t important because they wanted us to develop functionality. They trusted us. We had manual testers to functionally test the application, so they didn’t need us to spend time in writing unit tests. But then they discovered static analysis tools, and they wanted coverage and stuff like that.

So, to be fair, in my projects, where I work as an architect, unit testing, integration testing, it’s a must. There are pillars of good quality code, so you cannot do without them.

Jamie : Totally. Totally.

My own personal yardstick is I always, at the very least, sometimes when I’m working on Greenfield stuff, I’m like, “let’s write tests for everything as much as I can.” Maybe not test driven development, but at least tests for stuff. And if I’m walking in on a pre-existing project, a brownfield project, I’m like, “right, okay, give me a bug, and I want to write a test which proves that the bug exists, because then I’ve got a regression test,” right. Or maybe prove that I fixed the bug, whichever way around. Right. And I think those are in a brownfield project. My own personal opinion, those regression tests are way more important than proving that the system works the way that you think it works.

Irina : Yeah. So in the book, I’m covering, like, full flow, like, controller, fully tested, just to give the user a sense of how things would look like in production. And then I’m leaving the reader implement the other sides because they need exercise. You won’t get better at programming just by, I don’t know, reading a book or just looking at some code. Just practising makes you better.

Jamie : Sure. And then I guess once you’ve got there, I guess it will depend on the kind of reader, but I guess once you’ve got the basics of how to write a unit test down, you can go, “wait, hang on. So does that mean I can unit test this thing and that thing and those things,” and then you just sort of apply the same knowledge, right?

Irina : Yeah. And I also talk a bit about what kind of testing we have available, what kind of tests there are out there in the wild, and then move on to do an integration test. Because those are, to me, at least, the ones that cover an API, as it should be covered, like, entry point to the end, see what happens. Test everything, mock everything around, and it will give you trust in your code. I think that for a beginner, is lacking.

Jamie : Sure.

I’ve heard this. I don’t want to say fight, but it is that juniors and apprentice.

Irina : Debate?

Jamie : Yeah, okay, debate, let’s call it a debate where everyone remained absolutely, totally calm and the shouty voice didn’t come out at all. Well, of course it did. Where I’ve talked to Apprentices, I’ve talked to Juniors, where it’s like, “no, seriously, spend 30 seconds and write a test. You’ll thank me tomorrow when you don’t have all the context and the code doesn’t work. And then obviously, that then becomes, what do you mean the code doesn’t work?” And I’m like, okay, I’ll tell you what, write it without the test and talk to me tomorrow. I’ve been doing this for a while. I know what’s going to happen.

Irina : I mean, let’s be fair. When we have, like, simple cruds, create, read updates, deletes and stuff like that, it might be easier, and it might not be so obvious. Why do we need them? But once you’re testing business logic, heavy business logic in there, that becomes paramount. Again, start with the basic things and then evolve.

Jamie : Yes, 100%. Because a friend of mine calls it crunchy-business logic. It’s the business logic. It’s the transform part of the ETL or any of those things. Right? It’s that part where you’re taking some data in one format and applying some rules and creating data in another format. That’s the bit that can go wrong. And when it goes wrong, it’s not just a case of, “whoops, there’s a bug.” It can be, “oh, goodness, the company has closed because we’ve lost $10 million.” Let’s write a few tests.

Irina : And also, it gives you a focus, because when you need to mock a thing, then you need to think, “hey, what do I send here? What is the expected value from that?” So then it makes you think twice, and then you might realize that your business logic is a little bit flawed sometimes. Happened to me.

Jamie : Sure. I agree.

Okay, so we’ve got an API, we’ve got the database we’re talking to it with entity framework, with an ORM. So you’re explaining what that is. We’ve got some testing in place. Are we HTTP or are we gRPC or are we some other acronym that’s just been made up.

Irina : Yeah. So while I love gRPC, the last year has been on my workshops that I’ve been giving at conferences, my talks. I study about gRPC because it’s an alternative to let’s call it HTTP ReST APIs. And I really love the topic, but the book covers only HTTP because I realized a lot of developers, even experienced ones, are not using the HTTP protocol at its full power. And everybody says that they’re developing Rest APIs, but in fact they’re just using developing HTTP over sorry, JSON over HTTP. So it’s a different thing.

I like to do this exercise in my talks at conferences. Sometimes when I get the context, the right context, I ask, “hey, whoever developed the Rest API?” And everybody raises their hands. And afterwards I talk a bit and explain some things and then, “okay, now really, honestly, who here develops Rest APIs?” And nobody raises their hand. So to implement a Rest API as Rest supposed to be, is very hard. And sometimes I’ll be fair, it doesn’t add too much value. So the focus is for the reader to learn about HTTP protocol and to build on that, to understand the verbs, to understand status codes, and to use them.

Jamie : Again. That makes sense, right? And it goes back to what we were saying earlier on about how there’s years of supporting documentation around the book. You can Google for, “what is an HTTP ReSTful service,” and you get the list of verbs, or, “what does HTTP status code 419 mean?” And Google will tell you. In fact, if you go to think it’s HTTPstatuscodes.com or something like that, or http cats or something.

Irina : Exactly.

Jamie : Right. It’s all documented, it’s all there. So if you’ve hit something that you maybe shouldn’t have done, you can look it up. Oh, cool, there it is. Right. Whereas I feel like even though gRPC has been around a while, it’s still like it’s catching up. It doesn’t have that 15/“20 year plus backlog of documentation. And let’s be honest, SEO.

All that stuff.

Irina : That’s why I like to talk also about gRPC. I started talking about Rest HTTP and then gRPC, because gRPC is a tech that is here to stay also. And once we know about the technology, then we can make informed decisions. Okay? We are having APIs. Awesome. We have two APIs that talk to each other. Cool. What do we use? Do we use HTTP clients? Or maybe it’s better to use protocol buffers and a gRPC? So it depends, like any good architect would say, right? It depends. But for the user, the one that starts to learn web API and web, it’s paramount to learn HTTP one, so then it can learn about HTTP two entry and to learn how the things are getting transported over a specific protocol.

Jamie : Sure, absolutely. And then it’s immediately applicable. If you’re brand new to the okay, so I’m going to go on a bit of a rant here. Climb on top of my Soapbox:

This is my worry with things like coding boot camps because they seem very specific to a very specific niche of a problem. “You’re going to learn React and you’re going to do everything with Node and you’re going to use this particular library. That particular library, these versions of these libraries.” I’m not saying React, Node or JavaScript are bad at all. That’s not what I’m saying. I’m saying that you could say the same thing with .NET. Right. “You’re going to learn .NET 7 and you’re going to use these particular libraries and that’s it. Once you’ve done that, you’re in the industry, you never need to learn anything ever again.” And the something goes wrong or a version is updated, a package is updated to a new version and the API changes or something like that.

And I feel like teaching folks things that are immediately applicable, but then they can actually sit there and “wait, hang on. But it’s doing the same thing as my browser is doing, except the browser is doing get requests for a lot of stuff. Wow. I can see how this fits automatically.” And I feel like with software development, it’s something that doesn’t really fit with other types of learning. Like if I go and learn mechanical engineering, I can immediately apply what I’m learning to how my car works, right. I start understanding that the pistons in the engine move up and down and compress a bunch of air and fuel. And then that’s ignited, which pushes the piston up, which is then transformed into circular motion for the wheels, right. I can see it. If I take the bonnet or the hood off of my car, I can literally see it happening in front of me.

But with software, not so much. It’s all arrangements of little opaque boxes.

Irina : There is a quote I think, “the only constant in software is change."

It’s always evolving. So we need to keep up. We need to always update ourselves in terms of know how. Even though some of the concepts might be reusable and they are reusable. I mean, let’s look at gRPC. Well, in a way gRPC is replacing WCF; it’s kind of SOAP but prettier. So there is a debate and discussion that we could start around it, but some concepts tend to resurface from time to time. So once you know a thing, you’ll be able to at least, I don’t know, adapt your previous knowledge to the current things.

Jamie : Sure.

And I think that’s the important thing to impress upon people who are learning new stuff. And that is: you’re going on a journey. You’re starting to learn this one thing in this one specific context. But like you said, you can apply that to other things. You can learn C# and .NET and then you can say, “hey, I want to go learn Python.” Well, guess what? Both languages are a C-family. They’re both from the C family of languages. So if you know one, you can apply some of your knowledge to the other, and all you need to do is learn - so you’ve been taught the .NET way to program. .NET. Then when you go over to Python, all you need to do is switch your brain over to, “how do I learn the Python way to write Python?” Not the syntax, not the commands, not the vocabulary, none of that. It’s, “how do Python people write Python code?” Which testing libraries do they use? Which ides do they use? They may even use a different keyboard. I don’t know. I’m not a python vev.

So all those different kinds of things, you learn those and you’re still applying that same programming knowledge from one language into another. It’s brilliant.

Irina : Yeah. And one thing regarding this, I like to say that once you know C#, you’re halfway into knowing JavaScript, because the syntax is so similar. So the look and feel is pretty much the same, I could say. So what you have to know is the JavaScript specificity, the small bits and stuff like that, or if you working with TypeScript, it’s easy to translate. I don’t know. C# ish in JavaScript, so it won’t go to waste, your knowledge.

Jamie : Sure.

I always tell people that it’s never a waste of time learning something. You can always apply it somewhere, right. And that’s why I do a lot of reading outside of development. I don’t actually read that many development books every year, maybe one or two. But most of my reading happens outside of it. So like leadership books, business books, self help books, language learning books, because we’re learning languages, right?

Irina : Yeah.

Jamie : And it makes sense that you’re going to learn about how the language, like human spoken languages work, because we design computer programming languages to be halfway between a human spoken language and a computer spoken language. But I’ve digressed way too much. But there’s never a penalty for learning something. That’s what I always tell people.

So we talked about how you’re using HTTP, and we talked about ReST stuff, and you said how in your talks you always get people to put their hands up. Yeah, I’ve done a ReSTful API. But then you talk a little bit more and you say right now that you know what a Restful API actually is. Who’s done a real ReSTful API. So let’s talk a little bit about that.

Irina : Yeah, so I never done a fully Rest API in production. To be fair to me and to the book, a real Rest API is the API that actually respects the REST constraint - the four of them, not the six of them.

So it has the first constraint as being the client server architecture. There is two entities involved, the client and the server that need to talk to each other. And then we have statelessness like we’re using HTTP we shouldn’t keep state as we used to do with older versions of .NET. So everything should be self contained in that specific request or response. Why not? Okay, so then we have the cache: your resources should be able to be cached like the server marks the response as being cachable, the client understands and looks at the header and so on. So state machine-wise using the right verbs, right? There is also a thing. So the uniform interface for me is the fourth constraint that should be in a Restful API. So we should be able to identify resources and should be able to manipulate them, right, using the right resources. So four of them, I mentioned the last two of them, but I’m not emphasizing the in the book.

An API, an endpoint of the API, should be clean enough, should be easy to understand, right? If you look at an endpoint, you should be able to use the right verbs if you have cats, right? So you will have cats and you’ll look at the endpoint, you’ll automatically understand, okay, this is the endpoint that deals with cats being the many of them. So what you’ll be able to do is to query the endpoint. You should be able to use .NET to get all the cats, you should be able to filter them using query strings, so on. You should be able also to create a new resource, right, to add a new cat. And then if you look at the individual endpoint, you’ll have the cat’s by ID, right? So cat the ID placeholder and then you should be able to use three verbs to do operation on the specific endpoint.

These are conventions, but these are conventions that are there to help us create endpoints that are easy to understand, people won’t need, I don’t know, extensive documentation to call our endpoints, right? So I’m keeping this to a minimum, I explain a lot, I have schemas in the book and so on, but I think at that level, these are the things to be concerned about, right? You have HTTP, use everything, use headers to identify things that are different, use header to cache, use header to maybe transport and send information that are not, I don’t know, it doesn’t belong in query string or in the body of the request, stuff like that. Use the right verbs because those are there to stay and use the right status codes. That’s why we have like 64 of them, right? Just to be able to look at those, to see, “hey, it’s 404, what does that mean?” Well, it starts with a four, that means that is your fault as a client and specifically it’s not found because that’s what 404 means. Or it’s “a 201. What does that mean?” It starts with two, it’s a success one, but it means created and it should be returned as a result of an operation that adds a new resource, right? Created. Hey.

So that’s how I pretty much explain Rest as a concept. And I think this is how it’s just my personal opinion, but this is how Rest should be looked at just as guidelines around creating APIs that are mindful to other developers and to API consumers, basically. Because I personally lived the time when I had to read Soap documentation to understand what should I send in there to get a response, a valid response back. But those times have passed, and we should just be able to create easily create endpoints that are meaningful. Right?

Jamie : Sure, absolutely. Just using a couple of examples that you shared there, I’ve been brought in to work on maintaining a “Restful API” where there was a get, you would go to /cats/get and send a get request, and I’m like, that’s not Restful. Oh, yes, there was a /cats/create. I’m like that’s not restful. And then there was a /cats/delete. That’s not restful. And then there was a /cats/get/cached. And I’m like, Are you even trying now?

Irina : The thing with different representations based on, I don’t know, maybe headers that are sent, like Hypermedia’s Mime type sent to the server, and then the server looking at the request will be able to “okay, what do you want? Okay, you want this specifically for a specific vendor that has a specific logic? Yes, here it is.” But everything should be self contained. So some people might say, “hey, Rest is not all about naming.” No, it’s not. But we can also start from there and move on using the right verbs, using headers as a means to transfer information to the server and back. Why not caring about whatever is transported in the header, taking into account content, type and accept? Because that’s why they made it into the spec.

Jamie : Sure. So I guess then, is it even possible to go full Rest? Not ReSTful, but full rest. Maybe that should be a are you “Restful or full Rest?”

Irina : Now that you mentioned it.

Yeah, I think it is possible. But one thing is lacking around libraries. I found it very difficult to implement the HATEOAS part. Basically, the server should be able to drive the client, right? And with each response, it should be able to say, “h"ey, you’re here. These are your next steps. You can go to this specific URL or to this specific URL. You choose, but these are the only two options.” Yeah. So the client should be like, let’s call it “dummy” but it should be able to look at those links sent with the response to be able to navigate the server. I found it lacking in terms of libraries that help you do that because, well, the community didn’t invest in it because it haven’t seen the value of it, I think.

Jamie : Sure.

Irina : Some of our colleague developers are saying, “we’re not doing that because it’s performance penalty to send with each response a section with links to allow the client to specify where to go next.” So that’s one thing that I think it’s lacking in terms of libraries.

Jamie : So my question to those folks, and it’s a genuine question, I’m not making fun. What kind of thing are you doing? Where the performance will be negatively affected by adding a couple of kilobytes, maybe even a kilobyte of extra text, right? What are you doing?

Irina : The actual generation is a bit of a mystery.

Jamie : Yeah, well, like I said, I’m not making fun. I’m interested to know what those particular folks are working on that requires that to be able to squeeze that extra little bit of performance out. And I don’t know, I’m digressing way too much here. Do you think that hateoas? Hateoas? I’m always confused as to how to pronounce it.

Irina : Yeah, me too. But that’s why I say hate O-A-S.

Jamie : Is that the only way to be properly ReSTful, then? Because then it’s returning some stuff and it allows you to but then you said as well, that really it depends on headers that you include and saying the server saying, “hey, I am accepting this kind of data in.” So maybe there isn’t a “one process fits all” when it comes to being Restful or fully ReSTful.

Irina : For sure, there isn’t one size of Rest API. But to be fair, I personally believe that the first four constraints are the most important to me. Those mean that we’re actually leveraging the HTTP power, right? So if we use everything that HTTP as a transport has: headers, media types, we use them properly, status codes, verbs, as they should be. Because I remember a time when create and update, like Azure operations were done using post. So when MVC first started, I think, and I remember the code very clearly, we had a denominator. If it had an ID that was different than zero, then it was an ID edit, right?

Jamie : Yeah.

Irina : So if it was zero or nothing, well, then you are creating an entity. So that’s how we differentiate these two operations. I think this is how we should look at Rest or Restful APIs, leveraging the HTTP power using what we have available, basically, sure.

Jamie : I think that just comes all the way back to, “using what you have in your toolbox, but knowing what’s in the toolbox.” And so therefore it comes down to education, right?

Irina : Yes, indeed.

Jamie : So go buy the book.

Irina : Thank you.

Jokes aside, before the pandemic, I had to talk about Rest APIs. And when I started doing that, I was, okay, who’s going to listen to me? Who’s going to care about Rest? And I was surprised how many people didn’t know things about Rest and they were interested to know and to learn about Rest because Rest as a concept is it was misunderstood and not so well implemented.

Jamie : 100%. It’s one of those things where when I create brand new things, like in my own time, I think to myself, well, hang on, should this how do I put it?

I feel like there’s this leap towards, don’t worry about it, we’ll create an endpoint and then we’ll figure it out later. And actually, no, you’re saying that the contract for your app doesn’t matter, when actually it’s the contract that’s the most important thing. How something else speaks to you is the most important thing. How you deal with it doesn’t matter. Because one of the things that I do when I’m building brand new apps, if I’m just returning data, I just return an in memory list because I’m like, it’s not going to change until I get to the point where it needs to change, until I’ve figured out what that contract should look like. Without knowing what that contract looks like, it doesn’t matter how I get the data. I can fix that later. Let me work on the contract first. Get that contract working, because then when that API then looks the way that I want other people to see it - that was a really bad sentence, but hopefully you get what I mean. When it looks the way that it needs to look for other people to use it, that’s when I can actually go, “right, okay, the contract is sorted. I will go and work on making the other side of it, my bit of it work out.” But the problem with that is that that then requires you to step away from the fun bit, which is making your code work.

Oh, gosh. So, Irina, and just remind us all about the book because we’ve said all of this and we haven’t even talked about what the title is. So remind us about the book and how people can get it, and then tell us a little bit how people can get in touch with you.

Irina : Yes. So they are free to contact me on Twitter. I have my DMs open. The book is on Amazon. So “Web API Development for the Absolute Beginner: A Step-by-step Approach to Learning the Fundamentals of Web API Development with .NET 7”. Super long title, but it speaks to the point. So web API development for the absolute beginner. The book is already available pre order. It it’s on Kindle, available also, and on paperback.

Jamie : Amazing. Okay. It’s available pretty much everywhere.

Irina : Exactly. And I’m looking forward for the feedback from the community on this. So I encourage them to give me feedback because it might have a second edition.

Jamie : If you can find the time between raising the children and doing the work and writing the book. And it’s a lot of work. It’s a lot of work.

Like I said at the beginning, my hat, we say in British English - I don’t know if it translates, but “my hat is off to you.” All respect to you, because I can’t do that. But, yeah. There you go. Awesome.

Irina : Thank you.

Jamie : Well, thank you very much for sitting with me this afternoon and having a chat with me. I’ve really enjoyed it.

Because there’s some stuff that I’ve learned specifically around being fully ReST or ReSTful. Like I said, that’s probably a talk title, right? So get that written down quick before someone else steals it. Coming soon to a conference near you. But there’s things about being ReSTful and being fully ReST that I didn’t really contemplate. And so I’m going to actually go away and fix a bunch of my APIs, make them a little bit better, add some extra headers and stuff like that.

So, yeah. Thank you ever so much for sitting with us this afternoon and talking with us about being brand new, the readers of the book being brand new to web API, because you see, I’ll let you speak in a moment, but I’ve just had this brainwave. It is so important, no matter where we are in our learning journey, to take a step back and look at the things that are aimed at people who are maybe a few steps behind us, a few steps lower than us in our journey. Because there will be gaps in your knowledge, as I’ve just proven right, the stuff about ReST I didn’t know. So there will be gaps in your knowledge. You can totally go read something that is aimed at someone who has slightly less experience, slight less knowledge than you, to fill in those gaps, because why not?

Irina : Thank you for having me. It was a pleasure to discuss.

Jamie : You’re very welcome, very welcome.

Thank you very much.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest, Irina Dominte, for graciously sharing her time, expertise, and knowledge. Make sure to check the full show notes for a collection of links and lots of background information that Niels graciously provided to all of you, as a place to start your journey in learning about performance-based programming.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via our contact page, or join out discord server at dotnetcore.show/discord - all of which are linked in the show notes.

But above all, I hope you have a fantastic ReST of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places