Jak implementovat aplikace .NET MAUI s Blazor a nativními platformami

Pro efektivní integraci .NET MAUI aplikací s Blazor a nativními platformami je nutné pochopit, jak správně nastavit a konfigurovat různé části architektury aplikace. V tomto případě budeme pracovat s projektem Northwind.Maui.Blazor.Client a ukážeme si, jak implementovat různé API endpointy, jak povolit nešifrované připojení a jak správně použít vzor Model-View-ViewModel (MVVM) pro usnadnění vývoje a údržby aplikace.

Začneme konfigurací webového serveru a integrací s Swaggerem pro zjednodušení dokumentace a testování našich API endpointů. V rámci projektu .NET je možné vytvořit REST API, které umožňuje manipulaci s daty, jako jsou kategorie v databázi Northwind. K tomu používáme služby jako builder.Services.AddEndpointsApiExplorer() a builder.Services.AddSwaggerGen(). Swagger generuje dokumentaci, která usnadňuje testování našich API přímo z prohlížeče.

Další krok, který musíme provést, je povolení nešifrovaných HTTP připojení pro platformy iOS a Android v rámci aplikace .NET MAUI. Tato konfigurace je nezbytná pro umožnění komunikace mezi mobilní aplikací a naším webovým API během vývoje, kdy může být šifrování HTTPS dočasně neaktivní.

Pro iOS otevřeme soubor Info.plist a přidáme nový klíč NSAppTransportSecurity s hodnotou NSAllowsArbitraryLoads, čímž umožníme nešifrované připojení. Na Androidu je potřeba vytvořit soubor network_security_config.xml, ve kterém povolíme připojení přes specifickou IP adresu, která bude mapovat na localhost, a následně tuto konfiguraci zaregistrujeme v AndroidManifest.xml.

V neposlední řadě je důležité se zaměřit na implementaci vzoru MVVM (Model-View-ViewModel). Tento vzor je klíčovým prvkem pro rozdělení logiky aplikace na tři části: Model, View a ViewModel. Model reprezentuje data aplikace, například objekty typu Category nebo Product. ViewModel obsahuje logiku pro manipulaci s daty a také definuje vlastnosti, které budou svázány s uživatelským rozhraním. View představuje samotnou vizualizaci aplikace, která se mění v závislosti na změnách ve ViewModelu. Tento přístup umožňuje snadnější testování, rozšiřování a údržbu aplikace.

Jedním z problémů při implementaci MVVM v .NET MAUI je nutnost použít boilerplate kód, například implementaci rozhraní INotifyPropertyChanged, které zajišťuje, že se při změně dat v modelu automaticky aktualizuje i uživatelské rozhraní. Abychom si usnadnili práci, můžeme použít nástroje, jako je CommunityToolkit.Mvvm.ComponentModel, které automatizují tento proces. Důležité je vědoma si toho, že pokud náš model už dědí z jiné třídy, budeme muset použít speciální atributy, které zajistí, že všechny změny vlastností budou správně reflektovány ve View.

Jak implementovat a spravovat limitování rychlosti API pomocí ASP.NET Core

V moderních webových aplikacích, kde je interakce s externími službami a API stále častější, je kladeno velké důraz na správu zátěže a ochranu před přetížením serverů. Jedním z účinných způsobů, jak tomu zabránit, je použití techniky limitování rychlosti (rate limiting). Tento přístup nejen že chrání API před zbytečným zatížením, ale také umožňuje rovnoměrné a spravedlivé využívání zdrojů všemi uživateli. V této kapitole se podíváme na to, jak implementovat limitování rychlosti API pomocí middleware v ASP.NET Core a jak správně reagovat na chyby, které vzniknou, když uživatelé překročí stanovený limit.

Limitování rychlosti v API může být implementováno různými způsoby, včetně používání klientských ID, která slouží k rozlišení jednotlivých požadavků. V příkladu, který je součástí této kapitoly, se podíváme na způsob, jakým klientská aplikace využívá své unikátní identifikátory pro odesílání požadavků na server, který tyto požadavky následně kontroluje a omezuje podle stanovených pravidel.

Proces odesílání požadavků

csharp
Copy code
client.DefaultRequestHeaders.Accept.Add(new("application/json"));
client.DefaultRequestHeaders.Add("X-Client-Id", clientName);

Chyby limitování rychlosti

Při překročení limitu požadavků server vrací odpověď 429 spolu s hlavičkou „Retry-After“, která udává, kolik sekund musí klient čekat před tím, než bude moci znovu poslat požadavek. Tento proces je důležitý pro správné řízení zátěže a umožňuje aplikaci reagovat na přetížení serveru tím, že zajistí, aby každý klient měl rovnoměrný přístup k serverovým zdrojům. Příklad chybové zprávy z API vypadá následovně:

