Want to Build an Enterprise-Grade App? Tear One Down!

Hello, my name is Nithya Narasimhan. I'm a Cloud Advocate on the AI Advocacy Team at Microsoft. And today I want to talk to you about how you can build an enterprise-grade application by tearing one down.

So you might be asking yourself, why do I need this skill? We've all been here. You might think of a scenario where you've joined a new development team in an enterprise organization, and on day one, you're faced with an assignment where you realize you have a gap in your learning because your team has been commissioned to build a multi-scenario app that is enterprise-grade in conjunction with other teams. And you need to make a decision on the development environment and the design architecture that you want to use. What do you do?

The challenge is that we have a knowledge gap. Most of us, and it's very much like this meme about how to draw a horse, many of us know core concepts. We know building blocks. We've built functional applications that can help us kind of showcase demo things to small audiences. But a production-grade app is like that finished diagram, the finished picture, and between that functional prototype and the production-ready version is a gap in learning, and those small details are missing in all the things that we try to learn.

So, how do we skill up? How do we fill this gap? I want to recommend we do it in three steps. First, find a reference implementation that provides an example of what you want to build. Deconstruct it to learn how they did it and then transfer that knowledge to your own application requirements. So, at the end of this talk, hopefully, you'll know how you can go from having identified your knowledge gap to having transferred the knowledge from deconstructing an open-source reference implementation to your own project.

The first step is to find a good reference sample. I think about it as a three criteria process. First, you want to look for something that's open source because you do want to unpack and look underneath to see how things were implemented. Second, a good reference sample should teach you patterns. You don't want to just implement things. You want it to have something that is transferable. Good design practices that make sense to other applications. And third, you want a use case that provides coverage for the kinds of requirements you have. So, for instance, if your application is going to have an authentication scenario, look for a reference sample that has one, too.

So, in this talk, we're going to focus on Contoso Real Estate. It is an open-source, enterprise-grade reference implementation from the JavaScript DevOx team at Microsoft. Now, Contoso is a fictitious global corporation. And the Contoso Real Estate application builds a reference implementation of an onboarding app for new hires in that org. And as you can see, it's a multi-scenario implementation. It has a content management scenario.

It has a scenario which has two apps, a blog app where admins can fill in blog articles and have those blogs be read by both guests and new hires alike, and a portal app where admins populate the content management system with rentals in the area. And new hires can then use the portal to browse available rentals, save them to their profile, and reserve them for the payment. But most importantly, we knew that we had to design an architecture that could be extended to new scenarios.

So as we get started, what you need to do if you want to follow along is to go ahead and create a copy of this, fork the repo and use the URL that I've given in the text below. That's because this reference implementation is actively under development, so I want to make sure you have a stable branch, so look for aka.ms slash Contoso hyphen real estate, hyphen react, hyphen summit, hyphen 2023. Uncheck the main branch box so that it's actually copying over all the branches, and then look for the react summit branch in your fork. At this point, we are ready to start deconstructing.

The very first thing you want to do is understand or answer the question of development environment, how should we set up our development environment? In our reference implementation, we advocate for GitHub codespaces or rather for a devcontainer environment. So let me quickly show you what that looks like. So when you fork the repo and switched to that particular branch, you want to go look at the code dropdown and start a new codespace. In my case, I already have one running, so I dropped it, and you can see that I have one running, and when you launch it, it takes a little bit of time, but when you're done, you're actually going to see something like this.

So as you can see, you have what looks like a Visual Studio code experience right in your browser, but it's connected to a runtime environment that can actually run this application for you. So let's take a look at what a devcontainer is. So in this particular case, you're gonna learn two things. First, a devcontainer is a Docker container that runs in the cloud in the case of GitHub codespaces, but the pattern that you're going to understand is that it uses configuration as code. That environment is defined by a devcontainer.json file that you can check in along with your code base. You can version control it, you can modify it, you can share it with others. And what it does is ensures that anyone who uses this project is set up with the exact same environment in which they can build, debug, and deploy.

