DealsAdept
A deals site that found, published and announced its own deals.
A deals site that found Amazon offers every day on its own, published them, and announced them on social media and through browser notifications. One admin panel ran all of it. It worked for several years, and it is paused now.
Ran for several years · paused
Paused. The WordPress site is still up, but the app no longer runs inside it, so there is nothing to link to.
01
How it's built
- C#
- .NET 6
- Blazor WebAssembly
- Blazor Server
- MudBlazor
- Refit
- MediatR
- Azure Functions
- Azure Static Web Apps
- GitHub Actions
- SQL Server
- EF Core
- Dapper
- Hangfire
- ASP.NET Core Identity
- Azure Blob Storage
- Web Push
- WordPress
Three parts: a WordPress site, the public app inside it, and an admin behind it.
- The public app: Blazor WebAssembly on .NET 6 with MudBlazor, embedded in the WordPress site as a frame. It called its API through a typed Refit client.
- The API and the daily run: Azure Functions, hosted on Azure Static Web Apps and deployed by GitHub Actions. A timer-triggered function collected the day's deals.
- Amazon: a client for the Product Advertising API written by hand, including AWS Signature Version 4 request signing, searching by keyword, category and browse node.
- The admin: Blazor Server with MudBlazor, layered into domain, application and infrastructure, with CQRS through MediatR. Hangfire ran the background jobs on SQL Server, and ASP.NET Core Identity handled sign-in.
- Data: SQL Server through EF Core, with Dapper for fast reads and Dapper Plus for bulk writes. Azure Blob Storage for files.
- Announcements: posts to X over OAuth, posts to Meta, and web push notifications signed with VAPID.
02
The trade-off
The app sat inside the WordPress site as an embedded frame. Search engines read the page around a frame, not what is inside it. In return, the two stayed apart: WordPress kept the pages and the blog, and the app could change without touching them.