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.
Aby zaplanować sobie pracę i sposób podzielenia naszego projektu warto myśleć
o tym w jaki sposób nasz program może się rozwijać w przyszłości.
Możemy chcieć podzielić sobie ten kod na mniejsze kawałki które będą razem
współpracować niezależnie od siebie jako niezależne mikro serwisy
mikro serwisy to są takie niezależne od siebie działające programy komunikują się
najczęściej ze sobą i odpowiedzialne za jedną rzecz.
Na przykład jeden wniosek
jest odpowiedzialny za płatności i na podstawie tego mikro serwisu
odpowiedzialnego za płatności możemy sobie i innym np.
dać dostęp do jakiegoś pliku za które
użytkownik zapłacił bądź też nie bo nie zapłacił.
No dobrze mamy pierwszy problem czyli jak się przygotować na to żeby nasz program
był łatwy do ewentualnego podzielenia na małe mikro serwisy.
Jak do tego podejść.
Jest oczywiście masa sposobów na to aby to
zrobić i jednym z nich jest to aby dzielić nasz program tak aby w jednej paczce było
wszystko od początku do końca co jest odpowiedzialne za komunikację np.
komunikację z bazą danych pobieranie
jakieś informacje z pakietu i zwracanie gotowych danych do użytkownika.
Dzięki temu że będzie to umieszczone w jednej paczce nie powinno być większego
problemu aby to później rozdzielić na dwa niezależnie działające serwisy
to jest jeden sposób i z mojego doświadczenia wynika że najlepsze
wciąż mamy oddzielną bazę danych od logiki biznesowej mimo że jest w jednej paczce co
wielu programistów mimo wszystko uważa często za błąd i tak moim zdaniem jest to
błąd jeśli te paczki są duże ale jeśli to mimo wszystko jest mała paczka to moim
zdaniem nie powinno być z tym problemu dlatego że wciąż stosujemy separację i
dzięki temu jest to łatwe w testowaniu łatwe w rozwijaniu i utrzymaniu.
Czyli na przykładzie naszego projektu
który będziemy pisać w następnych lekcjach stworzyli byśmy np.
paczkę user w której byłby interfejs do bazy danych ze wszystkimi niezbędnymi
rzeczami do tego aby móc założyć konto czyli np.
Insight żeby móc spotkać użytkownika czyli
to będzie Select sprawdzić jego ideę i zaktualizować albo np.
wygenerować Access Token po zalogowaniu itd.
A następnie Nasza logika biznesowa czyli w
tym przypadku user serwis i znowu byłby to interfejs i
zaprezentujemy go w jakiejś strukturze która będzie faktyczną logiką.
Dzięki temu jeśli będziemy chcieli np.
zmienić bazę danych zupełnie np.
na S.A. albo usunąć Google'a i użyć czegoś
innego co daje nam mimo wszystko większe możliwości to nie musimy zmieniać logiki
biznesowej czyli naszego języka serwisu tylko zmieniamy nasz interfejs od bazy
danych i dbamy tylko o to żeby działał w ten sam sposób.
Na samym końcu w jaki działało wcześniej.
Co więcej dzięki integracji
możemy pozbyć się bazy danych i zamiast tej bazy używać jakiegoś zewnętrznego API
do tego aby dokładnie te rzeczy robić czyli np.
stworzyć użytkownika.
Nie wiem jaka byłaby w tym momencie potrzeba ku temu ale można.
A jeśli na końcu będziemy chcieli
wydzielić nasz serwis spośród innych serwisów np.
Payment Services to zamiast wyciągać go na początku możemy od razu stworzyć drugi
plik mail czyli będziemy mieli dwa pliki mail i w
zależności od potrzeb budować aplikacje w taki sposób aby działał tylko jeden serwis
albo tylko Payment Services czyli będziemy mieli na końcu dwie aplikacje
w jednym folderze w którym będą obie te funkcjonalności.
Co więcej dzięki takiemu podziałowi możemy
mieć dwa mikro serwisy a przykładowo chcemy użyć tylko Amazon lampy do tego aby
stworzyć kolejny plik mango i mieć dwa mikro serwisy i np.
Lambda w jednym Lambda to jest taki sam
okres i to działa trochę inaczej niż mikro serwisy a jeśli chcemy wydzielić to do
osobnego repozytorium dlatego że tak bardzo to urosło to po prostu
wyciągamy tę jedną paczkę i zależności do tej paczki i gotowe.
Celem planowania pracy jest w tym
przypadku sprawienie aby jak najmniej rzeczy nas ograniczało.
Co z tego że wszystko wrócimy do jednej paczki jeśli okaże się że nie jesteśmy w
stanie tego w żaden sposób rozwijać i utrzymać ani testować.
No bo co jeśli w pewnym momencie chcemy napisać testy dla naszej aplikacji musimy
sobie zadać pytanie czy jesteśmy na to gotowi.
Z doświadczenia wiem pracując w firmach że
im bardziej jesteś przygotowany na różne zmiany i niespodziewane zwroty akcji tym
lepiej ale oczywiście nie należy przesadzać wtedy drugą stronę
jeśli chodzi o pokazanie w jaki sposób można planować swoją pracę w języku Gallo
to w tej lekcji to wszystko i zapraszam Cię do kolejnej.