Exporty i eventy FiveM: Komunikacja między zasobami

Eventy a exporty: kiedy używać których

FiveM zapewnia dwa podstawowe mechanizmy komunikacji między zasobami: eventy i eksporty. Eventy są z natury asynchroniczne i działają w trybie fire-and-forget, co czyni je idealnymi do powiadomień, logowania i wywoływania efektów ubocznych między zasobami. Eksporty z kolei to synchroniczne wywołania funkcji, które natychmiast zwracają wartości, dzięki czemu sprawdzają się idealnie do pobierania danych i funkcji pomocniczych. Wybór właściwego mechanizmu dla danego zastosowania jest kluczowy do pisania czystego i łatwego w utrzymaniu kodu FiveM.

Eventy serwera i klienta

Eventy w FiveM przepływają w określonych kierunkach. TriggerServerEvent wysyła dane z klienta do serwera, gdzie mogą być bezpiecznie obsłużone. TriggerClientEvent wysyła dane z serwera do jednego lub wszystkich klientów przy użyciu identyfikatora source gracza lub -1 do transmisji broadcast. Lokalne eventy wywoływane za pomocą TriggerEvent pozostać w tym samym kontekście wykonywania. Zawsze rejestruj zdarzenia sieciowe za pomocą RegisterNetEvent przed dodaniem handlerów i pamiętaj, że każde zdarzenie zarejestrowane po stronie klienta może potencjalnie zostać wywołane przez cheaterów za pomocą injectorów.

Zabezpieczanie twoich eventów

Event handlery po stronie serwera powinny zawsze walidować przychodzące dane. Sprawdź, czy gracz źródłowy istnieje, zweryfikuj zgodność typów danych z oczekiwaniami i zastosuj rate limiting, aby zapobiec spamowi. Nigdy nie przekazuj wrażliwych informacji, takich jak identyfikatory z bazy danych, przez eventy klienta bez weryfikacji. Powszechnym wzorcem jest stosowanie callbacków po stronie serwera: klient żąda danych, serwer waliduje żądanie i pobiera informacje, a następnie wywołuje event odpowiedzi zwrotnej do tego konkretnego klienta.

Praca z exportami

Exports pozwalają jednemu resource udostępniać funkcje, które inne resources mogą wywoływać bezpośrednio. Definiujesz exports w swoim fxmanifest.lua i zaimplementuj je w swoich plikach skryptów. Gdy inny zasób wywołuje exports['your-resource']:YourFunction(args), wykonuje się synchronicznie i zwraca wynik. Jest to szczególnie przydatne w przypadku framework bridges, współdzielonych bibliotek narzędziowych oraz uzyskiwania dostępu do danych ze skryptów telefonu, systemów ekwipunku lub menedżerów prac bez ścisłego wiązania zasobów przez eventy.

Callbacki i wzorce asynchroniczne

Wiele frameworków FiveM implementuje systemy callbacków, które łączą eventy z obsługą odpowiedzi. QBCore używa QBCore.Functions.CreateCallback na serwerze i QBCore.Functions.TriggerCallback po stronie klienta. ESX ma podobny wzorzec z ESX.RegisterServerCallback. Te wywołania zwrotne pozwalają klientowi żądać danych z serwera i odbierać je w funkcji callback, łącząc asynchroniczne zdarzenia z kodem działającym synchronicznie. Zrozumienie tych wzorców jest kluczowe podczas pracy z zapytaniami do bazy danych lub sprawdzaniem ekwipunku, które wymagają autoryzacji serwera.

Dobre praktyki dotyczące komunikacji między zasobami

Stosuj przestrzenie nazw w nazwach eventów, aby uniknąć kolizji, na przykład według wzorca resourceName:eventAction. Przejrzyście dokumentuj swoje exporty, aby inni programiści mogli integrować się z Twoim zasobem. Unikaj tworzenia zależności cyklicznych, w których dwa zasoby eksportują do siebie nawzajem, ponieważ może to powodować problemy z kolejnością ładowania. Projektując API dla swoich skryptów, wybieraj exporty do prostego dostępu do danych, a eventy do złożonych procesów obejmujących wiele kroków lub efekty uboczne w różnych częściach serwera.