Code Europe 2024 nadchodzi!

Code Europe 2024 nadchodzi!


Czas akcji: 10 – 11.06.2024
Miejsce akcji: ICE Kraków (ul. Marii Konopnickiej 17, Kraków)


Gotowy na Code Europe — największy festiwal technologiczny w Polsce? 🎆

Hej, tegoroczna edycja Code Europe odbędzie się już w czerwcu w Krakowie. Tym razem będą to dwa dni konferencji, a więc warto sobie zabukować jakiś hotel. Jest to prawdopodobnie największa tego typu impreza w Polsce.

Byłem na Code Europe dwa lata temu ostatnim razem i potwierdzam, że było ciekawie. Niestety w tym roku nie będę mógł dołączyć, a szkoda, bo agenda wygląda całkiem fajnie, co możecie zobaczyć na oficjalnej stronie wydarzenia: https://www.codeeurope.pl/pl/

Prelegenci

Lista jest jak zwykle długa, ale możemy się spodziewać między innymi takich postaci jak:

  • Kenneth Rohde Christiansen – Intel
  • Ekaterina Sirazitdinova – NVidia, ekspertka od AI, która rozwijała m.in. analizy medyczne oparte na obrazach
  • Michelle Sandford – ewangelistka z Microsoftu
  • Shaundai Person – Netflix
  • dr Robert Gentleman – Harvard Medical School – współtworzył język R, mocno związany z biomedycyną

i inni.

Czemu warto?

/akapit organizatora/

Code Europe to nie tylko zwykłe wydarzenie IT — to miejsce, gdzie najlepsi eksperci z całego świata gromadzą się, by dzielić się wiedzą, wymieniać doświadczeniami i przekraczać granice technologii, a to wszystko w otoczce festiwalowej zabawy!

To Twoja szansa, by odkryć najnowsze trendy i nawiązać kontakty, które mogą kształtować Twoją przyszłość zawodową w branży technologicznej. Z ponad 15 000 już zaangażowanych uczestników, możesz być pewien, że każda chwila spędzona na Code Europe będzie wartościowa i zdecydowanie nie chcesz tego przegapić!

Code Europe zabłyśnie na ICE Kraków 10-11 czerwca 2024 r. Festiwal jest dla wszystkich entuzjastów technologii, deweloperów, architektów oprogramowania, specjalistów DevOps, zapaleńców bezpieczeństwa, profesjonalistów ds. produktu, specjalistów ds. danych i pasjonatów QA, którzy chcą dzielić się wiedzą i razem ją zdobywać!

Dlaczego warto być częścią Code Europe?

🚀 Unikalne spojrzenie: ucz się od najlepszych prelegentów, którzy dzielą się najświeższymi spojrzeniami i doświadczeniami z branży technologicznej.

🤝 Networking: poznaj innych entuzjastów technologii, współpracuj nad pomysłami i nawiąż kontakty, które mogą wpłynąć na Twoją dalszą ścieżkę kariery.

💼 Paliwo karierowe: odkryj możliwości, połącz się z gigantami branży i zdobądź wgląd w najgorętsze trendy i możliwości w branży IT i technologii.

🎤 Najlepsi prelegenci: przygotuj się na prelekcje z liderami technologicznymi takimi jak Venkat Subramaniam, José Valim, Sébastien Chopin, Sven Peters, Michelle Sandford i wielu, wielu innych!

UWAGA! Zniżka!

CodeEurope jest oczywiście płatnym eventem. Jednak moi subskrybenci dostają 20% zniżki na bilety. Zniżka już poleciała do Was w osobnym mailu 🙂

Jeśli jeszcze nie subskrybujesz, koniecznie zapisz się na newsletter, a też dostaniesz kod zniżkowy 🙂

Podziel się artykułem na:
Kiedy i jak ponawiać żądania HTTP? Najlepsze praktyki

Kiedy i jak ponawiać żądania HTTP? Najlepsze praktyki

Wstęp

Jeśli Twoja apka używa WebAPI, warto zatroszczyć się o ponawianie żądań HTTP właśnie do tych API. Stosuje się to z kilku powodów, o których piszę niżej.

W tym artykule przedstawię Ci najlepsze praktyki, jakie możesz wykorzystać.

O tworzeniu własnego klienta WebAPI i różnych uproszczeniach, które możemy zastosować, pisałem już w tym artykule. Ten, który czytasz, potraktuj jako rozszerzenie i coś, co warto zastosować w prawdziwym kodzie.

Jeśli jesteś zainteresowany tylko konkretnym rozwiązaniem, rozwiń poniższy akapit:

Na szybko

  1. Pobierz Nuget: Microsoft.Extensions.Http.Polly
  2. Przy rejestracji klienta Http dodaj kod:
builder.Services.AddHttpClient<IndexModel>((client) =>
{
    client.BaseAddress = new Uri("https://example/com/");
}).AddTransientHttpErrorPolicy(policy => 
        policy.OrResult(x => x.StatusCode == HttpStatusCode.TooManyRequests)
        .WaitAndRetryAsync(Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromSeconds(1), 3)));

Teraz możesz już używać HttpClienta otrzymanego z dependency injection w standardowy sposób. Wszystko załatwia pobrana biblioteka i metoda AddTransientHttpErrorPolicy.

Jeśli chcesz wiedzieć więcej, przeczytaj cały artykuł.

Po co ponawiać żądania?

Jeśli pobierasz jakieś dane z WebApi możesz spotkać się z kilkoma odpowiedziami poza poprawną. Wtedy masz dwie opcje – pokazać użytkownikowi błąd. No i cześć. Albo spróbować ponowić żądanie, może za drugim razem się uda, a doświadczenie użytkownika z Twoją aplikacją będzie lepsze.

Odpowiedzi, po których warto ponowić żądanie to na przykład:

Wewnętrzny błąd serwera

Czyli kody odpowiedzi 5xx.

Oznacza to, że serwer ma aktualnie problem ze sobą. Mamy nadzieję, że chwilowy. W najgorszym wypadku, programiści czegoś nie przewidzieli i kod po prostu się wywala. Jeśli jednak jest to chwilowy problem, warto spróbować ponowić żądanie. Być może problem za chwilę zniknie.

Throttling

Kod 429: Too Many Requests.

Ten problem oznacza, że klient (Twoja aplikacja) zbyt często odpytuje serwer. Serwer ma ustawiony jakiś rate limit, co oznacza że możemy do niego strzelić określoną ilość razy w określonym czasie. To może być też ograniczone do ilości przesłanych danych. Więc jeśli otrzymasz odpowiedź 429 oznacza to, że za jakiś czas powinieneś ponowić żądanie i będzie git.

A co przy braku szukanego zasobu, skoro został utworzony?

Stare, dobre 404.

No… tutaj ponawianie ma sens tylko w jednej sytuacji. Kiedy wcześniej próbowałeś stworzyć zasób, ale to chwilę może zająć. A samo WebApi jest asynchroniczne. O asynchronicznych WebApi pisałem w tym artykule. W innym wypadku powtarzanie żądania przy tym kodzie nie ma żadnego sensu. Czyli zasadniczo nie powinieneś dostać takiej sytuacji, jeśli poprawnie obsługujesz asynchroniczne WebApi.

Ponawianie żądania – z czym to się je?

Zasadniczo sytuacja jest ciekawa. Bo nie ma innej opcji jak tylko ponawianie żądania w jakiejś pętli. Jednakże można to robić zarówno źle jak i dobrze. I źle to np. samemu tworzyć takie mechanizmy.

I możesz napisać sobie coś najprostszego w stylu (tylko fragment kodu):

HttpResponseMessage response;
try
{
    response = await _httpClient.GetAsync("api/get-data");
    switch(response.StatusCode)
    {
        case ....
        //jakoś zrób retry
    }
}catch(HttpRequestException ex)
{
    switch(ex.StatusCode)
    {
        case ...
        //jakoś zrób retry
    }
}

To oczywiście nie dość, że ciężko jest reużyć, to jest brzydkie. Nie dość, że jest brzydkie, to sam musisz oprogramować jakieś standardowe zachowania. Sam musisz:

  • napisać kolejne mechanizmy do ponawiania requestu,
  • pilnować, czy nie ponawiasz requestu nieskończoną ilość razy,
  • pilnować, czy ponawiasz go dostatecznie długo, ale nie za długo,
  • napisać coś, co pozwoli Ci ponawiać request po jakimś delayu, a nie od razu,
  • i pewnie mnóstwo innych rzeczy.

Wpadasz w dużą ilość pułapek, zaczynasz trafiać na mnóstwo zduplikowanego kodu i koniec końców okazuje się, że tworzysz jakiś skomplikowany mechanizm albo nawet cały projekt, którego jedynym zadaniem jest tak naprawdę ponowienie requestu w pewnych warunkach… Zamiast skupić się na faktycznej robocie.

Co jaki czas ponawiać request?

Na to pytanie będziesz musiał odpowiedzieć sobie tak, czy inaczej. Nie możesz ponawiać requestu bez żadnej przerwy, np. tak

public async Task<HttpResponseMessage> SendRequest()
{
    HttpResponseMessage response;
    try
    {
        return await _httpClient.GetAsync("api/get-data");
    }catch(HttpRequestException ex)
    {
        return await SendRequest();
    }
}

Weź pod uwagę kilka rzeczy:

  • ten kod jest pozbawiony kluczowych elementów (np. sprawdzania kodu odpowiedzi)
  • zakładamy, że posiadamy tutaj ochronę przed nieskończoną rekukrencją

Tutaj będziesz ponawiał requesty jeden za drugim bez żadnej przerwy. Nie jest to dobre podejście, bo bombardujesz zupełnie bez sensu API. No i nie dajesz odetchnąć procesorowi.

Lepiej zrobić chociażby coś takiego:

public async Task<HttpResponseMessage> SendRequest()
{
    HttpResponseMessage response;
    try
    {
        return await _httpClient.GetAsync("api/get-data");
    }catch(HttpRequestException ex)
    {
        await Task.Delay(1000);
        return await SendRequest();
    }
}

Requestów wyjdzie od Ciebie duuużo mniej i będą dużo bardziej sensowne. No bo jeśli uzyskałeś odpowiedź 429, to mało prawdopodobne, że od razu w następnym requeście otrzymasz poprawną. Odczekaj chwilę – dokładnie to mówi ten błąd: „Wstrzymaj konie kowboju, daj odetchnąć… albo wykup wyższy pakiet dostępu”.

To samo tyczy się innych kodów, które warto ponawiać.

Takie „stałe” (co jedną sekundę) ponawianie pewnie jakoś wygląda i pomaga. Natomiast można to zrobić duuuużo lepiej.

Jitter

Jitter (możesz wyszukać w necie pod hasłem „retry with jitter”) to pewna zmienna, która pomaga lepiej ustalić ten czas. To może być jakaś losowość, czyli raz czekasz sekundę, raz czekasz dwie, raz czekasz pół.

Ale to może być też exponential backoff.

Exponential backoff

Zapamiętaj to pojęcie dobrze, bo może pojawiać się na pytaniach rekrutacyjnych 😉

Exponential backoff to ogólnie przyjęta strategia do obliczania czasu, jaki musi minąć pomiędzy ponawianiem konkretnego żądania. Polega na tym, że pierwsze ponowienia są dość szybko, a kolejne mają coraz większą przerwę. Zobacz ten prosty przykład ponawiania requestu w pseudokodzie:

Request();
Czekaj(1000);
Request();
Czekaj(2000);
Request();
Czekaj(4000);
Request();
Czekaj(8000);

Jeśli pierwszy request trzeba ponowić, odczekaj sekundę.

Jeśli i to nie poszło, odczekaj 2 sekundy.

Jeśli nadal nie działa, odczekaj 4 sekundy… (to jest potęgowanie) Itd.

Jest to dość eleganckie rozwiązanie i szeroko stosowane.

