Skąd to pytanie
Google Apps Script kusi. Nie musisz stawiać serwera, nie płacisz za hosting, wszystko jest w tym samym Google, w którym klient już siedzi. Piszesz JavaScript, dostajesz Sheets, Docs, Drive, Gmail, Calendar – bez integracji, bo to jeden ekosystem. Prototyp aplikacji wewnętrznej powstaje w weekend.
Pułapka pojawia się później. To co zaczęło się jako „sprytny arkusz z paroma skryptami” rośnie z firmą, a w pewnym momencie okazuje się, że to nie jest prototyp – to jest aplikacja produkcyjna, od której zależy wystawianie faktur. I nagle stają pytania, o których nikt nie myślał na początku: co jeśli klient chce się wylogować, jak wersjonujemy zmiany, jak testujemy, dlaczego pięć osób jednocześnie zamula aplikację.
Ten wpis nie jest tutorialem „jak zacząć z Apps Script”. Jest listą, którą chciałabym mieć trzy lata temu, kiedy podejmowałam decyzję „budujemy to na GAS-ie”.
Kiedy Apps Script jest świetnym wyborem
Automatyzacja wewnątrz Google Workspace, którą uruchamia jedna-dwie osoby. Chcesz mieć skrypt, który raz dziennie przechodzi po arkuszu, wysyła maile do klientów z zaległymi płatnościami i loguje wynik? Genialne dopasowanie. Napiszesz w godzinę, będzie działać latami, koszt zerowy.
Nakładka na arkusz dla właściciela małej firmy. Menu w Sheets, formularz w sidebarze, kilka przycisków „wygeneruj raport”, „eksportuj do Drive’a”, „wyślij PDF do księgowej”. Klient nie potrzebuje niczego więcej i sam sobie pogrzebie w arkuszu jak zajdzie potrzeba. Odbieranie mu tego arkusza byłoby wyświadczeniem niedźwiedziej przysługi.
Panel wewnętrzny dla zespołu do 5-10 osób, w którym operacji jest mało. Wpisujesz coś, klikasz, zapisuje się. Nikt nie robi masowych operacji, nikt nie wgrywa dużych plików, nikt nie klika trzydzieści razy na minutę. Aplikacja typu CRUD dla małego biura – Apps Script poradzi sobie z tym latami.
Integracje „jednorazowe” z zewnętrznymi API. Webhook, który raz na jakiś czas przyjmuje dane z formularza na stronie i wrzuca do arkusza. Skrypt, który raz w miesiącu ściąga dane z API i buduje raport. Klasyczne „coś, co się dzieje w tle i mało kto pamięta, że w ogóle istnieje” – idealne dla GAS.
Kiedy GAS przestaje działać
Więcej niż dziesięciu jednocześnie pracujących użytkowników. Google Sheets w roli bazy trzyma globalną kłódkę na cały arkusz przy każdym zapisie. Jedna osoba pisze – reszta stoi w kolejce. Przy trzech użytkownikach nie widać nic. Przy dwudziestu aplikacja wygląda jak zawieszona, mimo że kod jest w porządku. Optymalizacja pomaga tylko do pewnego momentu – potem trzeba wyjść z arkusza.
Duże paczki plików albo długie operacje. GAS ma sztywny limit sześciu minut na wykonanie skryptu. To brzmi jak dużo, ale przy wgrywaniu paczki pięćdziesięciu plików PDF z auto-zwymiarowaniem po drodze – kończy się mniej więcej po połowie. Aplikacja się wywala w środku, klient dostaje białą stronę, zapisała się połowa. To jest do obejścia (batchowanie, kolejki), ale każde obejście dodaje warstwę złożoności.
Aplikacja, którą trzeba testować. W GAS-ie nie ma sensownego środowiska staging. Nie ma „dev vs prod”. Testujesz albo w tym samym środowisku co klient (i psujesz mu produkcję), albo tworzysz kopię arkusza i skryptu i modlisz się, że nie zapomnisz przełączyć ID zanim wdrożysz zmiany. Wersjonowanie Git działa, ale nie w takim sposobie, w jaki działa w normalnym projekcie – clasp push to najbliższe, co masz do „deploya”, i łatwo w nim strzelić sobie w stopę.
Cokolwiek, co wymaga niskiego czasu odpowiedzi. Skrypt startuje „na zimno” – pierwsze wywołanie po dłuższej przerwie potrafi trwać kilka sekund, zanim silnik się rozgrzeje. Do panelu wewnętrznego nie problem. Do publicznego API, które ktoś woła z aplikacji mobilnej – koszmar.
Autentykacja i uprawnienia inne niż „wszystko przez konto Google”. Jeśli aplikacja ma logowanie przez email + hasło, role użytkowników, tokeny sesji – da się to zrobić w GAS-ie, ale robisz to sama. Nie ma bibliotek, nie ma standardów, nie ma społeczności, która to zrobiła przed Tobą. Kończysz z hasłami w kolumnie arkusza i modlitwą, że nikt się nie włamie.
Sygnały, że pora wychodzić
Nie ma jednego progu, po którym trzeba się przenosić. Są za to sygnały, których nie warto ignorować:
- klient regularnie mówi "aplikacja się zamula" i nie chodzi o pojedynczy dzień - zaczynasz pisać kod, którego celem jest OBEJŚCIE limitów platformy (batchowanie tylko po to, żeby zmieścić się w 6 minutach) - klient prosi o funkcje, które w normalnym stacku są jednym npm install, a w GAS-ie kosztują tydzień pracy - boisz się cokolwiek zmienić, bo nie masz jak przetestować bez rozwalania czyjejś roboty - widzisz, że firma ma jeszcze rosnąć, a aplikacja już się zatyka
Co zrobić z tego wyjściem
Nie skacz na „przepisujemy wszystko w Django/Node/cokolwiek” jako pierwszy krok. To pułapka. Największa wartość GAS-a – że klient widzi co się dzieje w arkuszu i może sam zajrzeć w dane – przy migracji ginie. Jeśli klient tego nie oczekuje wprost, jest szansa że po migracji będzie mu bardziej niekomfortowo, mimo że aplikacja szybciej działa.
Sensowniejszy pierwszy krok: przenieś tylko warstwę danych, zostawiając Apps Script jako front-end. Baza w prawdziwym Postgresie, GAS dalej rysuje ekrany. Klient dostaje szybszą aplikację, ale wciąż widzi arkusz w tle. Dopiero gdy sam poprosi „chciałbym mieć to na normalnej stronie”, ruszasz z drugim etapem.
Czego się nauczyłam
Google Apps Script nie jest złym wyborem. Jest wyborem o wąskim oknie stosowalności, którego nie widać na początku – a które łatwo przekroczyć niezauważenie, bo aplikacja rośnie stopniowo. Odpowiedzialność programisty to widzieć te granice wcześniej niż klient, i mówić o nich zanim staną się problemem. „Można to zrobić w GAS” to nie jest to samo co „warto to zrobić w GAS”, i klient nie ma jak sam tego rozróżnić.
