Wpis z mikrobloga

murki, pisałem ostatnio z pytaniem odnośnie płatnych zleceń w #python ale fakt, nie chce mi się bić z Hindusami o zlecenia za 5$, żeby nauczyć się różnych rzeczy.

Stwierdziłem, że napiszę coś większego po godzinach, żeby przy ewentualnej zmianie pracy mieć fajny projekt w CV i lepsza możliwość negocjacji pensji, jak i przede wszystkim nauczyc się masy rzeczy.
Ponieważ jestem za głupi, żeby wymyśleć coś nowego( o czymkolwiek pomyślałem, to już jest, serio ( ͡° ʖ̯ ͡°)), stwierdziłem, że napiszę coś, co fajnie jakby istniało w większej skali (tak jak ma to miejsce w Estonii) - "ogólnopolski" system umawiania wizyt do lekarza / spięcie kont pacjentów i lekarzy wraz z placówkami. Wizyty, badania, zapisywanie historii, autoryzacja po api jak i hasłami użytkowników + pinami.

Oczywiście nie chcę z tego robić czegoś komercyjnego, stwierdziłem, że warto napisać odnośnie tematyki, na której się względnie znam, a na tym zna się każdy.

Wstępny podział architektury na "aplikacje":
- pacjent
- lekarz
- badania
- placówki

Będą to takie "macro serwisy", że tak powiem, osobne byty, którym zrobię "bramę" przez API / cache gdy będą miały się łączyć. Do tego dodam zapewne jakieś już prawowite micro serwisy, bo chce się ich lepiej poduczyć.

Stack, którego chciałem użyć i go względnie znam, bo mam go w robocie w projekcie to:

- django jako podstawa
- DRF do api
- redis do cachy
- celery
- elastic search
- sql(w orm)
- wrzucę możę apki w dockery, bo akurat z docker'a nie korzystałem, więc fajnie coś wyizolować i przy okazji się poduczyć

jako, że jestem zupełna noga z frontu, przy okazji douczę się js'a i tym podobnych, niby chcę pracować wyłącznie z backend'em ale czasami coś w js muszę poprawić w robocie, więc jednak czas się go poduczyć

czy ktoś z #programowanie i #programista15k moze wstępnie określić sens takiej apki i ewentualnie dodać coś do stacka "technologicznego"? Nie chodzi mi o żadne walory komercyjne itp, liczy się wyłącznie aspekt edukacyjny
  • 15
  • Odpowiedz
Wstępny podział architektury na "aplikacje":

- pacjent

- lekarz

- badania

- placówki


@budyn: Moim zdaniem bez sensu, o powinno być bardziej abstrakcyjne. Serwis grafików, wizyt, użytkowników. A to, że zostanie to użyte przez pacjentów, lekarzy, badania, placówki to swoją drogą
  • Odpowiedz
  • 0
@kebab-case z architektury jestem jeszcze dupa, juniorom raczej nie każą jej tworzyć, tym bardziej w projekcie, który siedzi już ponad 6 lat, dlatego dzięki wielkie za uwagę.

@budyn to byłaby robota na kilka miesięcy. Chciałem zacząć. Od czegoś, co znam ( stack) ale samemu wszystko ustawić itd. Trudno jest mi powiedzieć, że ogarniam celery, skoro ja osobiście tylko dorzucam taski do konkretnych miejsc, albo korzystam z funkcji, która wyciąga dane z cache,
  • Odpowiedz
@michael93pl: Wydaje mi się że trzeba pisać rzeczy które są dla ciebie ciekawe, sztuka dla sztuki to opcja którą przerobiłeś na studiach. Imo nie ma sensu, i projekt którego nie potrzebujesz będzie ciężki do dopracowania i skończenia. A nieskończonego nie będziesz chciał pokazać, prawda? ( ͡° ͜ʖ ͡°)