Oczywiście nie musisz tego wszystkiego robić sam. W .NET jest paczka, która całą tą czarną robotę z ponawianiem requestów robi za Ciebie. I to jest prawidłowy mechanizm i bardzo dobra praktyka.

Przywitaj Polly

Jest taki Nuget:

Użycie tej paczki bardzo ułatwia całą pracę, co za chwilę zobaczysz, ale można jeszcze prościej (co zobaczysz później).

Polly przedstawia mechanizm AsyncPolicy, w którym po prostu budujesz sobie politykę ponawiania requestów. Oczywiście politykę możesz zbudować raz i używać ją wszędzie albo możesz też mieć różne polityki. Zbudujmy swoją pierwszą polityke:

private readonly IAsyncPolicy<HttpResponseMessage> _retryPolicy =
    Policy<HttpResponseMessage>
        .Handle<HttpRequestException>()
        .OrResult(x => (int)x.StatusCode >= 500 || x.StatusCode == HttpStatusCode.TooManyRequests)
        .RetryAsync(3);

//wywołanie requestu nieco się teraz zmienia:
public async Task<HttpResponseMessage> SendRequest()
{
   return await _retryPolicy.ExecuteAsync(() => _httpClient.GetAsync("api/get-data"));
}

W pierwszych linijkach stworzyliśmy politykę ponawiania requestów. To jest bardzo prosty builder i ma oczywiście dużo więcej możliwości niż tylko to, co pokazałem. Ale nie chcę w tym artykule pisać dokumentacji Polly, którą znajdziesz tutaj 🙂

Generalnie to mówi tyle:

  • IAsyncPolicy<HttpResponseMessage> – stwórz politykę dla typu zwracanego HttpResponseMessage
  • Handle<HttpRequestException> – użyj, jeśli pójdzie exception typu HttpRequestException (handle exception)
  • OrResult…. – lub rezultatem będzie – i tu przekazany delegat
  • RetryAsync(3) – ponów taki request 3 razy

I zobacz teraz co się stało w metodzie SendRequest. Została tylko jedna linijka, a mamy załatwione ponawianie requestu dla konkretnych StatusCode’ów i dla exceptiona, który może być rzucony. Wszystko się dzieje wewnątrz metody ExecuteAsync. My tylko musimy przekazać jej funkcję, która ma zostać wykonana – czyli konkretny strzał do API.

ExecuteAsync zwróci HttpResponseMessage, ponieważ z takim typem została zadeklarowana nasza polityka.

Jednak tak stworzona polityka nie jest idealna, bo będzie ponawiała request za requestem bez żadnej przerwy. Czy możemy dodać jakiś delay? Oczywiście, że tak:

private readonly IAsyncPolicy<HttpResponseMessage> _retryPolicy =
    Policy<HttpResponseMessage>
        .Handle<HttpRequestException>()
        .OrResult(x => (int)x.StatusCode >= 500 || x.StatusCode == HttpStatusCode.TooManyRequests)
        .WaitAndRetryAsync(3, retryCount => TimeSpan.FromSeconds(Math.Pow(2, retryCount)));

Tutaj metodę RetryAsync zamieniliśmy na WaitAndRetryAsync. Ta metoda w pierwszym parametrze przyjmuje ilość żądanych powtórzeń – tak jak RetryAsync, natomiast w drugim podajesz czas jaki ma upłynąć przed kolejnymi powtórzeniami.

Drugim parametrem jest oczywiście funkcja, która ten czas oblicza. W parametrze funkcji dostajesz zmienną int – retryCount, która Ci mówi, które powtórzenie aktualnie się odbywa. Za pomocą tej informacji w bardzo łatwy sposób możemy stworzyć swój exponential backoff, co zostało zrobione w tym kodzie.

Wygląda skomplikowanie? Jasne, że można prościej.

Rozszerzenia do Polly

W Nuget znajdziesz różne rozszerzenia do Polly, między innymi Polly.Contrib.WaitAndRetry. Celem tego rozszerzenia jest dostarczenie Ci już gotowych mechanizmów „backoff”, czyli tych do obliczania czasu między powtórzeniami żądania. I powyższy kod może być zamieniony na taki:

private readonly IAsyncPolicy<HttpResponseMessage> _retryPolicy =
    Policy<HttpResponseMessage>
        .Handle<HttpRequestException>()
        .OrResult(x => (int)x.StatusCode >= 500 || x.StatusCode == HttpStatusCode.TooManyRequests)
        .WaitAndRetryAsync(Backoff.ExponentialBackoff(TimeSpan.FromSeconds(1), 3));

W rozszerzeniu Polly.Contrib.WaitAndRetry dostaliśmy klasę Backoff i metodę ExponentialBackoff, której przekazaliśmy dwa parametry:

  • jaki czas musi upłynąć przed PIERWSZYM ponowieniem (tutaj sekunda)
  • ile razy ponawiać

Jest jeszcze lepsza metoda – do exponential backoff można dodać element losowości. Czyli przerwy nie będą idealnymi potęgami dwójki, ale będą trwały trochę mniej lub trochę więcej:

private readonly IAsyncPolicy<HttpResponseMessage> _retryPolicy =
    Policy<HttpResponseMessage>
        .Handle<HttpRequestException>()
        .OrResult(x => (int)x.StatusCode >= 500 || x.StatusCode == HttpStatusCode.TooManyRequests)
        .WaitAndRetryAsync(Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromSeconds(1), 3));

Jak widzisz, w bardzo łatwy sposób możesz zmieniać sobie strategie liczenia czasu.

Ale można jeszcze prościej… 😉

Integracja .NET z Polly

Microsoft w całej swojej dobroci zrobił już integrację z Polly, dzięki czemu możemy używać tego mechanizmu właściwie bez większych zmian w kodzie. Wszystko jest wpięte do HttpClientFactory, o którym pisałem trochę w artykule jak używać HttpClient.

Przede wszystkim pobierz sobie NuGeta: Microsoft.Extensions.Http.Polly. On ma już wszystkie zależeności.

Teraz, gdy rejestrujesz swojego klienta Http:

builder.Services.AddHttpClient<IndexModel>((client) =>
{
    client.BaseAddress = new Uri("https://example/com/");
});

możesz dodać swoją politykę Polly:

builder.Services.AddHttpClient<IndexModel>((client) =>
{
    client.BaseAddress = new Uri("https://example/com/");
})
    .AddPolicyHandler(Policy<HttpResponseMessage>
        .Handle<HttpRequestException>()
        .OrResult(x => (int)x.StatusCode >= 500 || x.StatusCode == HttpStatusCode.TooManyRequests)
        .WaitAndRetryAsync(Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromSeconds(1), 3)));

Zwróć uwagę, że dodałem dokładnie tą samą politykę, co w kodzie wyżej, bo to jest dokładnie takie samo działanie.

Oczywiście swoje polityki możesz trzymać w różnych miejscach (i zmiennych) i mieć je bardziej scentralizowane, jeśli tego chcesz.

Teraz już możesz HttpClienta uzywać w sposób klasyczny:

public class IndexModel : PageModel
{
    private readonly HttpClient _httpClient;

    public IndexModel(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<HttpResponseMessage> SendRequest()
    {
       return await _httpClient.GetAsync("api/get-data");
    }
}

Jeśli jeszcze nie wiesz, czemu akurat w taki sposób używamy HttpClient (przez dependency injection), KONIECZNIE przeczytaj ten artykuł.

Można jeszcze prościej

Ludzie, trzymajcie mnie, bo można jeszcze prościej:

builder.Services.AddHttpClient<IndexModel>((client) =>
{
    client.BaseAddress = new Uri("https://example/com/");
}).AddTransientHttpErrorPolicy(policy => policy.WaitAndRetryAsync(Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromSeconds(1), 3)));

Powtarzanie requestu w konkretnych warunkach jest na tyle pospolite, że Microsoft zrobił dodatkowe rozszerzenie do tego. Metoda AddTransientHttpErrorPolicy dodaje politykę domyślnie ustawioną na:

  • obsługę exceptiona typu HttpRequestException,
  • obsługę rezultatu, gdy status >= 500
  • obsługę timeout.

Musimy dodać tylko backoff jaki chcemy mieć (czyli ten delay pomiędzy powtórzeniami).

Ale uwaga. Uważny czytelnik zorientował się, że metoda AddTransientHttpErrorPolicy nie dodaje do polityki statusu kodu 429 Too may requests. Zgadza się. Jeśli chcemy to mieć, musimy sami to dodać:

builder.Services.AddHttpClient<IndexModel>((client) =>
{
    client.BaseAddress = new Uri("https://example/com/");
}).AddTransientHttpErrorPolicy(policy => 
        policy.OrResult(x => x.StatusCode == HttpStatusCode.TooManyRequests)
        .WaitAndRetryAsync(Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromSeconds(1), 3)));

Przyznasz jednak, że rozwiązanie jest duuużo bardziej czytelne i dużo lepsze niż mechanizmy, które tworzyłbyś sam, prawda? W zasadzie cały ten mechanizm ograniczył się do wywołania trzech metod przy konfiguracji. Piękna sprawa.


To tyle. Dzięki za przeczytanie artykułu. Jak zwykle, jeśli czegoś nie rozumiesz lub znalazłeś błąd w tekście, koniecznie daj mi znać w komentarzu.

A i sprawdź swoje apki, gdzie używasz zewnętrznych Api. Czy w którejś z nich masz czasem problem z dostępnością?

Podziel się artykułem na:
Badaj swoje API, czyli healthcheck

Badaj swoje API, czyli healthcheck

Spis treści

  1. Wstęp
  2. Czym jest healthcheck?
  3. Konfiguracja healthcheck
  4. Jak działa ten mechanizm?
  5. Badanie zdrowia standardowych serwisów
  6. Sprawdzenie bazy danych
  7. Jak zrobić niestandardowe sprawdzenie
  8. Jak pokazywać wynik healthcheck w niestandardowy sposób
  9. Zabezpieczanie healthcheck – uwierzytelnianie
  10. Kilka różnych końcówek – filtrowanie
  11. Dodanie healthcheck do Swaggera

Wstęp

Czy Twoja webówka działa? A jaką masz pewność? Musiałbyś co chwilę klikać i sprawdzać. Ale są też inne, lepsze metody. Możesz na przykład posłużyć się rozwiązaniem chmurowym, które cyklicznie będzie badać stan Twojej aplikacji. Co więcej, jest opcja, że nawet wyśle Ci maila albo SMSa, jeśli coś będzie nie tak.

Ten artykuł nie opowiada jednak o chmurowej części rozwiązania (jeśli chcesz taki materiał, daj znać w komentarzu), a o aplikacyjnej części. Czyli o healthcheck.

Czym jest Healthcheck?

Healthcheck jest sprawdzeniem stanu Twojej aplikacji. Czy działa wszystko ok, ewentualnie co nie działa. I oczywiście mógłbyś napisać sobie własny kontroler z odpowiednimi endpointami, w których to wszystko sprawdzasz, ale w .NET mamy już taki mechanizm w standardzie. I działa całkiem przyzwoicie.

Po co to właściwie?

Dzisiaj utrzymanie niezawodności i ciągłości działania aplikacji jest priorytetem. Stworzenie skutecznego mechanizmu healthcheck pozwala na szybką reakcję w razie wystąpienia jakiś problemów z jednym z kluczowych elementów systemu.

Jak już pisałem wcześniej, można to nawet spiąć z chmurą i spodziewać się maila albo nawet SMS gdy tylko coś niedobrego zacznie się dziać w Twojej aplikacji.

Przykładowa apka

Do tego artykułu stworzyłem przykładową aplikację, którą możesz pobrać z GitHuba. Po jej pobraniu, koniecznie uruchom migracje Entity Framework.

Niech nasza aplikacja zwraca różne dane pogodowe. Jeśli chodzi o prognozy, będą pobierane z zewnętrznego serwisu, a jeśli chodzi o dane archiwalne (prognoza z przeszłości), będą pobierane z naszej bazy danych.

