How all this works: Basic architecture

In my last post about the Daily Parker's new blog engine, I explained why I built this and what it's for. This post will give you an overview of the app's basic structure; that is, the physical building blocks that make the blog happen.

When you point your browser at https://www.thedailyparker.com, the request goes to the front door of a Microsoft Azure App Service, which runs on a server in Microsoft's US East data center, located outside the tiny town of Boydton, Va, on the Virginia-North Carolina border about halfway between Richmond, Va., and Raleigh, N.C. I put this app there because lots of Inner Drive apps live there, including Weather Now.

Once the request hits the server, it goes to a Microsoft Blazor WebAssembly application called InnerDrive.Journal.UI, which sends and receives messages to a stack of other components:

• A Microsoft Cosmos DB NoSQL database that stores all of the blog posts as fully-indexed JSON documents.
• Multiple Microsoft Azure Tables, which are high-speed flat structures that store simple rows of data with only two indices. The tables store information that needs to be written and read very quickly but doesn't have a lot of overhead. The blog engine uses tables for:
  • Audit logs
  • Event logs
  • Indexes
  • Comments
  • Tags
• An Azure Key Vault that stores keys and secrets, so that the source code never does. For example, to read from the database, the application needs the database's secret connection information, so it knows where to look and what password to use. That "connection string" goes in Key Vault.
• Microsoft Azure Blob storage to keep the photos and other files that you see.

Unlike Weather Now, the Daily Parker runs entirely in a single Blazor WebAssembly app. Weather Now uses two: a user interface app, which shows all the data, and a separate API, which stores and processes all the data. That makes it easy for Weather Now to serve its data to other apps. But the way I expect people will use the blog engine is entirely different, so I chose the simpler, one-app approach.

That doesn't mean everything is stuffed into one big executable file, though. The application architecture of the blog splits responsibilities into a collection of small-ish assemblies:

• Core contains the most basic components that every other part of the system uses, like the definitions for Privacy and Accuracy.
• Data defines how the application uses the database and other data structures like indexes. The basic abstraction for the app, the Event, lives here, as do the definitions for Factory and Repository, which represent different ways of dealing with certain kinds of data.
• Blog holds the bits that are specific to blogs and not generally used by other kinds of events. The BlogPost class lives here, as does the BlogPostFactory; both of those things extend their Data counterparts (Event and EventFactory).
• Services orchestrates how those other parts interact with each other. For example, the BlogService has a method to find a blog post by its ID. That code in turn calls the EventFactory.Find method to get the post, but then it calls a several other pieces of code to determine if the person trying to find the post has permission to see it, as well as code to log information to the event log (things that the software does) and the audit log (things that the user does).
• UI uses Services to generate the pages that you see in your browser.

All of this currently runs on .NET 10 and was written in the C# language. Plus, there are a bunch of 3rd-party components, including the Inner Drive Extensible Architecture™ (which I also wrote) that do specific tasks, like time zone calculations and translating the Markdown I'm typing right now into the HTML you see in your browser.

Over the next few weeks, I'll go into much more detail about all of this. But my next post will be about the features I developed for this new blog engine, and why I think they're cool.