Issue Tracker #0 – Start

Tytuł tego tekstu pewnie niewiele Ci mówi, ale już wyjaśniam. Brakowało mi od jakiegoś czasu dwóch elementów w moim zasobniku. Przykładowego projektu, na którym mógłbym bazować, kiedy opowiadam o konkretnych rozwiązaniach, oraz projektu, do którego mógłbym linkować, kiedy ktoś pyta mnie o projekt, który poleciłbym do przejrzenia w kontekście ASP.NET Core i Blazora.

Z tej właśnie myśli urodził mi się pomysł na napisanie swojego przykładowego projektu, który udostępnię jako open-source. Chcę też, oczywiście, żeby był to pewnego rodzaju pokaz moich umiejętności w kontekście budowania kompletnych aplikacji.

Po wymyśleniu kilku tematów, ostatecznie uznałem, że zbuduję issue tracker, czyli aplikację, która zbiera informacje o problemach i pozwala je przypisywać do konkretnych pracowników, którzy zajmą się rozwiązaniem tych problemów.

Repozytorium projektu już istnieje i nawet są w niej wstępnie zarysowane pliki dokumentacji i fragmenty kodu: https://github.com/zajacmarekcom/issuetracker

Zanim przejdę do krótkiego opisania jakie są założenia projektu (chociaż są też dodane w repozytorium), to chcę dodać, że projekt planuję budować publicznie. To znaczy, że nie zrobię tak, że napiszę cały projekt w swojej piwnicy, dopieszczę na maksa i wypuszczę jako gotowe, pełne repozytorium. Chcę żeby było widać jak projekt rośnie – od wstępnego zarysu i jakichś pustych plików, do w pełni działającej aplikacji. Ponieważ sam projekt będzie raczej spory, przynajmniej jeżeli chodzi o ilość pracy, to spodziewajcie się też, że przez najbliższe miesiące większość przykładów, na których będą bazowały moje treści, będzie pochodziło właśnie z niego. W ten sposób ma „na siebie zarabiać”.

Po tym przydługim wstępnie powiedzmy sobie jakie są założenia projektu „Issue Tracker”.

Pod względem funkcjonalnym aplikacja powinna oferować co najmniej:

• Przyjmowanie issues przez API
• Bibliotekę Blazor umożliwiającą wpięcie zgłaszania błędów przez użytkowników
• Bibliotekę .NET do automatycznego przesyłania issue (np. z backendu, albo wprowadzonych w innny sposób niż biblioteka Blazor)
• Dashboard ze statusami poszczególnych issues
• Tagowanie issues pod względem ważności (krytyczne, poważne, standardowe albo mało istotne)
• Rozdzielanie issues pomiędzy pracowników
• Wysyłanie powiadomień o przeterminowanych albo nowych issue
• Możliwość podpięcia webhooks
• Logowanie przez Azure Active Directory

W kontekście wymagań niefunkcjonalnych zakładam, że system powinien:

• Być w stanie przyjmować do 500 issues na sekundę
• Bez utraty wydajności, przechowywać do 100mln issues
• Działać w Dockerze
• Uruchamiać się jedną komendą
• Być zbudowany w .NET Core, ASP.NET Core i Blazor
• Udostępniać interfejs REST API i gRPC
• Być budowany z użyciem MinimalAPI
• Być single-tenant (tzn. że jakaś firma go bierze i uruchamia w ramach swoich serwerów/chmury/domeny)

Część wymagań może wydawać się dziwna, albo mieć bardzo duże wartości. Jednak założyłem, że nie idę na kompromisy i chcę żeby było to też wyzwanie, a nie projekt jak z tutorialu. Zrobienie bazy, w której będzie 200 issues, a nowe będzie wchodziło raz na godzinę to żadne wyzwanie. Taki system można zrobić pewnie po kilku dniach nauki .NETa. Jednak jeżeli musimy wykręcić wspomniane na liście wartości, to nagle trzeba inaczej podejść do problemu i już proste rozwiązania niekoniecznie zadziałają.

Dodatkowo chcę też, żeby projekt był faktycznie użyteczny. Chodzi o to, że jeżeli ktoś uzna, że w sumie przyda mu się taka aplikacja w firmie, to będzie w stanie wziąć to repozytorium i (z poszanowaniem licencji) wdrożyć je u siebie, bez konieczności dopisywanie własnego kodu.

Na koniec dodam, że nie zakładam tutaj jakiejś konkretnej regularności. Także jeżeli interesuje Cię postęp w budowie, to zachęcam do obserwowania repozytorium, odwiedzania bloga i śledzenia mojego kanału na Youtube. Zapraszam też do dodawania swoich propozycji, poprawek i uwag w repozytorium. W trakcie pisania tego tekstu issues na GitHubie jeszcze nie były ogarnięte dla tego projektu, jednak powoli się to będzie zmieniać. Nie planuję na ten moment dodawać nikogo więcej jak regularnego kontrybutora do projektu.