Once you've done that, this is optional, but I encourage you to install GitHub Copilot Chat, and I'm sure you're going to show you really quickly why that's useful. So what GitHub Copilot Chat does is it provides an AI assistant, but that AI assistant is sitting right in VS Code. So in my case, I've already installed it, and when I click on this, I get a chat assistant right in my VS Code experience. And what that means is when I'm stuck with a particular question, so for instance, I can ask it, what is GitHub Codespaces? And instead of going out from this to Google and then coming back and context switching, I ask it right here and it gives me a response in context, but it can do more. I can ask it, so I can use things like commands, like explain and say explain what this does, right? But now what it's doing is it's actually taking this and looking at the file that you've got open here, which is devcontainer.json and saying, oh, let me explain what this does, which is it's a dev container. And now you can actually, and it combines the two and follows the software, but you want to understand the benefits of code spaces. So what you've got is an AI assistant that stays in line with your flow, but also has the context for what you're working on in your development environment and can customize its responses to help you. And as you can see over here, you can not only get it to explain things, you can get it to generate code, you could get it to fix code, simplify it, create notebooks, create workspaces, and also just freeform queries or instructions. So now you have your development environment. You know that your code is already there. What can you do? Next, we want to build and preview the app right there in the browser to validate the fact that that reference implementation actually works for our needs. In my case, I already have that running and you'll notice that in the instructions, it tells us how to get started building and previewing it.

And what you need to do is fork the repo, start GitHub Codespaces, then run NPM install and NPM start. I already did that here. And what that gives me is this set of ports that show you all these different services started up. And we can see, we have a portal app and I can actually launch this portal app and preview what that looks like. Note that that's running in a dev container, but when I actually click on it, it forwards that port and I can see it in the browser in my development device, in my local device.

Here's what the Contos experience looks like. So I'm a guest user. I can browse listings. So I can go in and look at a particular listing. And let's just say that I'm kind of gonna go in and see a spacious family apartment, right? Now to reserve it, I can go ahead and login. This particular stage, it's actually using an emulator because we can allow testing in our local environment. But you can see that now I have an authentication token that's been used. And over here, I can go in now and try to book one of these apartments. So let's say I pick some kind of a renting period. Let's say I plan to go in for the new year, right? And I can try to reserve this down. And when I do that, you can see that the reservation is complete. I can go to my reservations. And now my reservations history shows that I just made a new reservation for January 15th to 30th. And I can see that my payment history shows that I just paid for it. Wait, there's one more thing. I can also go into the listings and I can browse them and save something. So maybe a charming apartment close to the train station. And when I do that and go back to my profile, it's saved. So you can see that we have a fully functioning experience right here in the browser, launched from the development environment that we've set up in Codespaces. So we're already more than halfway there.

What can we do next? Now we're going to talk about the design architecture. You notice in our use case that we had multiple scenarios. So here's how that architecture allows us to prioritize the scenarios, build a blog first, then add the portal, then add authentication, then add payments, then add search and so on. And Composable Enterprise is a pattern that's driven by an API-first design. You start by building your API specification first and use OpenAPI, and then you can allow the teams to go off and build their components against this API without having dependencies on each other.

And the interesting thing in this that we want to look at is how this architecture gets mapped. Can you actually deconstruct it to figure out how it gets mapped to the content in our code base? And you can see that quite clearly as the documentation tells you, because we're using a mono repo since we have multiple teams, and now every one of those scenarios is mapped clearly to a package in our code base.

Then let's go to the last step in the process. We've done all the development, now we wanna deploy it. So over here, I'm actually just gonna play this video because we don't want to really deploy to Azure, but this is the last thing that you're gonna take away from deconstruction. Deploying a complex multi-scenario app is not easy. You need to provision the backend. And you can see here, we're using a command called azdprovision. You need to provision the backend or your cloud with all the resources you need, and then you need to deploy your application and set up a CI-CD workflow so that every push to production is actually updating that deployment. I'm gonna speed through this in the thing of interest, but you can see that there's an azddeploy, and by the end of this, we now have a running application in the cloud.

But why did I bring this up? Because AZD is Azure Developer CLI. It's a unified tool that simplifies your deployment from the code space to the cloud with one tool. And it's driven by another pattern, infrastructure as code. In your code base, you will find an azure.yml file that describes the resources and configuration for your deployment to Azure. AZD looks at this YAML file and is able to automate that process for you. With that, we come to the end of this talk. If I did my job right, you should be able to see how you can now transfer this knowledge to your own user scenarios. Set up a monorepo, use Devcontainers for a consistent development environment, design for composability with an API-first approach, activate GitHub copilot so you have help to kind of figure out how things work. Deploy with AZD if you're deploying to Azure. You can find out more about the other items on that list. This is what we learned today, but I leave you with three resources to look at. I have to compress what is essentially a six hour video series into 10 minutes. I encourage you to go look at the Learn Live link where we deconstruct this application step-by-step over four episodes from our initial design all the way through deployment. And I hope you have fun deconstructing your next open source app. Thank you.