Wrzucasz gista do jednoplikowej aplikacji w Railsach to Ci odpisuję, że w Sinatrze to jest dużo prostsze i przejrzystsze. Argument ze studentów może nie jest specjalnie istotny w kontekście budowania złożonej aplikacji komunikującej się po RESCie, ale jest niewiele mniej związany z dyskusją niż Twoje zachwyty nad jednoplikową apką raislową.
Dywagacje na temat AR vs DM to faktycznie offtop pokazuje jednak filozofię Railsów, która w pewnym momencie zaczyna przeszkadzać.
Przykłady Codeclimate (jak sądzę ze względu na skrótowość) nie unikają jednego z podstawowych błędów - twardego powiązania klas poprzez wywołanie metod klasowych (User.new, etc.)
BTW - ile to ma związku z meritum to niech każdy już sam oceni
IMHO i Sinatra i Railsy mają swoje miejsce. Lubię pisać w obu frameworkach i na pewno podoba mi się prostota sinatry, ale jak zaczynasz pisać w sinatrze, to musisz być w miarę pewien, że ta aplikacja pozostanie względnie mała. Jak sie rozrośnie, to zaczną sie problemy z czasem bootowania (a w sinatrze nie ma żadnego reloadowania kodu domyślnie) i innymi rzeczami, do których ten framework nie jest po prostu przystosowany. I wtedy albo jak najszybciej rozbijas na mniejsze aplikacje albo przepisujesz na railsy.
Są jeszcze ludzie, którzy w takim wypadku piszą swój własny framework oparty na sinatrze, ale takie przypadki pominę (mam taką teorię, że goście od padrino mieli appkę, która zaczęła się rozrastać tak, że sinatra nie dawała rady i tak bardzo chcieli brnąć dalej, że napisali padrino)
@halgrim Istnieje już coś takiego jak API do bazy danych - jest to najczęściej binarny protokół
Nie wiem czemu kiedy uczymy się systemów rozproszonych chcemy je wszędzie stosować. Choć w sumie z każdą nową wiedzą taki jest.
Pomysł chyba wygląda tak: zrobimy API do bazy, będą możliwe tylko te operacje, które zatwierdzimy. A my pod spodem będziemy mogli wymienić storage na jaki chcemy!
Implementacja wydaje się prosta: aplikacja w Rails, Sinatrze, Javie. Do tego biblioteki, które po HTTP wykonują operacje.
Co się stanie jeśli jedna z aplikacji potrzebuje zmiany w schemacie? Trzeba dodać to do aplikacji API, dodać do bibliotek, które z tego API korzystają, zaktualizować wszystkie aplikacje.
Ktoś odkrywa, że brakuje walidacji na jednym z modeli - wartości jednak nie powinny być dowolne tylko z pewnego zakresu. Dodawana jest walidacja do implementacji API. Trzeba by ją dodać do bibliotek. Trzeba znów zaktualizować wszystkie aplikacje.
Jedna z aplikacji nie powinna mieć dostępu do wybranych danych. Trzeba wprowadzić system autoryzacji - efektywnie partycjonując dane według aplikacji. Dzięki temu zmiana w jednej aplikacji nie wymaga wymiany bibliotek w pozostałych.
Wszystko działa ale teraz mamy za duże opóźnienie przy każdym zapytaniu. Gdzie ten czas schodzi… Każde zapytanie do bazy danych to 150ms? Przecież po protokole binarnym było 5ms!
@Bragi czy możesz polecić jakąś lekturę lub podesłać jakiś przykład (jak nie tutaj to na priv) jak zbudować dobre API? Mam tutaj na myśli strukturę/schemat komunikacji pomiędzy dwoma aplikacjami. Pewnie warto zadbać także o inne rzeczy niż przekazanie wersji, o których bez popełnienia kilku błędów podczas rozwoju aplikacji teraz nie pomyślę. Będę chciał dodać nową funkcjonalność i okaże się, że źle zbudowałem API i trzeba je przebudować. Chciałbym tego uniknąć, a niestety nie mam doświadczenia w budowaniu aplikacji rozproszonych.