Home
The Internet Safety Plan is an all-in-one, parent-focused platform for managing a healthy and safe internet environment at home. This project was originally planned to be an app, but I since pivoted and created the Internet Safety Plan website. The purpose of this repo is now just to highlight my development capabilities.
Since I do not have a deployed demo instance yet, this Wiki serves as a walkthrough of key aspects of this project and the skills & knowledge I gained from doing this. Feel free to jump to any section that is of interest to you.
This app was created based on my love of helping parents keep their children safe and responsible online and a desire to provide broader support than I could through one-on-one consulting sessions. I built it with a strong intention of having it become an actual, sellable product, so I was very careful to build it with clean code and solid architecture. Here's a quick demo of the frontend:
Internet.Safety.Plan.Quick.Demo.mp4
The vast majority of the code was written in 2022 before the original release of ChatGPT, without any AI assistance. Various snippets of functionality and project design decisions have been taken and modified from online tutorials, Stack Overflow, AI chat prompts (for more recent development work), etc., but I have been solely responsible for adjusting it, QA'ing, and implementing it.
There are a few key coding practices that I wanted to follow throughout this project that I felt would provide easier long-term development, cleaner code, less bugs, etc.
Inspired by Eric Evans' "Domain-Driven Design" book, and an earlier version of Steve Smith and Julie Lerman's Pluralsight course, this repo exemplifies DDD implementation.
Before writing a single line of code, I started by spending a lot of time building a solid domain model, and ended up iterating over it many times as I ran it through different examples and use cases (and can always change in the future as needed). The app has a single bounded context with 5 Aggregates, listed in the InternetSafetyPlan.Domain project. It also has a variety of Value Objects - including Email, Nickname, and Description.
The Application project implements CQRS and has separate commands and queries for each Aggregate.
As implicitly mentioned above, the project utilizes Onion Architecture to implement Domain-Driven Design. The onion has the following layers:
- Core/Domain: The source of the domain structure and all associated business rules for each Aggregate. Found in InternetSafetyPlan.Domain, with data persisted in the SQL Server DB.
- Applcation: Responsible for orchestrating and handling the requests that come in. Found in InternetSafetyPlan.Application.
- Infrastructure: Deals with the database and object mapping. Found in InternetSafetyPlan.Infrastructure and InternetSafetyPlan.API. Contains EF Code-First DB migrations.
- Presentation: The presentation of the domain functionality. Found in the React frontend.
As per onion architecture, outer layers can reference and call inner layers, but no inner layer can reference a layer exterior to it.
The .NET tests were written before I had much experience writing unit tests, so they aren't the stand-out star of the project. The Domain tests all need to be rewritten to not use hard-coded values and magic strings. I recently refactored the Application tests, which better show good unit testing practices (random value generation, in-memory DB testing with a separate instance per test, and clear Arrange, Act, Assert sections for each test).
I designed the DB using Entity Framework Code-First Migrations. This allows for quick changes to the domain and simple SQL generation.
- SQL Server DB
- .NET 8 Solution with EF Core
- Swagger API
[Created using Mermaid Charts].
Keycloak is an open-source Identity & Access Management solution that provides tons of customization and flexibility options for authentication and authorization. I set up an internet-safety realm + client that the app uses to allow users to log in.
One neat feature is the realm-export.json. This is a json schema of all the configuration needed for the auth, so getting it running locally with all the custom configuration I've done just requires running the Dockerfile, which imports this schema and sets everything up automatically. This is useful for local development as well as if you need multiple instances of Keycloak running in separate locations but want the same config for all of them.
The frontend was built using React due to its popularity, clean component-based architecture, and easy API setup to interact with my backend. It uses Typescript for stronger object typing, Tailwind CSS for clear and clean styling, and Vite for speedy setup.