Zewnętrzny serwis to oczywiście jakiś mock, który będzie udawał połączenie z zewnętrznym API.

Konfiguracja healthcheck

Podstawowa konfiguracja jest zabójczo prosta, bo sprowadza się tylko do rejestracji odpowiednich serwisów i dodania middleware. Czyli mamy coś takiego:

builder.Services.AddControllers();

//healthcheck
builder.Services.AddHealthChecks();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.UseHttpsRedirection();

app.UseAuthorization();

app.MapHealthChecks("/_health");

app.MapControllers();

app.Run();

Jeśli chodzi o linię 4 – to dodajemy do dependency injection serwisy do sprawdzenia stanu zdrowia. Co się tyczy linii 13, to mapujemy te healthchecki do konkretnego endpointa. W parametrze przekazujemy, pod jakim adresem ma być ten healthcheck. W tej sytuacji to będzie https://localhost:pppp/_health, gdzie pppp to oczywiście numer portu na środowisku lokalnym.

Teraz jeśli uruchomimy aplikację i sprawdzimy ten healthcheck, dostaniemy zwrotkę ze StatusCode 200 OK i wartością:

Healthy

Przyznasz jednak, że takie sprawdzenie niewiele nam daje. No właśnie, domyślny mechanizm właściwie niczego nie sprawdza. Jeśli aplikacja chodzi, to zawsze zwróci Healthy. A my chcemy sprawdzić przynajmniej dwie rzeczy:

  • czy działa połączenie z bazą danych
  • czy działa połączenie z zewnętrznym serwisem

Możemy wszystko napisać ręcznie, ale jest lepsza metoda. Nudesy…eeee Nugetsy 😉 O tym za chwilę.

Jak działa mechanizm healthcheck?

Metoda AddHealthChecks zwraca nam interfejs IHealthChecksBuilder, dodając jednocześnie domyślny serwis do sprawdzenia HealthChecków, który wszystkim zarządza. I tak naprawdę możemy sobie stworzyć listę healthchecków, jakie chcemy mieć. To wszystko sprowadza się do dodania do tego buildera klasy, która implementuje odpowiedni interfejs (o tym też będzie za chwilę).

Potem ten domyślny serwis bierze sobie te wszystkie klasy, tworzy je i wywołuje po kolei metodę sprawdzającą. Ot, cała magia. Dzięki czemu możemy tworzyć sobie właściwie nieograniczone sprawdzenia stanu zdrowia apki.

Badanie standardowych serwisów

Jeśli wejdziesz sobie do managera nugetów i zaczniesz wpisywać AspNetCore.Healthchecks, oczom Twym ukaże się całkiem pokaźna lista z już oprogramowanymi sprawdzeniami do konkretnych serwisów:

To nie są w prawdzie oficjalne Microsoftowe paczki, jednak społeczność która za tym stoi, to (w momencie pisania artykułu) ponad 150 osób. Jeśli używasz jakiegoś standardowego serwisu, to jest duża szansa, że sprawdzenie healthcheka do niego już istnieje.

Sprawdzanie bazy danych

Oczywiście możemy sobie sprawdzić różne bazy danych, w tym MSSQL, Postgre, MySQL, Redis itd. – używając bibliotek z powyższej listy. Możemy też użyć oficjalnej paczki Microsoft.Extensions.Diagnostics.Healthcheck, która umożliwia testowanie całego kontekstu bazy danych (EFCore). A jak używać tych wszystkich bibliotek?

Metoda AddHealthChecks zwraca nam interfejs IHealthChecksBuilder i wszystkie rozszerzenia jakie mamy dostępne są rozszerzeniami właśnie tego interfejsu. A prostymi słowami:

//healthcheck
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>(); //rozszerzenie z Microsoft.Extensions.Diagnostics.Healthcheck

W taki sposób możemy dodać sprawdzenie, czy baza danych działa. Domyślnie, sprawdzane jest połączenie z bazą danych za pomocą metody dbContext.Database.CanConnectAsync(cancellationToken);

Jednak niech nie zwiedzie Cię ta pozorna prostota. Jeśli chodzi o bazę MSSQL, to ta metoda faktycznie próbuje połączyć się z bazą danych, a potem wysyła zapytanie SELECT 1.

Oczywiście można zrobić więcej – wystarczy dodać jakieś parametry, np.:

//healthcheck
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>(customTestQuery: async (ctx, token) =>
    {
        await ctx.WeatherArchives.CountAsync();
        return true;
    });

W tym momencie domyślne sprawdzenie zostanie zamienione na nasze. Czyli podczas sprawdzenia stanu zdrowia bazy danych, baza zostanie odpytana o ilość rekordów w tabeli WeatherArchives – którą mamy zdefiniowaną w naszym AppDbContext. Parametr CustomTestQuery to po prostu funkcja, która przyjmuje w parametrze nasz kontekst bazy danych i CancellationToken, a zwraca jakiś bool.

I co najważniejsze – ten kod wystarczy. Nie trzeba tutaj stosować żadnych try..catch’y, ponieważ cała nasza funkcja i tak jest wywoływana w kontekście try..catch. Więc jeśli wystąpi jakiś exception, mechanizm healthcheck zwróci nam odpowiednią informację.

Niemniej jednak przy standardowych zastosowaniach, standardowy mechanizm sprawdzania bazy danych jest w zupełności wystarczający.

Sprawdzanie niestandardowe

Jednak nasz przykładowy serwis ForecastService, który ma imitować klienta jakiegoś zewnętrznego API, jest niestandardowym serwisem i nie znajdziemy biblioteki dla niego. Mechanizm HealthCheck pozwala jednak na napisanie własnego HealthChecka – dokładnie w taki sam sposób w jaki powstają te biblioteki wyżej pokazane.

Utworzenie klasy do sprawdzenia zdrowia

W pierwszej kolejności musimy utworzyć klasę, która implementuje interfejs IHealthCheck. Interfejs ma tylko jedną metodę, którą musimy napisać.

Teraz załóżmy, że nasz serwis, który udaje klienta API do pobierania prognozy pogody wygląda tak:

public class ForecastService(RandomHelper _randomHelper)
{
    public async Task<WeatherData> GetForecastFor(string city, DateOnly date)
    {
        await Task.Delay(500);
        return new WeatherData
        {
            City = city,
            Date = date,
            TemperatureC = _randomHelper.GetRandomTemperature()
        };
    }

    public async Task<bool> IsServiceHealthy()
    {
        await Task.Delay(500);
        return true;
    }

Czyli sprawdzenie stanu zdrowia tego serwisu będzie wymagało tylko wywołania metody IsServiceHealthy, którą nam daje nasz oszukany klient. A jak to zrobić? No oczywiście w klasie implementującej IHealthCheck:

public class ForecastServiceHealthCheck(ForecastService _forecastService) : IHealthCheck
{
    public async Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, 
        CancellationToken cancellationToken = default)
    {
        var result = await _forecastService.IsServiceHealthy();
        if (result)
            return HealthCheckResult.Healthy();
        else
            return HealthCheckResult.Unhealthy();
    }
}

W metodzie CheckHealthAsync musimy teraz zwrócić HealthCheckResult – rezultat, który mówi, czy testowany podsystem jest zdrowy, czy nie. Domyślne stany Healthy i Unhealthy zazwyczaj wystarczą.

Oczywiście w klasie implementującej IHealthCheck możesz zrobić dowolny kod. Jeśli masz faktyczne zewnętrzne API, do którego się łączysz, możesz mieć tutaj po prostu HttpClienta, za pomocą którego wyślesz jakiś request.

I tak jak pisałem wcześniej – takich klas możesz sobie utworzyć tyle, ile potrzebujesz.

A jak ją zarejestrować? Też cholernie prosto:

//healthcheck
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>()
    .AddCheck<ForecastServiceHealthCheck>("Forecast service");

Czyli wywołujemy metodę AddCheck. W parametrze generycznym przekazujemy typ klasy, w której zaimplementowaliśmy sprawdzenie, a w parametrze Name przekazujemy jakąś nazwę dla tego sprawdzenia. W tym wypadku: "Forecast service", bo sprawdzamy działanie właśnie tego serwisu.

Pokazywanie większej ilości informacji

W tym momencie, jeśli strzelimy na końcówkę z healthcheckiem dostaniemy odpowiedź w formie czystego stringa – Healthy albo Unhealthy. Ale możemy to zmienić w dość łatwy sposób. Najprościej pobrać sobie Nugeta: AspNetCore.Healthchecks.UI.Client i podczas dodawania healthchecków do middleware dodać opcje:

app.MapHealthChecks("/_health", new HealthCheckOptions
{
    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse //UIResponseWriter pochodzi z ww. Nugeta
});

I teraz dostaniemy dużo więcej informacji. Np. przy działającej aplikacji:

{
  "status": "Healthy",
  "totalDuration": "00:00:08.0064214",
  "entries": {
    "AppDbContext": {
      "data": {},
      "duration": "00:00:06.9029003",
      "status": "Healthy",
      "tags": []
    },
    "Forecast service": {
      "data": {},
      "duration": "00:00:00.5291383",
      "status": "Healthy",
      "tags": []
    }
  }
}

Zwróć uwagę, że otrzymujemy główny status apki i statusy poszczególnych serwisów, które sprawdzamy. AppDbContext to oczywiście sprawdzenie bazy danych. A Forecast service – to jest to, co sami pisaliśmy. Przy błędzie możemy uzyskać coś takiego:

{
  "status": "Unhealthy",
  "totalDuration": "00:00:00.5979899",
  "entries": {
    "AppDbContext": {
      "data": {},
      "duration": "00:00:00.0768822",
      "status": "Healthy",
      "tags": []
    },
    "Forecast service": {
      "data": {},
      "duration": "00:00:00.5204673",
      "status": "Unhealthy",
      "tags": []
    }
  }
}

Tutaj nie zadziałał serwis do prognoz.

Generalnie właściwość ResponseWriter przy mapowaniu tych healthchecków daje nam opcje takiego stworzenia odpowiedzi jaką chcemy. Jeśli ta domyślna z Nugeta daje za mało info albo trochę za dużo, sami możemy coś pokombinować, np.:

app.MapHealthChecks("/_health", new HealthCheckOptions
{
    ResponseWriter = async (httpContext, healthReport) =>
    {
        await httpContext.Response.WriteAsJsonAsync(healthReport);
    }
});

ResponseWriter to po prostu funkcja, która dostaje w parametrze HttpContext i HealthReport, a zwraca Task. Jej zadaniem jest wypisanie do responsa tego, co chcemy zobaczyć w odpowiedzi na ten endpoint.

Więc możemy sobie tutaj skonstruować odpowiedź jaka nam się tylko podoba. Możemy np. napisać sobie funkcje, która zwróci nam informacje o wersji albo co sobie tam wymyślimy.

Dodatkowe możliwości

Jeśli przyjrzysz się metodzie AddCheck z IHealthCheckBuilder, zobaczysz że ma ona dodatkowe parametry, które możesz przekazać. Wszystkie parametry trafią później do HealthCheckStatus – parametr w metodzie, w której tworzysz sprawdzenie – jak robiliśmy wyżej z ForecastServiceHealthCheck.

Dodatkowo możesz umieścić tam np. timeout. Mechanizm healthcheck mierzy czas wykonania każdego sprawdzenia. Jeśli przekażesz timeout i ten czas zostanie przekroczony, no to też dostaniesz odpowiednią informację.

Jeśli chodzi o listę tags, to możesz sobie wrzucić tam jakieś dodatkowe informacje, które są Ci potrzebne. O tym będzie jeszcze niżej.

Zabezpieczenie healthchecka – uwierzytelnianie