makefile
Copy code
07:32:21: 429: API calls quota exceeded! maximum admitted 2 per 10s.

07:32:22: Retry after 8 seconds.

Pokud aplikace klienta správně zpracuje tuto chybu, měla by automaticky počkat uvedený čas a znovu zkusit požadavek. To může být dosaženo pomocí následujícího kódu:

csharp
Copy code
string retryAfter = response.Headers
   .GetValues("Retry-After").ToArray()[0];
if (int.TryParse(retryAfter, out waitFor)) {
   WriteLine($"Retry after {waitFor} seconds.");
}

Logování a sledování chyb

vbnet
Copy code
info: Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware[1]
Request:
   Protocol: HTTP/1.1
   Method: GET
   Path: /api/products

   X-Client-Id: console-client-d54c61ba-66bb-4e39-9c1a-7af6e2bf647e

info: AspNetCoreRateLimit.ClientRateLimitMiddleware[0]
Request get:/api/products from ClientId console-client-d54c61ba-66bb-4e39-9c1a-7af6e2bf647e has been blocked, quota 2/10s exceeded by 3.

Tato informace může být velmi užitečná při diagnostice problémů s přetížením nebo při ladění aplikace, kde se požadavky neustále opakují i přes to, že klient již překročil svůj limit.

Upravitelné limity pro různé klienty

bash
Copy code
Rate limit pro klienta „dev-id-1“ není aplikován.
Rate limit pro klienta „console-client-abc123“ je jiný.

Tato flexibilita umožňuje, že různí klienti mohou mít různou prioritu nebo různý přístup k API, což může být užitečné pro aplikace s více úrovněmi přístupu, například pro vývojáře, kteří mají zvýšený limit oproti běžným uživatelům.

Závěrečná poznámka

Kromě samotného limitování je nezbytné, aby aplikace dokázala efektivně reagovat na překročení limitu, zpracovávala chybové kódy správně a poskytovala uživateli dostatečné informace, jako je doba čekání, než bude možné provést další požadavek. Správně implementované limitování rychlosti chrání API před zbytečným přetížením a zajišťuje plynulý a efektivní přístup k serverovým prostředkům.

Jak efektivně používat OData pro získávání dat přes web?

OData je otevřený protokol, který umožňuje snadný přístup k datům prostřednictvím webových služeb. Tento protokol umožňuje interaktivní práci s daty ve formě REST API a je silně využíván pro zajištění přístupu k datovým zdrojům na webu, což je zvláště užitečné při práci s databázemi a systémy pro správu produktů. OData umožňuje snadné a efektivní dotazování, filtrování, řazení a procházení vztahů mezi entitami, což se ukáže jako nezbytné při práci s velkými množstvími dat.

Jedním z hlavních výhod OData je schopnost flexibilně vyhledávat specifické záznamy nebo skupiny záznamů podle předem definovaných parametrů. Tento protokol umožňuje definovat různé dotazovací možnosti pomocí URL parametrů. Mezi nejdůležitější možnosti patří $select, $expand, $filter, $orderby, $skip a $top. Každý z těchto parametrů slouží k dosažení specifických cílů při dotazování na data.

Pokud se rozhodnete pro použití $expand, umožňuje vám tento parametr načíst související entity v jednom požadavku. To znamená, že místo provádění několika dotazů na jednotlivé kategorie a produkty, můžete je získat v jednom komplexním dotazu. Takový přístup šetří čas a zjednodušuje práci s daty.

Parametr $orderby slouží k seřazení výsledků podle specifikovaných vlastností. Tento parametr může být užitečný, když chcete získat produkty seřazené podle ceny, nebo chcete-li řadit položky podle názvu. Tímto způsobem lze snadno optimalizovat způsob prezentace dat uživateli, ať už ve formě seznamu produktů nebo tabulky.

Další praktickou funkcí je $skip a $top, které vám umožňují ovládat stránkování výsledků. Pokud máte na serveru tisíce produktů, je efektivní rozdělit výsledky na menší dávky a načítat je po částech, což pomáhá zlepšit výkon a uživatelskou zkušenost. Parametry $skip a $top lze kombinovat pro přizpůsobení počtu zobrazených položek, což je ideální pro implementaci stránkování na webových stránkách nebo v aplikacích.

