Wpis z mikrobloga

Tworze projekt pewnego serwisu w #spring #java .
Sklada sie on z kilku elementow:
- Panel Klienta - generalnie CRUD+ dla danych dotyczacych jego profilu
- Strona klienta - publiczna dostepna pod domena, ktora kieruje do aplikacji, ktora serwuje uzytkownikowi strone danego klienta (template,dane itd)
- w planach apka mobilna dla uzytkownikow(nie bedacych klientami) ktora pozwoli zaciagac pewne istotne dane od wszystkich klientow i serwowac np na podstawie lokalizacji.

Poki co jest to monolit, tyle, ze z logika rozdystrybuowana na serwisy odpowiadajace za konkretne obszary dzialan, ale nadal jednak monolit.
Zaczalem sie zastanawiac czy warto i czy nie jest za pozno zeby zamiast starac sie dobrze dzielic w monolicie, lepiej jednak rozbic to na mikroserwisy? Plus taki, ze np api gateway + user service moglbym potem praktycznie bez zmian uzyc w kolejnych aplikacjach.

Pytam bo chcialbym wiedziec czy nie jest to troche przerost formy nad trescia?

#programowanie
  • 11
@interface: Mikroserwisy z założenia debuguje się łatwiej (chyba, że ktoś kompletnie skopie architekturę)

@fegwegw z główych korzyści to np. nie jesteś uzależniony od konkretnej technologii. Możesz pisać w javie i stwierdzić, że do pewnych zastosowań lepszy będzie python, więc jeden mikroserwis może być pisany w nim. Inna sprawa to, że mikrousługi są tanie. Napisanie pojedynczego serwisu nie powinno zająć więcej niż dwa tygodnie. Więc jeśli coś jest skopane, można to wyrzucić
@dog_meat: pytałem OPa, bo to on miał dylemat.

Z doświadczenia wiem, że 90% takich pytań wynika z braku fundamentalnej wiedzy, coś na zasadzie: 'czytałem w internecie, że mikroserwisy są fajne'.