Writing and Deploying a Database-Backed Website in Less Than 10 Minutes
One way to test your cloud development tooling is to see how fast you can actually get a real application up and running if you start from scratch and don't copy/paste code from anywhere (except memory). How intuitive and easy is it to get from logic around business objects to something that is deployed in the cloud.
I decided to put myself and my tooling to the test and I wanted to share the results. I managed to write and deploy a real database-backed website in less than 10 minutes. The application is a .NET CORE 2.0 application that provides a simple interface for taking notes and storing them in a database. I deployed it in an Azure Web App with Azure SQL Database on the backend.
Here is a video of me actually doing it. As you can see, I am slow at typing, and I make mistakes, but in 10 minutes my app is deployed. Not only that, it is done in way that is easily extended by modifying the object model (and database) or by adding things such as Continuous Integration (CI) and Continuous Delivery (CD).
Below I will walk through what I am actually doing with references to when it happens in the video.
[embed]https://youtu.be/SuiuPM1gxE8[/embed]
Details
This application is very simple. It is a note taking tool that will allow you to enter notes, store them in a database, edit them, and delete them if needed. Each note has a NoteId, Title, and Content. The approach is a Code First approach using the Entity Framework, where we define our application objects in code and let the tooling update the database to match. The basic steps of building the application are (I am not necessarily doing it in that order):
- Creating a new .NET CORE Application
- Adding a data model to that application along with a database context.
- Creating an Azure Web App and a SQL Server.
- Updating the database layout to match the data model.
- Creating a Controller and Views for the Notes.
- Publishing the application.
In the video I have two Visual Studio 2017 windows open and I am managing the .NET app coding in one and the deployment of the Azure resources in the other. I am doing it in the following order:
Creating a new .NET CORE (MVC) application (time: 00:00)
I am not doing a whole lot with the application at this point. I am just selecting the template and letting it create in the background (it takes a few seconds). I quickly switch to my other Visual Studio View to start the Azure deployment.
Creating a new Cloud Azure Resource Group project (time: 00:16)
Here I choose a template, which has a Web App and a SQL Server in it. I could have manually deployed these components through the Azure portal, but doing it this way automatically adds the SQL Server connection string as a setting on my web app and we will use that later. It also illustrates that it can be done from Visual Studio where there are some helpful tools for creating templates. One thing I will note is that this particular template uses some naming convention with unique strings for the SQL Server and the Web App. While that ensures deployment without problems, it is not necessarily my personal preference, so I actually keep a modified version of this template where I have chosen some other conventions. But again, it is a matter of preference and not important for this tutorial.
Adding a Data Model to the .NET CORE App (time: 01:38)
To add a data model (the "M" in the MVC application), I right click on the "Models" folder in my solution and choose Add and Add Item. I select a C# class and call it NoteModel.cs. My typing is slow and a make mistakes, but Visual Studio helps me get through it without too much pain. The final NoteModel.cs looks something like this:
using Microsoft.EntityFrameworkCore;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
namespace WebApplication3.Models
{
public class NoteContext : DbContext
{
public NoteContext(DbContextOptions<NoteContext> options) : base(options)
{
}
public DbSet<Note> Notes { get; set; }
}
public class Note
{
public int NoteId { get; set; }
public string Title { get; set; }
public string Content { get; set; }
}
}
There are two important parts to it. The Note class, which defines the object(s) we would like to work with, and the database context (NoteContext), which we implement by inheriting from DbContext in the Entity Framework. The database context has only one method for getting the Notes, but can be expanded as the objects grow in complexity.
Registering the Database Context with the application (time: 03:57)
We need to register the database context with the application services. This ensures that we have a connection to the database from the different components of the application. In order to connect to the database, we use a database connection string. At this point, we just pull a connection string variable called "DefaultConnection" out of the application Configuration. More on that below. The ConfigureServices function in Startup.cs is modified to look like this:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
var connection = Configuration.GetConnectionString("DefaultConnection");
services.AddDbContext<NoteContext>(options => options.UseSqlServer(connection));
}
Setting up database connection string with user secrets (time: 05:06)
On the web app that we deployed above, the connection string variable will be configured automatically by the template, but for local debugging and database updates, we need to make sure that a) we have the right connection string and b) that we can access the Azure SQL Server from our local development machine. We use the "user secrets" of the .NET CORE app to set this connection string variable. For more information on how and why to use this, see this blog post. In this example, we are taking advantage of the fact that the web app deployed by the template has this connection string set already and we simply copy it from the web app. We use the Azure portal in the browser to do this. While we are in the Azure portal, we also modify the firewall settings on the SQL server to allow access from the current client computer, which is just the laptop that I am using for development.
Using Entity Framework to update database (time: 06:38)
In the next step, I take advantage of the Entity Framework to update the database. It is beyond the scope of this tutorial to go into details on that, but whenever the data model layout changes, two steps should be performed: a) add a migration (code to update the database), b) update the database. There is a lot more information about that in this tutorial. In this example, I use the "Package Management Console" to issue the commands. The bottom line here is tha you do not need to be writing SQL scripts to update your database.
Adding a Controller with Views (time: 07:20)
Last thing we need in the code is a Controller (the "C" in the MVC application) and some Views (the "V" in MVC). I do this by right clicking the controller folder in the solutions explorer and choosing add controller. First I need to add the basic scaffolding and then I can add a controller with views. I need to select which data model object and which database context to use, but then the code is auto generated for me. In almost all cases, this code would need some adjustments, but it gets you started and makes your application functional.
Deploying (publishing) the application in Azure (time: 8:31)
After a quick build to make sure everything compiles, I deploy to the Azure Web App that was created earlier on. In real development workflow, you would probably test it locally on your machine and almost certainly deploy to a testing environment, but I was trying to get there fast.
Testing the application (time: 9:30)
After a bit less than 10 minutes the application is online and I can add notes. If you try it yourself, you will see that you can edit the notes, delete them, and so on.
Conclusions
That is it. It is pretty easy to get up and running with .NET Core, Entity Framework, Azure Web Apps, and Azure SQL Server. There is great support in Visual Studio for these services and with very little coding you are up and running. The only code you really need to write is the stuff that relates to your specific application objects, which is the way it should be.
Let me know what you think and let me know if you can do it any faster with your tool chain.