Co do technologii to się nie wypowiadam bo to nie moje technologie ( ͡ ͜ʖ ͡
  • Odpowiedz
z architektury jestem jeszcze dupa, juniorom raczej nie każą jej tworzyć, tym bardziej w projekcie, który siedzi już ponad 6 lat, dlatego dzięki wielkie za uwagę.


@michael93pl: może się mylę bo ja nawet juniorem nie jestem, ale koncepcja mikroserwisów jest jasna, każdy serwis ma być użyteczny sam w sobie i reużywalny, jak na szytwno to powiążesz z jakąś logiką to ja nie wiem gdzie tego użyjesz drugi raz ¯\_(ツ)_/¯
  • Odpowiedz
@michael93pl: a czujesz motywację do pisania czegoś takiego? jak myślałbym że robię klona znanegolekarza to tak słabo z mojej perspektywy, motywujące(i tutaj mówię przez pryzmat aspektu edukacyjnego, aby chciało się żeby to się rozwijało) dla mnie byłaby użyteczność czegoś takiego - dlatego sympatycznie mi się pracowało swojego czasu na danych o kolejkach z nfzu i parę razy nawet użyłem tego w praktyce szukając w lepszy sposób miejsca do rejestracji niż przez
  • Odpowiedz
  • 1
@kebab-case dlatego nazwałem apki " macro serwisami" -> po prostu oddzielenie pewnych aspektów aplikacji od siebie ale fakt, one nie mogą istnieć bez siebie, nie są to prawdziwe micro serwisy. Zakładam, że po prostu to słaby pomysł, żeby to trzymać wszystko razem i mieć wielkiego "monolitha"
  • Odpowiedz
  • 0
@ntskj dzięki, przejrzę ^^
Nie wiem jeszcze właśnie, chciałem zrobić coś komercyjnego ale jestem chyba na to zbyt tępy i nie mam zmysłu do tego. Chciałem napisać coś większego, żeby się uczyć, lubię siedzieć po pracy i napieprzac ale małe apki mnie szybko nudzą.
  • Odpowiedz
@michael93pl: Jeżeli chcesz wybrać Django do makroserwisów albo mikro to będziesz miał dużo problemów, chyba że przerobisz ich system bazodanowy. Django jest do monolitów, co nie jest złym rozwiązaniem.
Jeżeli chcesz iść w micro / macroserwisy lepiej jest wybrać flaska i sqlalchemy.
  • Odpowiedz
@SharkyShark: o, chętnie poczytam o flasku + alchemy w tym kontekście. Wiem, że django wiele narzuca przy tworzeniu i pod tym względem flask + sqlalchemy jest lepsze ale ogólnie(pewnie błędnie) flask kojarzy mi się z czymś bardzo "surowym"
  • Odpowiedz
Niestety ale microserwisy w pythonie są "surowe", zresztą zastanów się dobrze czy ta architektura jest dla Ciebie dobra, microserwisy wiążą się z tym że musisz dobrze rozplanować ich połączenia, co będzie jak jeden serwis wypadnie. Do tego dochodzi cała konteneryzacja, dużo trudniejsze debugowanie apki i i jej monitorowanie.
Wiem, że teraz jest hype na microserwisy, ale tak naprawdę nie wiem czy w pojedynkę bym się brał za to, dużo roboty.
  • Odpowiedz
@SharkyShark: dopiero teraz zobaczyłem
Wiesz co, to nie tyle hype z mojej strony ale chęć nauki. Chce napisać coś, co wymaga logowania, cachowania danych w redisie,obcykać się trochę lepiej z metodami w modelach i managerach, komunikacji z api(nałożyć auth i permissions i spiąć kilka endpontów), celery i elastic searcha.
Fakt, wszędzie słyszę "microserwis" ale osobiście nie mam jakiejś presji na to.

Wziąłem sobie 5 dni wolnego bo miałem trochę spraw i
  • Odpowiedz
@michael93pl: Na pewno to jest dobra droga ucząc się niż dorabiając po 10$ .
Czasami lepiej jest pójść mniejszymi krokami. Sama architektura microserwisów wymaga bardzo duży narzut i dlatego monolit nie jest wcale gorszym rozwiązaniem. Szczególnie że możesz zrobić tak, że pierwsza wersja będzie na monolicie, później zobaczysz co spieprzyłeś w architekturze, refaktoring kodu na powiedzmy macro serwisy, znów będziesz mógł zobaczyć co spieprzyłeś i pójść w microserwisy.

Jednak jeżeli chcesz
  • Odpowiedz