I had already prepared the first episode starting to code the project when I realized, maybe it’s a better idea to start with explaining what’s the goal “product” wise, for everyone to have the context before starting coding like a maniac on something no one would understand.
Given this, the following video provides an overview, but if you prefer a quick read, skip to the written synthesis.
The playlist for the whole series is here.
Concepts
Like I mentioned previously, the goal of the project is to make a friendly sports event managing application, to be used by those who gather some friends to play something with their friends. The initial idea was centered around football (or soccer) but I’ll try to make it generic.
With this in mind, trying to find the main concepts that fit this idea I came up with:
- Users - well… this one is unexpected right? 😆
- Groups - groups of friends that gather to play
- Players - players are a different concept than a user to allow for groups of people where not everyone wants to use the application, but the users who want to can still manage everything even if there’s someone who’s not a registered user
- Match/event/game - represents the specific event that has/is/will happen
- Teams - the teams that play the match - this may very well be something fixed, but also something scoped to a match, where the teams are defined each time
- Statistics - something interesting is to keep statistics os the various matches, like match scores, goal/point/other scorers, fouls, etc
Desired features
While writing down the concepts, the desired features started to come to mind (along with some components that’ll be written down in the next section):
- Create/manage users
- Define email, name, nickname, profile picture, …
- Communication
- Send emails, notifications, …
- Manage preferences
- Create/manage groups
- Invite users
- Create players
- Associate players with users
- Set a specific sport for the group
- …
- Matches
- Schedule
- Manage information
- When, where, players involved, teams chosen, …
- Add events
- Goal scored, foul suffered, … (more and sport dependent)
- Live
- Be able to add match events during the match and be able to see the stats evolve realtime
Components
Ok, with the concepts and desired features laid out as best as possible for this kind of project (if a business analyst gave something like this to one of us, we would probably be enraged 😝) we can start to picture our over-engineered system, where we try to fit in every possible hipster technology… and as this is that kind of project, that’ll be exactly what’ll happen!
The following is something of the sort of a very high level architecture. It’ll most certainly change along the way (for the best hopefully) but I think can summarize the initial ideas.
We can see basically an organization of the various components, where even if we’re over-engineering the solution, we don’t want the components to be like CRUD services, but be as much as possible self contained services that can implement a specific feature set.
With this in mind we have:
-
Users- to handle registration, authentication and other user management requirements -
GroupManagement- to handle everything group related, from associating users to managing players. -
Communication- to handle all communication requirements, including the user’s communication preferences. -
Matches- to handle everything match specific, like when and where, scores, match events and more, except the live part. -
LiveMatches- will probably be separated from the main matches component as it’ll have the realtime requirement and maybe useful to be isolated. -
Statistics- this will be a central place to handle all statistics, even if they originally come from the match events - we’ll see in the long run how (and if we should) orchestrate this service with the matches one.
Besides this components responsible for the application logic, we’ll need a frontend to see it all working. To feed the frontend I’m thinking of going with a “backend for frontend”, to provide everything in the best way possible for the web frontend. The mobile part is out of scope, just added to the image as a possibility.
Outro
Not being a specification (not even close), I think this post can give a good initial idea of what’s the desired end result. If not, let me know so I can improve it.
Thanks for stopping by, cyaz!
Top comments (5)
Thank you for sharing this beautiful insights with me. Reading this part of your article makes me fekt like I was in a board room meeting where the CTO asked me to come up with this project. I love the idea of the boxes above it kind of makes me see a clearer path into the project.
Glad it's helpful!
It's far from perfect and very high level look, plus things are certainly bound to change, but hopefully it's good enough to understand the base idea.
I haven't used ASP.Net since ASP.Net MVC 1 came out I know I can RTFM but maybe you can answer some quick questions for me.
Sure, no problem.
Regarding question 1:
I don't feel you lose anything, if anything, it's the other way around, but there are somethings to take into account.
As .NET Core is not shipped with Windows like the .NET Framework, they can iterate on it faster. That's more inline with other technologies that release new versions more regularly, but has the same issue as others in that regard - support lasts for less time than the full framework which is supported as long as the Windows version is (i.e. a long long time!). If I'm not mistaken .NET Core is supported for 3 years on LTS versions, and some months for the others.
When .NET Core 1.0 was released, there were a lot of missing APIs that existed in .NET Framework, but with the release of 2.0 (and .NET Standard 2.0, which is like a contract that states what APIs a compatible .NET runtime must provide) they were mostly put up to par, except for Windows specific things - for this scenario they added the Windows Compatibility Pack.
And of course, being cross platform makes it better than ever, as if you prefer to run it on Linux servers, you can (and use Docker and those things that we couldn't with the .NET Framework).
And as a side note, we can (or at least could when on version 1.0) run ASP.NET Core on .NET Framework. It's probably not the ideal, but could be a good migration path for those who need it, not needing to completely jump the base framework plus web framework). Also a plus if one has dependencies on older libraries.
Regarding question 2:
Performance has improved a lot. Not only are they more focused on it than before, but being open source, people with specific needs just went ahead and improved things that were critical for them.
For real numbers you can check out the TechEmpower benchmarks which compares a lot of web frameworks. In some test scenarios ASP.NET Core is up on the top, in others not so much, but the effort to make it better is clearly there.
In the latest releases they created some new APIs to facilitate development of lower level stuff (like Span and Memory used in networking code) and even added C# features, also for lower level stuff (readonly structs).
Hope this was helpful 👍
amazing , that what we miss in real life project .