Zastanów się, czy każdy powinien mieć dostęp do Twojego healthchecka. Być może po drugiej stronie siedzi gdzieś ciemny typ, który próbuje hackować Twój system i zastanawia się jak po różnych krokach wygląda healthcheck. Jeśli dojdziesz do wniosku, że tylko niektóre osoby (maszyny) powinny mieć do tego dostęp, łatwo to ogarnąć.

W momencie, w którym mapujesz końcówkę healthchecka możesz dodać zabezpieczenia:

app.MapHealthChecks("/_health")
    .RequireHost("localhost");

Po takiej konfiguracji, będzie można dobić się do healthchecka tylko z domeny localhost. Próba dojścia z innej da po prostu zwrotkę 404 Not Found. Możesz też pokombinować mocniej. Np. wymusić konkretny port z dowolnego hosta:

app.MapHealthChecks("/_health")
    .RequireHost("*:5001");

Takich metod Require* mamy kilka, których możemy używać do różnych ograniczeń.

  • RequireCors – będzie wymagało odpowiedniej polityki CORS. O CORSach pisałem tutaj,
  • RequireAuthorization – będzie wymagało uwierzytelnionego użytkownika. Jak to zrobisz, to już jest Twoja sprawa. W tej metodzie możesz podać politykę autoryzacyjną, możesz też role, schematy. Jeśli nie podasz niczego, będzie użyty domyślny schematy uwierzytelniania,
  • RequireRateLimiting – da Ci rate limiting na tej końcówce 🙂 Po krótce, jest to mechanizm, który pozwala uderzyć w dane miejsce nie częściej niż ileś tam razy. Czyli np. możesz sobie ustawić raz na minutę.

Te ograniczenia możesz ze sobą również łączyć. Nic nie stoi na przeszkodzie, żeby mógł dobić się tylko uwierzytelniony użytkownik z konkretnego hosta i to nie częściej niż co jakiś czas:

app.MapHealthChecks("/_health")
    .RequireAuthorization()
    .RequireHost("localhost:5101")
    .RequireRateLimiting(...);

Filtrowanie healthchecków i kilka końcówek

Z jakiegoś powodu możesz chcieć uruchamiać tylko niektóre sprawdzenia. Domyślny mechanizm uruchamia wszystkie zarejestrowane HealthChecki. Ale możesz stworzyć filtrować te serwisy i pozwalać na uruchamianie tylko niektórych. Ponadto, możesz mieć więcej końcówek dla różnych sprawdzeń. Na przykład:

app.MapHealthChecks("/_health", new HealthCheckOptions
{
    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});

app.MapHealthChecks("/_health_db", new HealthCheckOptions
{
    Predicate = healthCheck => healthCheck.Tags.Contains("db")
});

Tutaj stworzyłem dwie końcówki:

  • _health – sprawdzi wszystkie zarejestrowane healthchecki i zwróci rezultat w JSON (tak jak pokazywałem wyżej)
  • _health_db – sprawdzi tylko te healthchecki, które zwróci Predicate – w tym wypadku te, które mają w swoich tagach słowo "db". I rezultat będzie zwrócony w standardowy sposób, czyli dostaniesz tylko informację Healthy lub Unhealthy (w tej końcówce nie posługujemy się ResponseWriterem).

A skąd ten filtr ma wiedzieć, że tag „db” oznacza bazę danych? Na szczęście to nie jest żadna magia i sam musisz zadbać o to, żeby do odpowiednich serwisów dodać odpowiednie tagi. Robisz to podczas ich rejestracji, np. tak:

//healthcheck
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>(tags: new string[] { "db" })
    .AddCheck<ForecastServiceHealthCheck>("Forecast service");

Zwróć uwagę, jak w trzeciej linijce dodałem tagi do serwisu badającego bazę danych.

Dodanie endpointa do Swaggera

Skoro to czytasz, to zapewne zauważyłeś, że tak stworzony endpoint dla healthcheck nie jest dodawany do Swaggera. I przy obecnej technologii, gdzie możemy używać Postmana i requestów prosto z VisualStudio (plik *.http) nie widzę w tym większego sensu, ale się da. Wystarczy stworzyć i zarejestrować swój własny DocumentFilter.

IDocumentFilter to interfejs, który dostarcza informacji o dodatkowych operacjach. Standardowo Swagger szuka po prostu kontrolerów i akcji w nich i na tej podstawie (używając refleksji) tworzy swoją dokumentację. Oczywiście można mu dodać operacje, które nie są obsługiwane przez kontrolery. Wystarczy zaimplementować ten interfejs IDocumentFilter:

public class HealthCheckDocumentFilter : IDocumentFilter
{
    public void Apply(OpenApiDocument swaggerDoc, DocumentFilterContext context)
    {
        var healthCheckOp = CreateHealthcheckOperation("_health", true);
        var dbHealthCheckOp = CreateHealthcheckOperation("_health_db", false);

        var healthPathItem = new OpenApiPathItem();
        healthPathItem.AddOperation(OperationType.Get, healthCheckOp);

        var dbHealthCheckPathItem = new OpenApiPathItem();
        dbHealthCheckPathItem.AddOperation(OperationType.Get, dbHealthCheckOp);

        swaggerDoc.Paths.Add("/_health", healthPathItem);
        swaggerDoc.Paths.Add("/_health_db", dbHealthCheckPathItem);
    }

    private OpenApiOperation CreateHealthcheckOperation(string endpoint, bool returnsJson)
    {
        var result = new OpenApiOperation();
        result.OperationId = $"{endpoint}OperationId";

        var mediaType = returnsJson ? "application/json" : "text/plain";
        var objType = returnsJson ? "object" : "string";
        var schema = new OpenApiSchema
        {
            Type = objType
        };

        var response = new OpenApiResponse
        {
            Description = "Success"
        };

        response.Content.Add(mediaType, new OpenApiMediaType { Schema = schema });
        result.Responses.Add("200", response);

        return result;
    }
}

No i musimy go zarejestrować podczas rejestracji Swaggera:

builder.Services.AddSwaggerGen(o =>
{
    o.DocumentFilter<HealthCheckDocumentFilter>();
});

Nie będę omawiał tego kodu, bo nie ma nic wspólnego z healthcheckiem, tylko z dodawaniem operacji do Swaggera. Jest dość prosty i intuicyjny. Po prostu musimy dodać konkretne operacje (OpenApiOperation) do konkretnych endpointów (swaggerDoc.Paths.Add) i tyle. A każda operacja może składać się z różnych opisów, zwrotek itd. To wszystko co tutaj podasz, będzie potem widoczne w odpowiednich opisach na stronie Twojej dokumentacji.


To tyle na dzisiaj. Dzięki za przeczytanie tego artykułu. Jeśli czegoś nie rozumiesz lub znalazłeś jakiś błąd, koniecznie daj znać w komentarzu. Jeśli chciałbyś jakąś dodatkową wiedzę na temat healthchecków, to też daj znać. No i koniecznie podziel się tekstem z osobami, którym się przyda 🙂

Podziel się artykułem na:
Nowości w C#12

Nowości w C#12

Wstęp

Wraz z wersją ósmą .NET, o której pisałem w tym artykule, dostaliśmy też wersję 12 języka C#. Dzisiaj opiszę Ci wszystkie nowości i zmiany w tej wersji. Lecimy.

Główne konstruktory – Primary constructors

Do tej pory mogliśmy ich używać tylko w recordach. Od C#12 mamy je dostępne również w klasach i strukturach. Działają jednak troszkę inaczej. O co chodzi?

Spójrz na ten POPRAWNY w C#12 kod:

class Person(string name, int age)
{
    public string Name { get; } = name;
    public int Age { get; } = age;
}

Obok nazwy klasy znalazły się nawiasy z parametrami. To jest właśnie coś, co nazywamy primary constructor. Zwróć uwagę, że te parametry: name i age są dostępne w całym ciele klasy. Można je odczytywać, zmieniać i robić wszystko to, co robiłbyś z prywatnymi polami. No właśnie… prywatnymi. Nie możesz się do nich dobrać z zewnątrz, dlatego też powyżej widzisz utworzone właściwości, które zwracają ich wartości.

Tak samo to działa w strukturach. I to jest ta różnica między klasą/strukturą, a rekordem:

record MyRecord(int X, int Y)
{
    public bool IsNegative()
    {
        return X < 0 || Y < 0
    }
}

Jeśli używasz primary constructor w rekordach, kompilator automatycznie stworzy właściwości ( { get; init; } ) dla każdego takiego parametru. Dzięki czemu możesz się normalnie do nich odwoływać na rzecz obiektu.

Wróćmy jednak do naszej klasy:

class Person(string name, int age)
{
    public string Name { get; } = name;
    public int Age { get; } = age;
}

To, co tutaj widzisz to tak naprawdę cukier składniowy. Kompilator wygeneruje do tego kod, który będzie wyglądał mniej więcej tak:

class Person
{
    private string __unspeakable_name;
    private int __unspeakable_age;

    public string Name  => __unspeakable_name;

    public Person(string name, int age)
    {
        __unspeakable_name = name;
        __unspeakable_age = age;
    }
}

Primary constructor z innymi konstruktorami

Jeśli chciałbyś mieć dodatkowe konstruktory, to musisz w nich wywołać ten primary constructor. Robi się to za pomocą słówka this:

class Person(string name, int age)
{
    public string Name { get; } = name;

    public Person(string name, DateTime birthday)
        : this(name, DateTime.Now.Year - birthday.Year)
    {

    }
}

Dependency injection

Primary constructors wspierają również mechanizm dependency injection, co wydaje się całkiem interesującym rozwiązaniem. Prawdę mówiąc, to chyba jedyny powód, dla których chciałbym ich używać. No bo popatrz na standardowy kod:

class MyService
{
    private readonly MyOtherService _service;

    public MyService(MyOtherService service)
    {
        _service = service;
    }
}

Używając primary constructors możemy go skrócić do takiego zapisu:

class MyService(MyOtherService service)
{
}

Jest kompresja.

Operacje na parametrach

No dobra, a jak poradzić sobie z sytuacją, gdzie w konstruktorze musimy zrobić jakieś sprawdzenia, czy coś w ten deseń? Czyli po staremu:

class Person
{
    public Person(string name)
    {
        if (string.IsNullOrWhiteSpace(name))
            throw new ArgumentException("Person must have a name");
    }
}

Po prostu możemy użyć statycznej metody:

class Person(string name)
{
    public string Name { get; } = ValidName(name) ? name : throw new ArgumentException("Person must have a name!");

    private static bool ValidName(string name) 
    {
        return !string.IsNullOrWhiteSpace(name);
    }
}

Podczas tworzenia takiego obiektu, zostanie wywołana metoda ValidName. No i jeśli podamy niepoprawną wartość, wywali się. Czyli kod poniżej zadziała tak, jak się tego spodziewamy:

var person = new Person(""); //wywali się

Niemniej jednak nie podoba mi się to. Chociaż to pewnie głównie kwestia gustu. Natomiast uważam, że to czyni kod brzydkim, brudnym, a im więcej takich rzeczy, tym ciężej będzie się go debugować.

Tworzenie kolekcji – Collection expressions

Bardzo miłe ułatwienie. Do tej pory, żeby stworzyć tablicę, trzeba było napisać:

int[] tab = new int[] { 1, 2, 3 };

Stary, fajny, klasyczny kod. Collection expressions, które dostaliśmy w C#12 daje nam dużo prostszą i szybszą metodę:

int[] tab = [1, 2, 3];

Możemy to samo zrobić z listami, spanami i właściwie wszystkimi kolekcjami wspierającymi inicjalizatory:

List<int> list = [1, 2, 3];
IEnumerable<int> e = [1, 2, 3];

A teraz spójrz jeszcze na zaznaczoną powyżej linię. Widzisz, jak stworzyłem IEnumerable?

Ale jak to? Przecież IEnumerable to interfejs!

Azaliż. I tak naprawdę powstał obiekt klasy ReadOnlyArray<int>.

