od Podstaw
6 godz. 26 min · Go · Full-stack i Programowanie
Piotr KrzesajW Go wszystko opiera się o typy. Czym one są? Tak zwane typy proste(string, int, float itd.) to tylko początek, interfejsy, struktury i nie tylko. Pokażę Ci jak używać wielu wątków Go i jakie są sposoby komunikacji między nimi, a także opowiem i pokażę na praktycznych przykładach jakie zagrożenia niesie ze sobą wykorzystywanie wielowątkowości.
W Go nie mamy obiektowości znanej z wielu innych języków. Posiada zalążki obiektowości ale sprawia to wielu osobom problemy jak podejść do architektury aplikacji. Nauczę Cię jak podejść do funkcyjności w taki sposób aby wciąż nawet duże aplikacje były łatwo rozwijalne lub co ważniejsze, była możliwość podzielenia ich na mniejsze mikroserwisy gdy zajdzie taka potrzeba.
Wśród programistów można usłyszeć głosy że w Go wielowątkowość jest świetnie rozwiązana i trudno się z tym nie zgodzić ale warto pamiętać że nasze mózgi działają jednowątkowo i często pomijamy zagadnienia takie jak wyścig wątków, deadlock i inne wyzwania, które stawia przed nami praca na dzisiejszych procesorach. Pokażę i wytłumaczę Ci w praktyce większość z nich i jak sobie z nimi radzić i na co uważać. Jeśli nie pracowałeś z językami wielowątkowymi to ta sekcja jest specjalnie dla Ciebie.
Zastanawiałem się wiele razy czy nie istnieje taka technologia w której piszę sobie jeden pliczek i z tego pliku do każdego języka mogę wygenerować sobie klienta i serwer jedną komendą. To jest w wielkim skrócie GRPC, nie musisz się przejmować czy używasz HTTP 1.1/2.0, czy używasz websocketów do transmisji, czy przesyłasz dane w formacie JSON, XML, Protobuf, czy jest moje API kompatybilne wstecz. Tym wszystkim zajmuje się GRPC. Wyjaśnię Ci czym dokładnie jest, dlaczego jest super i wreszcie jak tego używać razem z językiem Go. Napiszemy praktyczny projekt chatu w którym wykorzystamy funkcję server-streaming.
Pisząc aplikację chcemy aby uruchamiała się ona tak samo niezależnie czy uruchamiamy ją na Linuxie, macOS czy na Windowsie i z pomocą przychodzi nam Docker. Pokażę Ci jak z gotowej aplikacji napisanej w Go stworzyć obraz Dockerowy aby móc go uruchamiać na swoim komputerze bądź serwerze. Pokażę Ci również jak nasz obraz Dockerowy połączyć z bazą danych za pomocą Docker Compose aby móc cieszyć się działającą aplikacją uruchamianą jedną komendą.
Kurs Go nie mógłby obejść się bez serwera HTTP stworzonego tylko z pomocą biblioteki wbudowanej w język Go. Dokładnie tak, nie musisz instalować nic poza językiem i już możesz tworzyć serwery co jest świetną wiadomością. Następnie pokażę Ci popularną bibliotekę Gin do tworzenia serwerów. Dzięki temu zobaczysz różnice i ocenisz czy warto zostać przy wbudowanej bibliotece czy może używać zewnętrznych.
Jak w każdym języku serwerowym tak i w Go możemy się podłączyć pod bazę danych. Krok po kroku wyjaśnię Ci jak to zrobić prosto i przyjemnie używać baz SQL, które od dziesiątek lat cieszą się niezwykłą popularnością. Migracje, zapytania czy dbanie o połączenie to nie będzie dla Ciebie nic trudnego.
Ten Kurs powstał z myślą o osobach, które chciałyby poszerzyć swoją wiedzę o język Go. Zakłada on że posiadasz już wiedzę z minimum jednego innego języka programowania i wiesz w jaki sposób działa komunikacja po protokole HTTP. Możesz też znać Go i chcieć zobaczyć jak dzielić programy na paczki tak aby były łatwo rozwijalne w przyszłości.
Zanim zaczniemy pracę i tworzeniem naszego własnego czasu musimy
się dowiedzieć co to w ogóle jest i po co to zostało stworzone.
Tworzenie API jest czymś co ma rozwiązać problem komunikacji strony internetowej z
pakietem aplikacji mobilnej czy dwóch mikro serwisów.
Znamy dobrze API tzw.
tekstowe czyli takie w którym mamy kilka zapytań mamy kilka rodzajów odpowiedzi
mamy kody błędów mamy różne rodzaje pilotów czyli np.
Jackson XML HTML czy zwykły tekst itd.
Dalej musimy się martwić jeśli chcemy np.
używać pakietów to musimy dbać o
połączenia co przesyłane w jaki sposób itd.
Wiele lat temu zostało stworzone PC i służy to do tego aby wykonywać normalnie
nazywa się funkcję zdalnie przez inny kontekst i kontekst mam na myśli np.
w tym przypadku przez HTTP
zamiast specjalnie do tego służących end point czyli np.
po stworzenie użytkownika wreszcie będzie to zapytanie typu POST ukośnie Józek a
będzie to józek czyli normalnie nazywa się funkcja która jasno mówi co robi.
No dobrze ale to tylko nazwę.
W czym jest lepszy od miasta więc tworzymy na początku plik w którym
definiujemy wszystkie modele obiekty strukturę i funkcje.
I na podstawie tego automatycznie
generowany jest klient i serwer lub serwer.
Do wszystkich popularnych popularnych języków dodatkowo automatycznie
jest kompatybilne wstecz czyli opisując coś nowego nie tracimy stałych klientów
tylko nie są po prostu obsługiwane nowe metody.
Istnieje coś takiego jak słabe GUI więc
jest to coś podobnego jeśli chodzi o dokumentację.
Ale oprócz tego nie musimy się martwić w
przypadku czy używamy HTTP 1.1 czy HTTP 2.0.
Nie musimy się martwić jakie teksty są wysyłane a jakie nie są wysyłane.
Cały interfejs jest generowany
automatycznie i nie musimy się martwić że klient nie obsługuje HTTP 2.0.
A wymaga HTTP 2.0.
Nie musimy się martwić o dbanie o to że wysyłamy to w poprawnym formacie danych
nie musimy się martwić o wydajność dlatego że zawartość może być nawet o 30 proc.
mniejsza niż np.
zawartość ta sama wysłana telefonem
a do tego może to być szybsze nawet ośmiokrotnie od klasycznej komunikacji.
Dodatkowo mamy automatycznie wsparcie nie
tylko dla Request ale też dla Streamu czyli połączenia
którego podczas którego można przesyłać dane coś w rodzaju Web sekretów.
Tylko wiadomo jaka jest struktura i jasno
jest to sprecyzowane w jaki sposób to robimy.
I żadna strona nie musi dbać o to dlatego
że klient serwer jest generowany automatycznie.
Jednak mimo wszystko moim zdaniem
największą zaletą jest zmuszenie programistów do używania tzw.
schizmy czyli schematu czyli ten plik o którym mówiłem wcześniej na podstawie
którego muszą wygenerować ten klient bądź sekretariatu komunikacji.
Powoduje to jedynie problem podczas projektowania takiego interfejsu
i podczas generowania klienta i serwera czyli walka z samym automatem czyli
napisanie tak naprawdę poprawnej komendy do generowania tzw.
protokołów czyli plików które są generowane na podstawie tego schematu
i zapraszam do następnej lekcji w której zaczniemy pisać nasz projekt.