Read time: 8 minutes
I hope you have been enjoying the newsletter issues so far, but starting today I’m switching to a different format.
No more tutorial-like issues since they take more time to make than I can afford these days. Also, this and future newsletter issues will no longer get published on my site but will only arrive by email.
From here on I’ll use the weekly newsletter to tell you about anything interesting I’ve been working on so hopefully you can learn from my learnings.
So, what have I been working on?
A new .NET bootcamp
For my upcoming .NET Bootcamp, I was originally thinking of creating an updated version of the PlayEconomy system I built for the .NET Microservices program.
However, many of you told me you’d prefer to see how to go from the small CRUD-based system I cover in my .NET REST API Essentials and Blazor Essentials courses and take them into a full-blown e-commerce system.
So I took on the challenge and I’ve been building this new system for the last two months or so.
As I build this I’ve been diving into a crazy amount of new tech, patterns, and challenges that I had not faced even in the PlayEconomy system, which has been lots of fun and frustrating at times, but very rewarding in the end.
This is why I always tell folks that the best way to learn tech is to build something, end to end. Learn, fail, learn more, fail more, and you’ll end up with tons of new skills that you can’t get from just reading books/tutorials or watching videos.
The new e-commerce system so far
The new Game Store system I’m building has a few similarities to the popular eShop Reference application, which I have been exploring in-depth.
It’s a nice reference system, and it covers many topics and patterns. But the problem is that:
- It leaves many doors opened (Where to create products? How to actually take payments? Where is the inventory? Etc, etc.)
- It uses some tech/patterns just for the sake of showing off them (you don’t need gRPC there)
- Seems like the main focus was on migrating the older eShopOnContainers system to .NET Aspire, not on rethinking the system architecture itself
So I’ve been taking several learnings from there, but I’m building a brand new system that extends my small Game Store application into an e-commerce system that uses enough tech to solve real problems.
This is how the Game Store system architecture is looking so far:
I won’t go into the details of what’s going on there today (it’s a lot), but I’ll start diving into each piece and how they relate to each other in future newsletter issues.
As usual, my focus will be on the .NET backend, but I strongly believe you can’t build a backend without a meaningful frontend. After all, the main purpose of a backend is to serve the needs of some sort of frontend, right?
So I’ve been upgrading the Blazor frontend presented in Blazor Essentials to enable the multiple e-commerce scenarios that the backend is meant to support.
I’m not good at frontend stuff, so I looked for inspiration at a few actual game stores like these:
And, so far, with lots of help from ChatGPT and Copilot, I have come up with this:
It’s 95% Blazor Static SSR, with a few sprinkles of WASM in essential places. I’ll dive more into this one too in future issues.
Here’s also a sneak peek of the current source code structure:
That structure will most certainly change dramatically once I get all user scenarios complete and start moving to a proper microservices code structure, where each microservice lives in its own repo.
Current progress and where I am today
I have the following scenarios working currently:
- Game catalog management, with search and pagination
- Product image upload and display
- Storefront games display (also with search and pagination)
- Authentication and authorization via Keycloak (OIDC)
- Shopping cart
- Checkout with Stripe integration for payments
- Order creation and management
- Order workflow orchestration via a saga
- Game codes inventory management
- Automatic refund due to out-of-stock (compensating transaction)
Works pretty well, but I’m looking into switching from Stripe Checkout to Stripe Elements, which I think is a much nicer integration, especially given all the microservice interactions we have to account for in the backend.
And, beyond that, I still need to figure out:
- The right time to clear the shopping basket
- How to notify the customer of their order completion
- Adding external auth providers (maybe)
- How to liberate data across microservices
- API gateway integration
- Caching and CDN
- Azure deployment
- Integration testing
- CI/CD via Azure DevOps
- Observability
So, lots of exciting learnings to come.
But there’s one more thing I’ve been working on.
.NET Aspire Keycloak component
The entire system is connected and orchestrated via .NET Aspire. And, as I tried to integrate Keycloak, which is used for OIDC, I noticed there’s no Keycloak support in Aspire yet.
So I built my own Keycloak component by learning from a few examples I found on the web. Later, I decided to contribute what I got to the actual .NET Aspire project (because why not) and I’ve been working on this PR for the last month or so.
I must confess I completely underestimated how much work it would take to drive this to the finish line, given the tons of feedback I got from several members of the ASP.NET team.
In fact, I’m still working on a few more comments. It’s a bit frustrating since the component works just fine already, but, as usual, PR comments are an amazing way to learn and grow, especially when they come from the awesome ASP.NET team.
Closing
So that will do it for today’s update. Let me know if you have any feedback on what I’m trying to build there and things I might be missing.
Until next week!
Whenever you’re ready, there are 2 ways I can help you:
-
.NET Cloud Developer Bootcamp: Everything you need to build production ready .NET applications for the Azure cloud at scale.
-
Promote yourself to 20,000+ subscribers by sponsoring this newsletter.