W taki sposób można tworzyć też wszystkie rodzaje tablic – wielowymiarowe, poszarpane (jagged arrays) itd.

Jak dla mnie, bardzo fajne rozwiązanie. Bardzo ułatwi pracę i zdecydowanie będę z niego korzystał.

Inline arrays

UWAGA! To jest dość zaawansowany temat. Jeśli nie bawiłeś się pamięcią i nie używałeś bibliotek z innych języków (np. C++, Pascal), prawdopodobnie ten akapit niczego Ci nie da.

Inline array to odpowiednio utworzona struktura. Jest odpowiednikiem fixed buffer w bezpiecznym kodzie (safe code). Spójrz w jaki sposób możesz utworzyć taką strukturę:

[InlineArray(3)]
struct InlineBuffer
{
    public int element0;
}

Oznacza to, że tworzymy 3 elementową tablicę intów. Jedna rzecz jest istotna:

InlineBuffer buff = new InlineBuffer();

Teraz zmienna buff WSKAZUJE na pierwszy element tablicy – który jest jednocześnie polem element0. Czyli nie jest to referencja do tablicy, tylko sama tablica.

To jest przydatne, gdy walczymy bardzo o szybkość wykonywania kodu. Kompilator gwarantuje, że buff będzie po prostu ciągłą pamięcią o zadanej wielkości.

Ważne jest, że taka struktura nie może mieć żadnego layoutu i musi mieć jedno pole o typie, jakiego chcemy użyć w naszej tablicy.

Co istotne, to pole nie może być wskaźnikiem (w końcu to wskaźnik to niebezpieczny kontekst), ale może być każdym typem wartościowym i większością typów referencyjnych (w tym stringiem). A dobrać się możesz do konkretnych wartości tak samo jak w przypadku zwykłej tablicy – przez indekser. A także przez operator zakresu.

Domyślne parametry w wyrażeniach lambda

Nie ma się co rozpisywać. Po prostu w C#12 możemy używać domyślnych parametrów w wyrażeniach lambda. Wcześniej taki zapis w ogóle się nie kompilował. Obowiązują dokładnie te same reguły, co przy domyślnych parametrach metod:

var foo = (string s = "Siemma") => System.Console.WriteLine(s);

foo();  //wyświetli -> Siema
foo("Hej"); //wyświetli -> Hej

Modyfikator ref readonly

Do tej pory mieliśmy takie modyfikatory, którymi mogliśmy oznaczać parametry metody:

  • in
  • out
  • ref

W C#12 doszedł nowy: ref readonly.

W sumie, ref readonly robi dokładnie to samo, co in. Przyjrzałem się nawet kodowi generowanemu przez IL i te poniższe fragmenty C# tworzą dokładnie ten sam kod IL:

static void Main(string[] args)
{
    int val = 10;

    Show(val); //<-- pierwszy przypadek
    Show2(ref val); //<-- drugi przypadek
    Show2(in val); //<-- trzeci przypadek
}

public static void Show(in int value)
{
    System.Console.WriteLine(value);
}

public static void Show2(ref readonly int value)
{
    System.Console.WriteLine(value);
}

A kod IL też jest dość prosty, bo najpierw odkłada na stos ADRES zmiennej val, następnie wywołuje metodę, która ten adres ze stosu pobiera.

Jednak pewne, nieznaczne różnice są:

  • metoda przyjmująca parametr in nie potrzebuje, żeby kod wywołujący dawał o tym znać. Przy ref readonly bez jawnego określenia dostaniesz warning. Czyli:
//tu wszystko jest ok
Show(val);

public static void Show(in int value)
{
    System.Console.WriteLine(value);
}

//tutaj dostaniesz warning, bo powinieneś wywołać metodę z modyfikatorem ref lub in (nie ma żadnego faktycznego znaczenia dla kodu):

Show(val); //<-- dostaniesz warning
//Show(ref val); //<-- bez warninga
//Show(in val); <-- bez warninga

public static void Show(ref readonly int value)
{
    System.Console.WriteLine(value);
}

Zaznaczam – nie ma znaczenia, czy wywołasz metodę (ref readonly) z modyfikatorem ref, czy in. Kod w IL zostanie utworzony dokładnie ten sam.

  • jeśli przekażesz wartość (lub wyrażenie) do metody z modyfikatorem in, wszystko będzie ok; jeśli zrobisz to samo z metodą z modyfikatorem ref readonly – dostaniesz warning:
//tu wszystko jest ok
Show(10);

public static void Show(in int value)
{
    System.Console.WriteLine(value);
}

//tutaj dostaniesz warning

Show(10); //<-- dostaniesz warning
public static void Show(ref readonly int value)
{
    System.Console.WriteLine(value);
}

Jeśli jesteś ciekawy, co się wydarzy tutaj, to już mówię. Kompilator tak jakby stworzy za Ciebie zmienną, której przypisze wartość 10. Następnie adres tej zmiennej przekaże do metody.

Więc po co to ref readonly? Nie wiem. W specyfikacji czytam coś takiego:

W C# 7.2 wprowadzono parametry „in” jako sposób przekazywania referencji tylko do odczytu (w C++ nazywałoby się to stałą referencją – przyp. Adama). Parametry „in” dopuszczają zarówno lvalues jak i rvalues i można ich używać bez żadnej adnotacji podczas wywoływania.

Jednakże interfejsy API, które przechwytują lub zwracają referencje ze swoich parametrów chciałyby uniemożliwić rvalue a także wymusić pewne wskazanie w miejscu wywołania, że przechwytywana jest referencja.

Parametry ref readonly są idealne w takich przypadkach, ponieważ ostrzegają, jeśli zostaną użyte z rvalue lub bez żadnej adnotacji.

Także ma to na celu chyba tylko indykację, że metoda przyjmuje referencję.

Atrybut Experimental

C#12 daje nam nowy atrybut. System.Diagnostics.CodeAnalysis.ExperimentalAttribute. Możemy nim oznaczyć chyba wszystko. Od klasy, czy też enuma do pola, właściwości, czy zdarzenia.

Jeśli w kodzie użyjemy czegoś, co jest oznaczone atrybutem Experimental, kompilator wypluje ostrzeżenie, które zachowa się jak błąd. Trzeba jawnie oznaczyć to stłumić (suppress) to ostrzeżenie, żeby taki kod się zbudował.

Jeśli jednak wywołanie eksperymentalnego elementu będzie w innym eksperymentalnym elemencie, wtedy takie ostrzeżenie się nie pojawi. Czyli np.:

internal class MyClass
{
    public static void Run()
    {
        Foo();
    }

    public static void Foo()
    {

    }

    [Experimental("")]
    public static void Bar()
    {

    }
}

Powyższy kod skompiluje się bez problemu. Poniższy też

public static void Run()
{
    //Foo(); <-- wykomentowane wywołanie, czyli nie używamy metod eksperymentalnych
}

[Experimental("")]
public static void Foo()
{
    Bar();
}

[Experimental("")]
public static void Bar()
{

}

Ale poniższy da już błąd:

public static void Run()
{
    Foo(); //<-- użycie eksperymentalnej metody
}

[Experimental("")]
public static void Foo()
{
    Bar();
}

Błąd mówi:
Error CS9204 'Foo()' is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.

Więc, jeśli chcemy jednak używać metody eksperymentalnej, musimy to ostrzeżenie będące błędem wyłączyć:

        public static void Run()
        {
#pragma warning disable CS9204 
            Foo();
#pragma warning restore CS9204 
        }

        [Experimental("")]
        public static void Foo()
        {
            Bar();
        }

Można też zmniejszyć poziom tego ostrzeżenia – dokładnie tak samo jak innych. Możemy też to zrobić oczywiście globalnie, ale tego bardzo nie polecam.

Po co ten atrybut?

Raczej dla twórców bibliotek. Jeśli wprowadzają jakieś działanie, które w przyszłości może się mocno zmienić lub w ogóle zostać wywalone, wtedy oznaczenie tego jako Experimental jest dobrym pomysłem. A czy używanie takiego eksperymentalnego kodu jest dobrym pomysłem? Na produkcji raczej nie. W swoich wewnętrznych testach można się pobawić.

Wyłączanie ostrzeżeń o konkretnych funkcjonalnościach

Atrybut Experimental ma ciekawą właściwość. Można mu przekazać coś w rodzaju Id danej funkcjonalności (DiagnosticId), a potem tym Id posługiwać się podczas wyłączania ostrzeżenia. Np.:

        public static void Run()
        {
#pragma warning disable DoingFoo
            Foo();
#pragma warning restore DoingFoo
        }

        [Experimental("DoingFoo")]
        public static void Foo()
        {
            Bar();
        }

Co więcej, możesz przekazać więcej informacji w komunikacie błędu – a konkretnie adres strony, na której jest opisana ta funkcjonalność lub powód dlaczego klienci nie powinni tego używać:

[Experimental("DoingFoo", UrlFormat = "https://example.com/{0}")]
public static void Foo()
{
    Bar();
}

Wtedy błąd będzie wyglądał tak:

Error DoingFoo 'Foo()' is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed. (https://example.com/DoingFoo)

Interceptory

W chwili pisania tego artykułu (styczeń 2024) interceptory są eksperymentalne, więc póki co, nie opisuję ich. Ale będę trzymał rękę na pulsie i jeśli wejdą do użycia, na pewno o nich napiszę. Żeby tego nie przegapić, koniecznie zapisz się na newsletter 🙂


Dzięki za przeczytanie tego artykułu. Widać coraz bardziej, że C# idzie w stronę minimalizacji pisanego kodu, co jest z jednej strony fajnym rozwiązaniem. Chociaż może być cięższe do zrozumienia dla początkujących programistów. Niemniej jednak uważam, że to dobry krok naprzód. I choć w tej wersji może nie było jakiś super wielkich zmian, to jednak miło że MS słucha community.

Jeśli czegoś nie rozumiesz lub zauważyłeś w tekście jakiś błąd, daj znać w komentarzu 🙂

Podziel się artykułem na:
Co nowego w .NET8?

Co nowego w .NET8?

Wstęp

.NET8 wyszedł już oficjalnie jakiś czas temu. Przez ten czas sprawdzałem co i jak się zmieniło w tej ostatecznej wersji. Ale pracy przy tym było na tyle dużo, że w przyszłości jednak będę to robił na bieżąco w wersjach preview.

W tym artykule opisuję większość zmian i nowości, jakie zostały dla nas przygotowane. Elementy, które w pewnych okolicznościach mogą być lub są breaking changem, zaznaczyłem w kolorze czerwonym.

Weź pod uwagę, że to nie jest w 100% pełna lista. Wybrałem najciekawsze i najbardziej przydatne rzeczy wg mnie. Jeśli uważasz, że coś więcej powinno się znaleźć w tym artykule, daj znać w komentarzu.

Bez zbędnych ceregieli – lecimy z koksem.

Spis treści

Wsparcie dla .NET8

Przede wszystkim, .NET8 w przeciwieństwie do siódemki jest oznaczony jako LTS (long-time-support). Co oznacza, że będzie oficjalnie wspierany przez 3 najbliższe lata. Więc jeśli tworzysz nowy system i wahasz się między wersją 7, a 8, to zdecydowanie powinieneś wybrać ósemkę, chociażby z tego względu.

Serializacja JSON

Doszło kilka nowości i usprawnień jeśli chodzi o serializację JSON:

  • dodano wsparcie dla dużych liczb: Int128 i UInt128 (a także dla Half – float16)
  • Tablice bajtów serializowane na Memory<byte> i ReadOnlyMemory<byte> domyślnie zmieniane są na Base64
JsonSerializer.Serialize(new byte[] { 1, 2, 3 }); // da w efekcie "AQID"

Deserializacja obiektu z brakującymi właściwościami

W .NET8 mamy teraz wybór, co zrobić gdy deserializujemy jsona do obiektu, który nie ma niektórych danych.

Załóżmy, że masz taką klasę:

internal class JsonData
{
    public int Id { get; set; }
}

I takiego JSONa:

{
    "Id": 42, 
    "AnotherId": -1
}

Po staremu, jeśli takiego jsona chciałeś deserializować do klasy JsonData, wszystko było ok. Po nowemu domyślnie też tak jest, a więc nie jest to żaden breaking change. Natomiast masz wybór, co zrobić w takiej sytuacji. Możesz się na to nie zgodzić, ustawiając odpowiedni atrybut na klasie:

[JsonUnmappedMemberHandling(JsonUnmappedMemberHandling.Disallow)]
internal class JsonData
{
    public int Id { get; set; }
}

Teraz, JsonSerializer.Deserialize wywali się.

Serializacja enumów

Do tej pory mieliśmy dostępny specjalny konwerter JsonStringEnumConverter. Teraz mamy dostępną jego generyczną wersję JsonStringEnumConverter<T>. Ma to związek tylko z kompilacją AOT. Wersja generyczna nie wykorzystuje refleksji.

Nowe polityki nazw atrybutów

Do tej pory, parsując JSONa, mogliśmy używać polityki camelCase. Dawała ona tyle, że nazwa atrybutu w JSON mogła być napisana właśnie tak:

{
    "nazwaMojegoPola": "wartość"
}

Oczywiście, była opcja żeby sobie dopisać własne polityki. Teraz jednak mamy dodatkowe, których możemy użyć: snake_case i kebab-case. Możemy to ustawić w opcjach serializacji dokładnie w taki sam sposób, jak ustawialiśmy camelCase.

Deserializacja pól tylko do odczytu

Załóżmy, że mamy taki model:

class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
}

