Duże aplikacje w GWT: jeden moduł lub kilka?

Question

Aby zapewnić ładne adresy URL między częściami naszej aplikacji, podzieliliśmy wszystko na kilka modułów, które są niezależnie kompilowane. Na przykład istnieje część "menedżera" i część "edytora". Edytor uruchamia się w nowym oknie. W ten sposób możemy połączyć się bezpośrednio z edytorem:

/com.example.EditorApp?id=1 

Moduł EditorApp pobiera wartość id i ładuje dokument.

Problem z tym, że WSZYSTKO kodu, który jest wspólny pomiędzy tymi dwoma modułami, jest duplikowany na wyjściu. Obejmuje to wszelką zawartość statyczną (grafika), arkusze stylów itp.

Kolejnym problemem jest czas kompilacji generowania JavaScriptu prawie dwukrotnie, ponieważ mamy pewien skomplikowany kod wspólny dla obu modułów, który musi zostać przetworzony dwa razy.

Czy ktoś sobie z tym poradził? Rozważam złomowanie poszczególnych modułów i scalenie ich z powrotem do jednego celu kompilacji. Jedyną wadą jest to, że adresy URL między naszymi „apps” stać się coś takiego:

/com.example.MainApp?mode=editor&id=1 

Każde okno ładuje moduł główny, sprawdza wartość parametru mode, a i wywołuje odpowiedni kod moduł startowy.

Answer 1

Zbudowałem kilka bardzo dużych aplikacji w GWT, i uważam, że najlepiej jest podzielić rzeczy na moduły i przenieść wspólny kod do własnego obszaru, tak jak zrobiłeś. Powód w naszym przypadku był prosty, niektóre części naszej aplikacji bardzo różniły się od reszty, więc z punktu widzenia rozmiaru kompilacji. Nasza aplikacja została skompilowana do 300kb dla głównej sekcji i około 25-40kb dla innych sekcji. Gdybyśmy po prostu umieścili je wszystkie w jednym, użytkownik musiałby pobrać 600 KB, co było dla nas nie do przyjęcia.

Ma również więcej sensu z punktu widzenia projektowania i ponownego wykorzystania, aby jak najlepiej rozdzielić elementy, ponieważ od tego czasu używaliśmy wielu modułów, które zbudowaliśmy na tym projekcie.

Czas kompilacji nie jest czymś, na co należy się ogólnie martwić, ponieważ w rzeczywistości można go przyspieszyć, jeśli posiada się osobne moduły. Używamy mrówki do budowania naszego projektu, a my ustawiamy go tylko na kompilację GWT, który się zmienił, a podczas projektowania, który ma być zbudowany tylko dla jednej przeglądarki, typowe czasy kompilacji w naszym projekcie to 20 sekund, a my mamy dużo kodu. Możesz zobaczyć i przykład tego here.

Jeszcze jedna drobna rzecz: zakładam, że wiesz, że nie musisz używać domyślnych ścieżek GWT, które generuje? Więc zamiast com.MyPackage.Package możesz po prostu umieścić go w folderze o fajnej nazwie, np. "Ui" lub coś podobnego. Po skompilowaniu GWT nie obchodzi, gdzie go umieścisz, i nie jest wrażliwy na zmiany ścieżki, ponieważ wszystko działa z tego samego katalogu.

Answer 2

Ok. Naprawdę mam wrażenie, że tak naprawdę nie ma "właściwej" odpowiedzi, ponieważ projekty różnią się tak bardzo. To bardzo zależy od charakteru aplikacji.

Nasz główny build składa się z wielu modułów wewnętrznych i modułów zewnętrznych. Wszystkie są zarządzane w oddzielnych projektach. Ma to sens, ponieważ są one używane w różnych miejscach.

Ale posiadanie więcej niż jednego modułu w jednym projekcie zaprojektowanym do pracy jako jedna kompletna aplikacja wydaje się mieć skomplikowane rzeczy. Pierwotny powód tych dwóch modułów polegał na tym, aby adres URL był prosty podczas otwierania różnych ekranów w nowym oknie.Mimo wielu celów kompilacji używają bardzo dużego wspólnego zestawu kodu (w tym niestandardowej biblioteki rozrządowej XML/POJO).

O rozmiarze ... dla nas jeden moduł miał 280 KB, a drugi nieco ponad 300 KB.

Właśnie skończyłem scalanie wszystkiego z powrotem w jeden moduł. Nowy połączony moduł wynosi około 380 KB. Tak więc jest to trochę mniej do pobrania, ponieważ większość użytkowników używa obu ekranów.

Pamiętaj również, że istnieje doskonałe buforowanie, aby 380 KB mogło zostać pobrane tylko raz, chyba że aplikacja zostanie zmieniona.

Answer 3

Z mojego doświadczenia w budowaniu aplikacji GWT wynika, że ​​należy wziąć pod uwagę kilka czynników, wybierając wiele modułów (z punktami wejścia lub bez) lub wszystko w jednym: czas pobierania (rozmiar pakietu Javascript), czas kompilacji, nawigacja/url i łatwość konserwacji/ponownego użycia.

... za czas pobierania, podział kodu praktycznie eliminuje potrzebę włamywania się do różnych modułów ze względu na wydajność.

... na czas kompilacji, nawet duże aplikacje są dość szybkie do skompilowania, ale może to pomóc w rozbiciu dużych aplikacji.

... na nawigację/adres URL może być trudny do nawigacji z jednego modułu do drugiego (przy założeniu różnych punktów Entry), ponieważ każdy moduł ma swój własny stan po stronie klienta ... i nawigacja nie jest płynna moduły.

... na łatwość konserwacji/ponownego użycia, może być pomocne z perspektywy organizacji/struktury, aby podzielić je na oddzielne moduły (nawet jeśli istnieje tylko jeden punkt EntryPoint).

Napisałem wpis na blogu na temat using GWT Modules, na wypadek, gdyby to pomogło.