Meowv/Blog is a running blog that doubles as a .NET and ABP tutorial

A blog that is really a course on building one

The project description is explicit about its purpose. There are different development versions, the newest is built on abp vNext and the free and open source cross platform framework .NET5, with MongoDB storing the data and Redis caching it. The project is developed in a front end and back end separated mode, the API follows RESTful conventions, the pages are built with Blazor, and it can serve as an introductory .NET Core project for learning.

That last clause is the one to hold on to. This is a reference application with a working deployment behind it, not a product. The homepage is meowv.com, and the README links three live sites: the web project at meowv.com, the admin project at admin.meowv.com, and the API project at api.meowv.com, with screenshots of each in light and dark themes for the web and admin sites.

The reason to publish a running application rather than a set of snippets is that the pieces interact. A repository layer, a migration job, a cache and a JWT protected API are things that are easy to get subtly wrong in isolation, and seeing them wired together in one solution is the actual teaching content. The documentation lives at docs.meowv.com, and the article index is a set of write-ups, in Chinese, that follow the project from an empty directory to a deployed one.

The licence is MIT, with the file at the repository root, and the last push was on 2026-07-28.

Ten projects in one solution, and three of them are deployed sites

The solution file in the repository root, meowv.blog.sln, holds a set of projects that map onto the layers of an ABP application. The tree in the README is the clearest description of the architecture.

     ├── Meowv.Blog.Application ---------- Application
     ├── Meowv.Blog.BackgroundWorkers ---------- BackgroundWorkers
     ├── Meowv.Blog.Core ---------- Core
     ├── Meowv.Blog.MongoDb ---------- MongoDb
     ├── Meowv.Blog.Response ---------- Response

Three of the projects are the deployed applications. Meowv.Blog.Web is the web project at meowv.com, Meowv.Blog.Admin is the admin project at admin.meowv.com, and Meowv.Blog.Api is the API project at api.meowv.com. The rest are the layers underneath: the application layer for the use cases, Core for the shared domain pieces, BackgroundWorkers for the scheduled work, the Response project for the shared return model, and Meowv.Blog.MongoDb for the database side, plus a DbMigrator project.

The separation is what makes the REST claim meaningful. The API project is a separate deployable with its own domain, the web project is a Blazor front end that talks to it, and the admin project is a second front end over the same API. The Response project is the reason the API can be described as unified, since the write-up series includes a step on unifying the API with a wrapper return model.

For a learner this layout is the point. It shows the same split that a large ASP.NET Core application tends to arrive at, with the exception that the DbMigrator is a separate project rather than a command, which is the ABP convention.

MongoDB for storage, Redis for cache, and a migration project

The stack is specified in one line of the description and it is a deliberate choice rather than a default. The newest version uses MongoDB to store data and Redis to cache it, which means the persistence layer is a document store rather than a relational database, and the caching layer is an explicit one rather than an in-process cache.

The write-up series walks through that stack in the order a developer would hit it. The listed articles for v3.4.0 run from setting the project up with the abp cli, through slimming the project down so that it actually runs, adding Swagger, and moving on to data access with a code first approach. There is a dedicated step on a custom repository with create, read, update and delete, and another on unifying the API with a wrapper response model, followed by a second Swagger article on grouping, descriptions and the lock icon for the authorisation header.

Authentication is covered in its own step, integrating GitHub sign in and protecting the API with JWT, and that is followed by exception handling and logging. Caching data with Redis is a later step, and then the scheduled work, with an article on integrating Hangfire for scheduled job processing, one on object mapping with AutoMapper, and a three part series on scheduled job best practices.

The database side has its own project, Meowv.Blog.DbMigrator, which is the piece that makes the code first approach work. With a document store and code first mappings, the schema is derived from the model classes, so something has to apply those changes to the database, and that is what the migrator project is for.

The article list is the documentation, and it stops where the project stops

The article index in the README is long, and its shape tells you what kind of project this is. There are thirty linked write-ups for the v3.4.0 line, and they are not a reference manual. They are a narrative, ordered by what you do rather than by what exists.

The first group is the build itself: creating the project with the abp cli, trimming it so it runs, and adding Swagger. The second group is the data layer: data access with code first, and a custom repository with the four CRUD operations. The third group is the API surface: a unified response model, then Swagger grouping and documentation. Then authentication with GitHub and JWT, exception handling and logging, and Redis caching.

After that comes the asynchronous side, with Hangfire, AutoMapper and three articles on scheduled job patterns, then a five part series on the blog API, then a nine part series on Blazor, and finally an article about publishing the project.

The v4.0.0 section, by contrast, is two words: a to do. That is an honest and useful signal about where the project stands. The current branch covers the v3.4.0 line with a full series of articles, and the next line is announced rather than delivered.

The README also states the versioning arrangement plainly, with a note telling you to switch branches to see the different versions. So the branches, not the tags, are the history, and the repository publishes no GitHub releases to sort that out for you.

The alternative is a single monolith, and the difference is what you can reuse

The realistic alternative to this project is not another blog engine, it is building the same thing as one ASP.NET Core application with a single project, a controller per entity and views rendered on the server.

The difference in approach is the separation of the API from the front end. In the monolith, the UI and the data access share a process, share a transaction boundary and share a deployment. In Meowv/Blog, the API project exposes REST endpoints that three different clients consume, the Blazor web site and the admin interface being two of them, and the API project itself is the third deployable, at api.meowv.com. The same API serves a public blog, an admin console and any third party integration.

The trade is in the number of moving parts. A monolith is one process, one configuration file and one database migration path. This solution needs MongoDB and Redis running before anything works, a separate migrator job, a JWT issuer and a GitHub OAuth application, and the deployment of three applications. For a learning project that complexity is the lesson, and for a product it is a cost you would probably not want to pay.

That is also why the description calls it an introductory project. The value is that every layer is present and small enough to read in an afternoon, rather than that it is the way a blog should be built.

The Blazor series is the largest part of the curriculum

Nine of the thirty write-ups for v3.4.0 are the Blazor series, which tells you where the bulk of the front end work sits.

The Blazor approach in this project is the one the topic list names, blazor-server, and the pages are Blazor components that call the REST API. The split between the two is what the front end and back end separated mode means in practice: the pages hold no database access and no business rules, they are a client of the API project, and the API project is a client of MongoDB and Redis.

The Blazor series runs from the first practical article through to the ninth, and the final article in the whole list, 终结篇之发布项目, is about publishing the project, which is where the deployment of the three sites is described. The structure of the list mirrors the order of the work, which is what makes it usable as a course rather than as a set of reference fragments.

For someone evaluating the project, the practical reading is that this is a .NET learning resource that happens to be a working blog. The blog is the vehicle. The three live sites, the code first data access, the JWT protected API and the Hangfire background jobs are the substance, and each of them is a piece of machinery that a real .NET Core application needs and that most tutorials only show in isolation.

Editorial conclusion

Meowv/Blog fits a developer who wants to see a complete.NET Core application, with the API, the admin, the background workers and the database migration in one solution, and who prefers learning from a running system over a tutorial that stops at the controller. It is the wrong choice as a foundation for a production blog, because it is presented as a learning project rather than a product. Verify first which branch corresponds to the version you want, since the documentation index stops at v3.4.0 with the v4.0.0 section still marked as a to do, and expect to follow the Chinese write-up series rather than English reference documentation.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Meowv/Blog on GitHub
4. Project website
5. README