i prostą klasę, która go używa:

class Data
{
    public Person Person { get; } = new();
}

Zauważ, że właściwość Person nie ma żadnego settera. W poprzednich wersjach .NET, taka deserializacja po prostu nie działała:

string json = "{\"Person\":{\"Id\": 5, \"Name\": \"Stefan\"}}";
Data d = JsonSerializer.Deserialize<Data>(json); //właściwość Person miała domyślne dane

Teraz, wystarczy że klasę Data opatrzysz odpowiednim atrybutem: [JsonObjectCreationHandling(JsonObjectCreationHandling.Populate)] i właściwość Person zostanie wypełniona odpowiednimi danymi.

Pamiętaj tylko, że klasa Person musi mieć przy swoich właściwościach settery.

Takie działanie możesz też ustawić globalnie w aplikacji:

builder.Services.AddControllers()
    .AddJsonOptions(o =>
    {
        o.JsonSerializerOptions.PreferredObjectCreationHandling = JsonObjectCreationHandling.Populate;
    });

JsonSerializationContext

Od .NET6 mamy możliwość (de)serializacji obiektów do JSON za pomocą wygenerowanego specjalnego kodu (kompilacja AOT), zamiast refleksji. Jest to szybsze (wg testów MS nawet 40%), jednak też ma minusy. Nie jest to artykuł o tym i jeśli nie robiłeś tego wcześniej, możesz pominąć ten fragment.

Przed .NET8 można było dodać własny JsonSerializationContext do opcji: JsonSerializerOptions.AddContext<TContext>. Teraz ta metoda jest oznaczona jako obsolete, ale mamy coś lepszego do dyspozycji. A mianowicie: TypeInfoResolverChain. Teraz można dodawać te konteksty swobodnie i swobodnie je usuwać:

JsonSerializerOptions.TypeInfoResolverChain.Add(MyContext.Default)

ponieważ TypeInfoResolverChain to zwykła lista.

Możliwość blokowania (de)serializacji opartej na refleksji

Możesz zablokować domyślną (de)serializację opartą na refleksji. Jeśli potrzebujesz zrobić bibliotekę AOT lub po prostu chcesz pokombinować z wydajnością. Wystarczy, że dodasz w pliku projektu odpowiedni wpis:

<PropertyGroup>
  <JsonSerializerIsReflectionEnabledByDefault>false</JsonSerializerIsReflectionEnabledByDefault>
</PropertyGroup>

Potem, jeśli chcesz sprawdzić, czy refleksja jest dostępna, możesz posłużyć się właściwością JsonSerializer.IsReflectionEnabledByDefault

Używanie konstruktorów z parametrami

Domyślnie, JsonSerializer używa publicznego bezparametrowego konstruktora. Jednak możesz zmienić to zachowanie, używając odpowiedniego atrybutu:

public class MyClass
{
    public int Data { get; private set; }

    public MyClass()
    {
        
    }

    public MyClass(string data)
    {
        Data = Convert.ToInt32(data);
    }

    [JsonConstructor]
    internal MyClass(int data)
    {
        Data = data;
    }
}

Zauważ, że w powyższym kodzie mamy 3 konstruktory. Jeden bez parametrów, drugi z jakimś parametrem string i trzeci, nie dość że oznaczony jako internal, to też z parametrem typu int.

Ze wszystkich konstruktorów możemy swobodnie korzystać. Dodatkowo JsonSerializer będzie korzystał tylko z konstruktora oznaczonego atrybutem JsonConstructor. Nie jest ważne, że jest to konstruktor wewnętrzny. JsonSerializer właśnie z niego skorzysta, przekazując w parametrze odpowiednią wartość.

UWAGA! W klasie możesz mieć tylko jeden konstruktor oznaczony tym atrybutem.

Jeśli chcesz zdeserializować jsona do takiego obiektu poza mechanizmem webowym (żądanie w kontrolerze), musisz stworzyć odpowiednie opcje:

string json = "{\"data\": 5}";

var options = new JsonSerializerOptions(JsonSerializerDefaults.Web);
var obj = JsonSerializer.Deserialize<MyClass>(json, options);

Abstrakcje dla czasu

O, tego czasami brakowało i trzeba było samemu sobie robić takie abstrakcje, jeśli pewne rzeczy chciałeś mockować w testach jednostkowych. Teraz mamy to w standardzie.

W .NET8 powstała klasa abstrakcyjna TimeProvider, po której możemy dziedziczyć lub używać domyślnego, lokalnego czasu. Poniższy kod pokazuje te operacje:

internal class FakeTime : TimeProvider //tworzymy fake'ową klasę; można to też po prostu zamockować
{
    public DateTimeOffset Now { get; set; }

    public FakeTime(DateTimeOffset value)
    {
        Now = value;
    }
    public override DateTimeOffset GetUtcNow()
    {
        return Now;
    }
}

internal class TimeProviderTest
{
    public void Foo()
    {
        Bar(TimeProvider.System); //używamy domyślnej implementacji

        TimeProvider fakeTime = new FakeTime(new DateTimeOffset(2000, 01, 01, 00, 00, 00, TimeSpan.Zero)); 
        Bar(fakeTime); //używamy własnej implementacji
    }

    public void Bar(TimeProvider time)
    {
        Console.WriteLine("Aktualny czas: " + time.GetLocalNow()); //pobieramy czas z providera
    }
}

Timer

Klasa TimerProvider daje nam też do dyspozycji całkiem fajny timerek. Możemy go utworzyć w taki sposób:

ITimer timer = TimeProvider.System.CreateTimer(obj.TimerCallback, state, TimeSpan.Zero, TimeSpan.FromSeconds(1));

Timer ma kilka parametrów:

  • TimerCallback callback – delegat, który będzie cyklicznie uruchamiany. To po prostu metoda, która zwraca void i przyjmuje w parametrze nullable object: void Foo(object? state). Bardzo podobnie jak w ParametrizedThreadStart,
  • object? state – dane, które możemy przekazać do naszej metody. Jak widzisz, to może być dowolny obiekt,
  • TimeSpan dueTime – czas, jaki ma upłynąć od utworzenia timera, do pierwszego wywołania metody callback,
  • TimeSpan period – interwał uruchomienia metody callback. Czyli jeśli tu ustawimy np. 5 sekund, to metoda callback będzie wywoływana co 5 sekund.

ITimer ma też metodę Change, w której możesz zmienić interwał wywołań metody callback.

UWAGA! Timer różni się od tych, które możesz pamiętać z WinForms, czy starszych technologii. Ten timer wywołuje metodę callback na wątku branym z ThreadPoola. To oznacza, że metoda callback wywoływana jest na innym wątku. Pamiętaj o tym.

Co więcej, ITimer implementuje interfejs I(Async)Disposable. To znaczy, że musimy go zwalniać. Oczywiście tutaj zwykłe using ITimer... raczej nie wchodzi w grę, bo jest duża szansa, że timer zakończy swój żywot nim metoda callback się uruchomi.

Tak, jak inne tego typu timery, także ten ma ograniczony interwał, w którym może pracować. Ograniczenie jest spowodowane rozdzielczością zegara systemowego, którą możesz przyjąć na 15 milisekund. Jeśli podasz interwał mniejszy niż te 15 milisekund, to i tak, będzie pracował ze swoją minimalną.

Pomiar czasu między operacjami

TimeProvider umożliwia również mierzenie czasu między operacjami. Do tej pory mogliśmy stosować inne rozwiązania, np. Stopwatch. Tutaj mamy dokładnie to samo, tylko ładniej obudowane, spójrz na ten kod:

var start = TimeProvider.System.GetTimestamp();
Thread.Sleep(1025);
var elapsed = TimeProvider.System.GetElapsedTime(start);
System.Console.WriteLine("To trwało: " + elapsed);

//To trwało: 00:00:01.0326601

Metoda GetElapsedTime po prostu policzy różnicę między aktualnym Timestamp, a tym podanym. Jest jeszcze druga wersja, która liczy różnice pomiędzy dwoma timestampami.

Operacje losowe

Mamy kilka nowych metod, których możemy użyć do pracy z losowością.

GetItems<T>()

Metoda GetItems zwraca nam losowo wybrane elementy z jakiejś tablicy/listy/czegokolwiek. Spójrz na poniższy przykład, który mógłby zostać użyty do generowania haseł w systemie. Tylko dwie linijki:

char[] chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$%^&*()".ToCharArray();
char[] selectedChars = Random.Shared.GetItems(chars, 10);

Tablica chars zawiera wszystkie dostępne elementy, z których będziemy losować. Metoda GetItems losuje przekazaną ilość elementów (tutaj 10) z podanej tablicy wszystkich.

Oczywiście to nie ogranicza się do tablicy znaków. Możemy losować wszystko z każdej kolekcji (konwertując kolekcję na tablicę lub ReadOnlySpan).

Shuffle<T>()

Ta metoda, niby nowa, ale nie wymaga wyjaśniania. Jedna z moich ulubionych opcji w odtwarzaczu WinAmp 🙂 Metoda Shuffle, prawdopodobnie ze względu na optymalizację, miesza tylko w istniejącej tablicy / spanie. Tak więc jeśli masz listę, którą chcesz pomieszać, musisz ją najpierw przerzucić do tablicy. Dajmy trochę bardziej skomplikowany przykład – z listą obiektów, którą chcemy pomieszać:

class IdItem
{
    public int Id { get; set; }
}

class RandomTestRunner
{
    public static void Run()
    {
        List<IdItem> data = new();
        for(int i = 1; i < 100; i++)
            data.Add(new IdItem { Id = i });

        var arr = data.ToArray();
        Random.Shared.Shuffle(arr);

        data = new(arr);
    }
}

Najpierw tworzę sobie listę obiektów. Potem tworzę klasyczną tablicę z tej listy. Tablicę przekazuję do metody Shuffle. Ona tam sobie tą tablicę miesza. Na koniec tworzę listę z pomieszanej tablicy – obiekty są już w losowej kolejności.

Uważam że mimo swojej prostoty, te metody są całkiem fajne. Rzadko kiedy robię jakieś randomowe operacje, ale jak już robię, to musiałem takie rzeczy pisać sam. A teraz mamy gotowy mechanizm.

Nowe typy stworzone dla szybkości