Kromě operátorů má OData také funkce, které mohou být užitečné při práci s textovými a datovými hodnotami. Funkce jako startswith, endswith, contains, nebo concat umožňují provádět pokročilé operace nad textovými řetězci, jako je hledání řetězců začínajících nebo končících na určitý text, nebo sloučení dvou textových hodnot do jedné. Tyto funkce poskytují flexibilitu při práci s daty, která mají složitější strukturu.

Další důležitou funkcí je now, která vrací aktuální datum a čas. Tato funkce může být užitečná při filtrování dat podle data, například při vyhledávání produktů, které byly přidány do katalogu v posledních 30 dnech.

V praxi je práce s OData zjednodušena díky standardizovaným URL konvencím a dokumentaci, která vysvětluje, jak tyto dotazy správně formulovat. Příklady dotazů, jako je požadavek na produkty s určitou cenou nebo filtrování produktů podle počátečního písmena názvu, ukazují, jak tento přístup efektivně využít při hledání konkrétních dat.

Závěrem je důležité si uvědomit, že efektivní využití OData vyžaduje správné pochopení struktury dat, které se používají v dotazech, a schopnost optimalizovat dotazy pro lepší výkon. Správné používání parametrů pro filtrování, řazení a stránkování může výrazně zlepšit výkon aplikace a zpřehlednit uživatelský zážitek. Naopak, nepřiměřené nebo složité dotazy mohou vést k pomalejšímu načítání dat a nižší efektivitě aplikace.

Jak získat metadata z gRPC volání a proč je důležité nastavit deadline

Při práci s gRPC službami nejsou jediným způsobem přenosu dat mezi klientem a serverem formálně definované request a response objekty. Vedle těchto standardních zpráv lze využít i metadata ve formě hlaviček (headers) a ukončovacích metadat (trailers), které představují jednoduché slovníky předávané spolu s hlavním obsahem komunikace. Tato metadata lze snadno číst na klientské straně, například v ASP.NET Core MVC aplikaci, a poskytují dodatečné informace o probíhajícím volání – například datum volání, server, stavové kódy a další relevantní informace.

Chceme-li tato metadata zachytit, potřebujeme použít objekt typu AsyncUnaryCall, který umožňuje získání hlaviček volání přes metodu ResponseHeadersAsync. Po zavolání služby bez awaitu je možné metadata extrahovat a zapsat do logu. Výstup v logu, pokud je správně nakonfigurován, pak zobrazí klíčové hodnoty jako date a server, které server připojuje k odpovědi. Stejně tak můžeme po ukončení volání získat tzv. trailers – metadata přenášená na konci komunikace – pomocí metody GetTrailers.

Tato technika je zvláště užitečná při ladění služeb, sledování výkonu nebo zaznamenávání bezpečnostně relevantních informací. Pokud chceme tyto záznamy sledovat důsledně, je nezbytné upravit konfiguraci úrovně logování v souborech appsettings.Development.json, aby bylo možné zaznamenat i informace a varování namísto výchozích výstrah.

Dalším zásadním prvkem při navrhování robustních gRPC služeb je nastavení tzv. deadline – časového limitu, do kdy má být odpověď poskytnuta. Deadline omezuje maximální dobu běhu volání a chrání tak klienta i server před zbytečným zatížením systémových prostředků. Pokud server nedokončí práci v přiděleném čase, klient požadavek přeruší a zaznamená chybu s kódem DeadlineExceeded. Deadline se odesílá v rámci požadavku, což umožňuje serveru rozhodnout se, zda má práci přerušit, pokud je již překročen časový rámec.

V ukázce implementace serverová metoda GetShipper uměle zpožďuje odpověď o pět sekund. Na straně klienta je pak při volání nastavena třís­ekundová deadline. Výsledkem je, že i když server nakonec odpověď připraví, klient už ji nezpracuje a výsledek je chybový stav s informací o překročení časového limitu. Tento scénář nejen simuluje reálné síťové podmínky, ale zároveň ukazuje správné zacházení s výjimkami, které je třeba na klientské straně ošetřit – zejména výjimky typu RpcException s příznakem DeadlineExceeded.

Přesná správa metadat a nastavení deadline tak tvoří zásadní součást konstrukce efektivních a škálovatelných mikroslužeb. Je to nejen technická nutnost, ale i praktické opatření pro vyšší spolehlivost, predikovatelnost a bezpečnost distribuovaných systémů.

Při návrhu a implementaci je důležité chápat rozdíl mezi hlavičkami (headers) a trailery. Hlavičky přicházejí ještě před samotnou odpovědí – lze je tedy využít například pro předběžné ověření, sledování verzí API nebo stavových indikátorů. Trailers přicházejí až po přenosu obsahu a mohou obsahovat diagnostické nebo výstupní informace, které souvisejí s konečným výsledkem volání.