.NET 8 wprowadził kilka typów, których zadaniem jest przyspieszenie niektórych operacji. Nie korzystałem z tego w rzeczywistych projektach, więc nie mogę powiedzieć, jak to faktycznie działa, ale postanowiłem zrobić mały benchmark. Zobaczmy po kolei.

System.Collections.Frozen

Ten namespace daje nam dwie nowe kolekcje – FrozenDictionary<TKey, TValue> i FrozenSet<T>. Są one tylko do odczytu. Jak już stworzysz, nie możesz niczego w nich zmienić. Teoretycznie zostały poczęte do tego, żeby operacje odczytu były szybsze niż w ich odpowiednikach. Sprawdźmy to.

Ring wolny

W lewym narożniku mamy klasyczne Dictionary<int, int>, a w prawym czeka FrozenDictionary<int, int>. Testy zostały przeprowadzone dla 12 przypadków. Różniły się:

  • ilość wpisów (1000, 10 000, 100 000, 1000 000)
  • ilość odczytów (1, 10, 100)

Kod, który był testowany wyglądał tak:

int result = 0;
for (int i = 0; i < Reads; i++)
    result += dict[i];

return result;

Gdzie Reads to oczywiście ilość odczytów. Wyniki są jednoznaczne. Frozen wygrywa:

MethodElementsCountReadsMeanRatioRatioSD
ReadDictionary1000111.173 ns1.000.00
ReadFrozen100017.047 ns0.640.11
ReadDictionary10001097.220 ns1.000.00
ReadFrozen10001061.455 ns0.640.08
ReadDictionary10001001,000.912 ns1.000.00
ReadFrozen1000100566.589 ns0.570.07
ReadDictionary10000110.008 ns1.000.00
ReadFrozen1000016.577 ns0.700.08
ReadDictionary100001093.015 ns1.000.00
ReadFrozen100001057.464 ns0.620.05
ReadDictionary10000100963.958 ns1.000.00
ReadFrozen10000100654.683 ns0.690.11
ReadDictionary100000110.472 ns1.000.00
ReadFrozen10000016.879 ns0.670.12
ReadDictionary1000001098.492 ns1.000.00
ReadFrozen1000001062.093 ns0.640.09
ReadDictionary1000001001,075.513 ns1.000.00
ReadFrozen100000100614.143 ns0.580.09
ReadDictionary1000000110.387 ns1.000.00
ReadFrozen100000016.834 ns0.660.08
ReadDictionary10000001089.935 ns1.000.00
ReadFrozen10000001061.172 ns0.690.06
ReadDictionary10000001001,013.573 ns1.000.00
ReadFrozen1000000100620.679 ns0.620.08

System.Buffer.SearchValues<T>

SearchValues to swego rodzaju tablica. Używamy jej, gdy często szukamy jakiś wartości. Np. jeśli często byśmy szukali samogłosek w stringach, można by było napisać taki kod:

string str = "To jest jakiś tekst napisany przez Adama"; //tekst, w którym będziemy szukali
string chars = "aeiou"; //samogłoski, których szukamy
ReadOnlySpan<char> needles = new ReadOnlySpan<char>(chars.ToArray()); //teraz musimy skonstruować Span
SearchValues<char> values = SearchValues.Create(needles); //to przyjmuje tylko ReadOnlySpan

var result = str.AsSpan().IndexOfAny(values); //no i szukamy

SearchValues niestety może być utworzone jedynie z ReadOnlySpan byte'ów lub char'ów.

Generalnie powstało to po to, żeby optymalizować częste szukanie pewnych danych. Wszelkie optymalizacje są robione w momencie wywołania SearchValues.Create <– to tutaj dzieje się cała magia. Dlatego pamiętaj, że żeby to miało sens, metoda Create powinna być użyta tylko raz, a Twoje SearchValues powinno żyć tak długo, jak długo z niego korzystasz.

To ma być w przyszłości używane również przez operacje Regex, które dzięki temu mogą stać się szybsze. Z tego, co wiem, na moment pisania tego artykułu w .NET8 to jeszcze nie jest ogarnięte.

A teraz sprawdźmy przykładowy program. Sprawdzanie, czy string zawiera jedynie duże i małe litery bez znaków specjalnych. Sprawdzimy trzy metody:

[MemoryDiagnoser]
public class BufferTestBenchmark
{
    private static SearchValues<char> _searchValues;
    private string _allowedChars = "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM";

    [Params("qoiudhjkfdsbnfmaQOIUDHJKFDSBNFMA", "qoiudhjkfdsbnfm@QOIUDHJKFDSBNFM@", "@oiudhjkfdsbnfma@OIUDHJKFDSBNFMA")]
    public string Value {  get; set; }

    
    public BufferTestBenchmark()
    {
        _searchValues = SearchValues.Create(_allowedChars.AsSpan());
    }

    [Benchmark(Baseline = true)]
    public bool UsingSearchValues()
    {
        return !Value.AsSpan().ContainsAnyExcept(_searchValues);
    }

    [Benchmark]
    public bool UsingContains()
    {
        foreach(var ch in Value)
        {
            if (!_allowedChars.Contains(ch))
                return false;
        }

        return true;
    }

    [Benchmark]
    public bool UsingSpan()
    {
        return !Value.AsSpan().ContainsAnyExcept(_allowedChars);
    }
}

Czyli mamy string, który na początku ma specjalny znak, na końcu i tak, który nie ma go w ogóle (czyli jest zgodny z założeniami). Wyniki wyglądają następująco:

MethodValueMeanRatioRatioSD
UsingSearchValues@oiud(…)BNFMA [32]8.984 ns1.000.00
UsingContains@oiud(…)BNFMA [32]7.922 ns0.890.14
UsingSpan@oiud(…)BNFMA [32]116.279 ns13.131.58
UsingSearchValuesqoiud(…)BNFM@ [32]9.134 ns1.000.00
UsingContainsqoiud(…)BNFM@ [32]90.065 ns10.121.76
UsingSpanqoiud(…)BNFM@ [32]119.263 ns13.392.25
UsingSearchValuesqoiud(…)BNFMA [32]6.140 ns1.000.00
UsingContainsqoiud(…)BNFMA [32]203.261 ns33.544.97
UsingSpanqoiud(…)BNFMA [32]114.471 ns18.972.55

Jak widać, w większości użycie SearchValues daje ogromne różnice na plus. Zatem jednoznacznie wychodzi, że jeśli robimy jakieś częste przeszukiwania konkretnych elementów, zdecydowanie warto zastanowić się nad SearchValues.

Formatowanie stringów – CompositeFormat

Ok, ogólnie rzecz biorąc mamy do dyspozycji trzy metody formatowania stringów (nie licząc niektórych przeciążeń metod w stylu Console.Write, które i tak sprowadzają się do użycia string.Format). A są to:

  • string.Format, który jest od początku
  • interpolacja stringów
  • i nowość – klasa CompositeFormat

Czy to nie jest jakaś klęska urodzaju? Nie.

Na początku był string.Format. Ogarniał wszystkie możliwe przypadki. Potem, wiele lat później doszły interpolowane stringi, czyli coś takiego:

int i = 10;
string s = $"Cześć, jestem interpolowanym stringiem. Wartość zmiennej to: {i}";

Początkowo interpolowane stringi pod spodem sprowadzały się do wykonania string.Format. Później jednak były w jakiś sposób optymalizowane. A i ich zapis wydaje się bardziej czysty.

Ale co zrobić w momencie, gdy nie znasz formatu stringa w czasie pisania apki? Na przykład ten format przychodzi z zasobów albo z innego miejsca?:

int data = 10;
string format = _resourceProvider.GetFormatForString();
string result = string.Format(format, data);

Wciąż musimy używać string.Format. Najczęściej taka sytuacja będzie związana pewnie z pobieraniem stringów z tłumaczeń.

Problem leży w tym, że takie rozwiązanie nie jest idealne. Na pewno można szybciej to rozwiązać… No i w .NET8 zrobili nam klasę CompositeFormat. Ta klasa w pewien sposób kompiluje sobie format, który ma użyć. I robi to tylko raz. String.Format robił coś takiego przy każdym użyciu. Dzięki czemu CompositeFormat wydaje się być bardziej wydajne… Sprawdźmy to.

Testujemy prędkość

Kod, który testuję wygląda tak:

[MemoryDiagnoser]
public class StringFormatBenchmark
{
    private static string format = "Hello {0}, today is {1}";
    private static readonly CompositeFormat s_cFormat = CompositeFormat.Parse(format);

    [Benchmark(Baseline = true)]
    public string FormatTest()
    {
        string result = string.Format(format, "Adam", DateTime.Now);
        return result;
    }

    [Benchmark]
    public string CompositeFormatTest()
    {
        string result = string.Format(null, s_cFormat, "Adam", DateTime.Now);
        return result;
    }

    [Benchmark]
    public string InterpolatedTest()
    {
        string result = $"Hello {"Adam"}, today is {DateTime.Now}";
        return result;
    }
}

Jak widać, użycie CompositeFormat jest szalenie proste. Grunt, żeby to było utworzone tylko raz. A potem i tak wykorzystujemy odpowiednie przeciążenie string.Format.

Wersję ze stringiem interpolowanym dodałem tylko ze względu na dopełnienie obrazu. Pamiętaj, że jednak chodzi o dwa różne scenariusze – interpolowane stringi zawsze znają format. String.Format dostaje go w trakcie trwania aplikacji. Spójrzmy na wyniki:

MethodMeanErrorStdDevRatioRatioSDGen0AllocatedAlloc Ratio
FormatTest494.9 ns10.67 ns28.84 ns1.000.000.0801128 B1.00
CompositeFormatTest468.4 ns10.04 ns27.66 ns0.950.070.0658104 B0.81
InterpolatedTest458.3 ns13.24 ns37.78 ns0.930.090.0658104 B0.81

Tutaj widać, że string.Format i CompositeFormat mają bardzo podobny czas. CompositeFormat jest nieco szybszy, ale czy to będzie zauważalne w prawdziwej apce? Ciężko powiedzieć. Jeśli jednak ktoś zapytałby się mnie, czy warto zmieniać klasyczny string.Format na CompositeFormat, to zdecydowanie powiedziałbym, że nie. Jeśli jednak piszesz nową apkę, przemyśl to, bo w kolejnych wersjach CompositeFormat może dostać większego kopa.

Walidacja danych

W .NET8 mamy kilka nowych atrybutów DataAnnotations. Nie będę ich dokładnie opisywał, bo ich użycie jest dokładnie takie samo lub analogiczne. Po prostu wiedz, że zostały dodane:

RangeAttribute

  • RangeAttribute.MinimumIsExclusive – określa, czy wartość minimalna w [Range] jest otwarta (true), czy zamknięta. Innymi słowy, czy ta wartość ma się zawierać w zakresie,
  • RangeAttribute.MaximumIsExclusive – analogicznie jak wyżej, tylko dotyczy to maksymalnej wartości. Np.:
public class Model
{
    [Range(18, 30, MinimumIsExclusive = true, MaximumIsExclusive = false)]
    public int Age { get; set; }
}

Oznacza, że Age powinien być w zakresie (18, 30>, czyli 18 nie spełnia wymagań (MinimumIsExclusive). Czyli mamy tutaj od 19 do 30 włącznie (MaximumIsExclusive = false).

LengthAttribute

Dodano drugą wartość – maksymalną. Dzięki temu można ustawić walidację na stringa (lub kolekcję), która sprawdzi, czy string ma między min i maks znaków. Np.:

public class Model
{
    [Length(3, 12)]
    public string Name {  get; set; }
}

Teraz Name powinno mieć między 3 i 12 znaków włącznie (3 też będzie ok).

Base64Attribute

O, to jest dość fajne. Sprawdza, czy string jest prawidłowym stringiem w formacie Base64:

public class Model
{
    [Base64String]
    public string Data {  get; set; }
}

AllowedValuesAttribute i DeniedValuesAttribute

One sprawdzają, czy przekazany string znajduje się na liście zezwolonych lub zabronionych stringów:

public class Model
{
    [AllowedValues("mama", "tata", "koń")]
    [DeniedValues("koza")]
    public string Data { get; set; }
}

Niestety te atrybuty działają tylko na stringach. Nie działają na kolekcjach ani na obiektach innych klas pomimo, że w konstruktorze przyjmują tablicę object.

Zipowanie do strumienia

Dostaliśmy nowe operacje zipowania, dzięki którym możemy pakować wszystkie pliki, znajdujące się w konkretnym katalogu, do strumienia.

using (var stream = new MemoryStream())
{
    ZipFile.CreateFromDirectory("dataToZip", stream, CompressionLevel.SmallestSize, false);
}

Te przeciążenia powstały właśnie do tego, żeby nie robić operacji na plikach. Żeby bez sensu nie obciążać dysków, jeśli nie trzeba.

Dodatki w Dependency Injection

Chłopaki w .NET8 wprowadzili KeyedServices. Polega to na tym, że możesz zarejestrować w dependency injection różne serwisy pod różnymi indeksami dla jednego interfejsu.

Załóżmy, że mamy interfejs ISomeService:

public interface ISomeService
{
    void Foo();
}

I teraz chcesz zarejestrować dwa różne serwisy dla tego interfejsu w dwóch „pulach”. Tak to by chyba można było nazwać. Spójrz na rejestrację:

builder.Services.AddKeyedScoped<ISomeService, UserSomeService>("user");
builder.Services.AddKeyedScoped<ISomeService, AdminSomeService>("admin");

Tutaj są zarejestrowane dwa serwisy pod różnymi kluczami (user i admin). Jednak to prowadzi do pewnego problemu. Jak je pobrać? Tak nie da rady:

public SomeController(ISomeService someService)
{
    _someService = someService;
}

Apka się po prostu wywali. Musimy jasno określić, z którego klucza chcemy pobrać dany serwis. Służy do tego odpowiedni atrybut:

public SomeController([FromKeyedServices("user")]ISomeService someService)
{
    _someService = someService;
}

Można to zrobić też bardziej dynamicznie. Najprostszy mechanizm, który tworzyłby odpowiedni serwis w zależności od zalogowanego użytkownika mógłby wyglądać tak:

public class SomeController
{
    [HttpGet]
    public IActionResult Get()
    {
        bool loggedIsAdmin = User.HasClaim("admin", "true");
        string key = loggedIsAdmin ? "admin" : "user";

        ISomeService service = HttpContext.RequestServices.GetRequiredKeyedService<ISomeService>(key);
        service.Foo();

        return Ok();
    }
}

Oczywiście tutaj musimy pobierać serwis ręcznie. Nie da się wstrzyknąć do konstruktora serwisu w zależności od zalogowanego użytkownika. Przynajmniej nie w standardzie.

Oczywiście zawsze można sobie wstrzyknąć IServiceProvider, jednak jeśli to jest robione poza jakąś fabryką, to wtedy raczej będzie złym rozwiązaniem, które nam zrobi Abstract Service Locatora.

Dodatki do IHostedService, czyli większa kontrola nad cyklem życia

O interfejsie IHostedService i po co to jest pisałem w tym artykule – jak korzystać z dobrodziejstw Dependency Injection i tych wszystkich mechanizmów w aplikacji konsolowej (i nie tylko).

Natomiast w .NET8 doszedł nowy interfejs IHostedLifecycleService. On implementuje już znany nam IHostedService, dodając kilka metod, dzięki którym masz większą kontrolę nad cyklem życia Twojej aplikacji.

Ten interfejs wygląda tak:

public interface IHostedLifecycleService : IHostedService
{
    Task StartingAsync(CancellationToken cancellationToken);
    Task StartedAsync(CancellationToken cancellationToken);
    Task StoppingAsync(CancellationToken cancellationToken);
    Task StoppedAsync(CancellationToken cancellationToken);
}

Więc albo implementujesz IHostedService do swojego hosta i nic się dla Ciebie nie zmienia, albo implementujesz IHostedLifecycleService i dostajesz dodatkową kontrolę nad cyklem życia. A metody wywoływane są w takiej kolejności:

  • IHostLifetime.WaitForStartAsync
  • IHostedLifecycleService.StartingAsync
  • IHostedService.Start
  • IHostedLifecycleService.StartedAsync
  • IHostApplicationLifetime.ApplicationStarted
  • IHostedLifecycleService.StoppingAsync
  • IHostApplicationLifetime.ApplicationStopping
  • IHostedService.Stop
  • IHostedLifecycleService.StoppedAsync
  • IHostApplicationLifetime.ApplicationStopped
  • IHostLifetime.StopAsync

Zmiany w konfiguracji aplikacji

Walidacja opcji bez użycia refleksji

O walidacji opcji pisałem już w tym artykule. Natomiast w .NET8 wszedł mechanizm, który możemy używać w kompilacjach AOT – nie używa refleksji. Załóżmy, że model, który chcesz walidować wygląda tak:

public class MyAppConfig
{
    [EmailAddress]
    [Required]
    public string SmtpAdress {  get; set; }
    [Range(1, 10)]
    public int TraceLevel { get; set; }
}

Aby teraz mieć walidację zgodną z AOT, musisz…. poniekąd sam ją napisać. Ale sprowadza się to jedynie do utworzenia pustej klasy:

[OptionsValidator]
public partial class MyAppConfigValidator: IValidateOptions<MyAppConfig>
{
 
}

I to jest dokładnie tyle. Dobrze widzisz. Tutaj są istotne dwie rzeczy:

  • klasa musi być oznaczona jako partial
  • klasa musi posiadać atrybut [OptionsValidator]

W innym wypadku po prostu się nawet nie skompiluje. Na koniec musimy ją jeszcze zarejestrować:

builder.Services.AddSingleton<IValidateOptions<MyAppConfig>, MyAppConfigValidator>();

W efekcie zostanie wygenerowany kod dla klasy MyAppConfigValidator, który będzie miał zaszytą całą logikę walidacji w sobie. I to wszystko zadzieje się bez wykorzystania refleksji. Dzięki temu możesz tego używać w kompilacjach AOT.

Bindowanie opcji bez użycia refleksji

Jeśli chodzi o rejestracje opcji, tj. Configure(TOptions), Bind i Get, to standardowo była do tego wykorzystywana refleksja. W .NET8 w aplikacjach internetowych domyślnie konfiguracja jest realizowana przez generator kodu. Czyli jest to zgodne z AOT i nie wymaga żadnych zmian.

Jeśli jednak chcesz być zgodny z AOT i nie tworzysz aplikacji webowej, musisz na takie działanie jawnie wyrazić zgodę. Wystarczy dodać ustawienie w projekcie:

<PropertyGroup>
    <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
</PropertyGroup>

Nowości w… WPF!

Tak! Dorzucili coś do WPFa 🙂 A konkretnie dwie rzeczy.

Przyspieszenie sprzętowe dla RDP

Mniej interesująca dla mnie jest taka, że aplikacje WPF dostępne zdalnie (za pomocą zdalnego pulpitu – RDP) używały softwarowego przyspieszenia graficznego. Teraz mogą używać hardwareowego, czyli są wspomagane kartą graficzną. Musisz jednak na to wyrazić zgodę. Trzeba w pliku runtimeconfig.json wpisać ustawienie Switch.System.Windows.Media.EnableHardwareAccelerationInRdp z wartością true.

Kontrolka do wyboru folderu

Wreszcie! Po tyyylu latach. Już nie trzeba używać third parties albo kontrolki z Win32, żeby dać użytkownikowi możliwość wyboru folderu. Trochę śmieje się przez łzy, że ktoś to wreszcie ogarnął 😀 W .NET8 możemy już wykorzystywać pełnoprawne okienko WPF:

var openFolderDialog = new OpenFolderDialog()
{
    Title = "Wybierz folder...",
    InitialDirectory = Environment.GetFolderPath(
        Environment.SpecialFolder.ProgramFiles)
};

string folderName = "";
if (openFolderDialog.ShowDialog())
{
    folderName = openFolderDialog.FolderName;
}

Typowe breaking change

W .NET8, jeśli w MinimalAPI używasz IFormFile lub IFormFileCollection, teraz będzie wymagane posiadanie antiforgery token. I tak jest domyślnie. Jeśli chcesz z tego zrezygnować (zastanów się, czy na pewno powinieneś), możesz to zrobić w konfiguracji endpointa:

app.MapPost("/", (IFormFile formFile) => ...)
  .DisableAntiforgery();

Do tej pory, jeśli podawałeś jakąś ścieżkę, np.:

var fileName = @"path\to\file\file.jpg"

na systemach unixowych separatory ścieżki (backslash) były zamieniane na slashe. Czyli to \ na to /. Od werji .NET8 tego nie ma. Usunięcie tego mapowania ma związek z różnymi problemami z uruchomieniem aplikacji, które się zdarzały. Jak sobie z tym poradzić?

  • nie hardkoduj znaków separatora ścieżki. Zamiast tego używaj zmiennej Path.DirectorySeparatorChar,
  • jeśli na systemach unixowych wywołujesz polecenie dotnet, przekazując mu jakieś ścieżki, upewnij się że to są slashe (/), a nie backslashe(\),
  • na systemach unixowych zaktualizuj wszystkie zmienne środowiskowe, które zawierają ścieżki – właśnie w taki sposób, żeby backslashe zamienić na slashe.

Wcześniej, jeśli próbowałeś zapisać coś do zamkniętego pliku (za pomocą FileStream), był rzucany wewnętrzny wyjątek, jednak był on zupełnie ignorowany. Nic się w pliku nie zapisywało, a rezultat operacji wskazywał na powodzenie. Czyli „operacja się udałą, pacjent umarł”.

Teraz, w .NET8, próba takiego zapisu zakończy się rzuceniem wyjątku IOException. Miej to na uwadze.

Do tej pory metoda ManagementDateTimeConverter.ToDateTime(String) zwracała obiekt DateTime z DateTime.Kind ustawionym na wartość Unspecified. Teraz ta wartość jest ustawiona na Local. Więc jeśli na niej polegałeś, koniecznie sprawdź swój kod.

Inne zmiany

W .NET8 wprowadzono też szereg zmian, o których nie piszę w tym artykule z różnych powodów. Niemniej jednak chcę dać Ci szybki dostęp do nich, więc wrzucam interesuące linki:

Breaking changes w .EFCore

Możesz spotkać problemy w starszych serwerach SQL od wersji 2014 w dół (razem z 2014). Co więcej, jeśli używasz JsonDocumentów, to zmienili sposób serializacji enumów. Teraz domyślnie idą intami. Wprowadzono też zmiany w SQLite, CosmosDB i mniejsze.

Mimo wszystko polecam zapoznać się z tym krótki artykułem, być może rozwiąże to Twoje problemy szybciej niż Stack Overflow 🙂

Więcej tutaj: https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-8.0/breaking-changes

Zmiany w Blazor, SignalR, MinimalApis, NativeAOT, Kestrel, Identity

Jest jeszcze kilka fajnych zmian w Blazor. Ale to jest kwestia na zupełnie inny artykuł, więc odsyłam Cię po prostu do źródła.

Ciekawą zmianę dodali też w .NET Identity (o ile możemy to tak jeszcze nazywać). Wprowadzili m.in. endpointy do logowania, wylogowania, pobierania info o użytkowniku itp. Tak out of the box. Ale dla użycia tylko w apkach webowych (nie nadaje się raczej do WebApi).

Więcej tutaj: https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-8.0?view=aspnetcore-8.0


Ufff, to tyle. Dzięki za przeczytanie tego artykułu. Mam głęboką nadzieję, że będzie naprawdę pomocny. A dla Ciebie jakie zmiany były najważniejsze? Daj znać w komentarzu.

Podziel się artykułem na: