Jak skonfigurowałem projekt map z pomocą Computer Use

6 października poprosiłem AI o przygotowanie nowego projektu Google Cloud dla map i podpowiadania adresu w aplikacji. Potrzebowałem projektu, rozliczeń, budżetu, ograniczeń użycia i odpowiednio ograniczonego klucza API. API to interfejs, przez który aplikacja korzysta z usługi, a klucz pozwala powiązać jej wywołania z moim projektem.

To przykład pracy przez Computer Use. Agent obsługiwał widoczną konsolę Google Cloud w zalogowanej przeglądarce, a ja podejmowałem decyzje o zakresie oraz akceptacji warunków. Dzięki temu nie musiałem przedzierać się przez wiele ekranów konsoli, ale nadal wiedziałem, co dokładnie zostało zapisane.

Najpierw ustaliłem, co naprawdę ma działać

Pierwszy plan był szerszy: mapa, podpowiadanie adresu, geokodowanie po stronie serwera i dwa osobne klucze. Geokodowanie oznacza tu zamianę adresu na współrzędne. W trakcie pracy zapytałem, czy aplikacja rzeczywiście potrzebuje do tego osobnego klucza serwerowego.

Odpowiedź brzmiała: nie na tym etapie. Adres wybiera operator w przeglądarce, a komponent Places może zwrócić dane wybranego miejsca, w tym współrzędne. Obliczenie najbliższego punktu jest już zwykłym liczeniem odległości pomiędzy znanymi współrzędnymi. Nie wymaga dodatkowego wywołania Google.

Dlatego końcowy zakres był mniejszy:

To świadome odłożenie elementów, które nie mają jeszcze konkretnego zastosowania. Każda dodatkowa usługa i każdy klucz oznaczają kolejne ustawienia do utrzymania. Google zaleca ograniczanie dostępu kluczy do potrzebnych API. Google Maps Platform: zabezpieczanie kluczy i usług

Konto, projekt i rozliczenia to trzy różne rzeczy

Computer Use najpierw odczytał aktywne konto i organizację w konsoli. Dopiero potem utworzył nowy projekt, otworzył jego ustawienia rozliczeń i potwierdził powiązanie z właściwym kontem płatniczym.

To rozróżnienie ma znaczenie. Konto służy do logowania. Projekt grupuje API, uprawnienia, klucze i limity. Konto rozliczeniowe określa, skąd Google pobiera opłaty za użycie. Stworzenie projektu nie odpowiada jeszcze na pytanie, czy usługi mogą działać ani czy właściciel zobaczy koszt.

Po utworzeniu projektu ustawiliśmy miesięczny budżet 100 zł, ograniczony wyłącznie do tego projektu, oraz progi alertów 50%, 90% i 100%. Odczyt po zapisie potwierdził kwotę, progi i zawężenie zakresu. Nie sprawdzaliśmy jeszcze dostarczenia alertu po rzeczywistym przekroczeniu progu.

Tu łatwo o nieporozumienie: budżet nie jest bezpiecznikiem, który automatycznie odetnie użycie po 100 zł. To mechanizm obserwacji i powiadomień. Google opisuje alerty budżetowe jako prognozowanie lub raportowanie wydatków; sam budżet nie zatrzymuje usług ani naliczania kosztów. Google Cloud Billing: budżety i alerty

Budżet odpowiada więc na pytanie „czy zbliżamy się do kosztu?”, a limit API odpowiada na pytanie „ile żądań dana funkcja może przyjąć?”. Warto mieć oba.

Akceptacja warunków nie była ukrytym kliknięciem

Przy pierwszym włączaniu usług Google Maps Platform konsola pokazała warunki dla Europejskiego Obszaru Gospodarczego. To nie była zwykła opcja techniczna. Akceptacja tworzy zobowiązanie dla organizacji, dlatego agent zatrzymał się na ekranie, opisał jego znaczenie i czekał na moją jednoznaczną decyzję. Ten sam sposób zatrzymania przed decyzją o skutkach zewnętrznych opisuję w historii przenoszenia domeny z Computer Use.

Po akceptacji włączyliśmy tylko Maps JavaScript API i Places API (New). Konsola została następnie ponownie odczytana, aby potwierdzić, że nie włączono przy okazji niepotrzebnego Geocoding API.

Później zdecydowałem się dołożyć Places UI Kit do planowanego formularza z podpowiedzią adresu przy mapie. To osobna usługa, dlatego była drugim, wyraźnym etapem: wyszukanie jej w bibliotece, włączenie, odczyt potwierdzenia i dopisanie jej do ograniczeń klucza. Places UI Kit udostępnia komponent BasicPlaceAutocompleteElement, przeznaczony do budowania podpowiedzi miejsc. Dokumentacja Places UI Kit

„Maps” nie jest jednym przełącznikiem. Wybór API wynika z konkretnego interfejsu, który budujesz. Przy podobnym zadaniu warto sprawdzić po zapisie listę aktywnych usług i porównać ją z zatwierdzonym zakresem.

Jeden klucz przeglądarkowy, dwie warstwy ograniczeń

Powstał tylko klucz przeglądarkowy. Został zapisany lokalnie w pliku pomijanym przez Git, czyli poza plikami objętymi historią wersji projektu. Dostęp do tego pliku ograniczono do jego właściciela. W artykule nie publikuję wartości klucza.

Klucz dostał dwa rodzaje ograniczeń:

1. Ograniczenie aplikacji: działa wyłącznie z lokalnych adresów localhost i jego subdomen. To zakres środowiska deweloperskiego.
2. Ograniczenie API: może wywoływać tylko Maps JavaScript API, Places API (New) oraz — po drugim etapie — Places UI Kit.

Te dwie warstwy rozwiązują różne problemy. Ograniczenie do adresu strony utrudnia wykorzystanie klucza z obcej witryny. Ograniczenie do API sprawia, że nawet poprawnie użyty klucz nie otworzy dostępu do innych usług projektu. Google zaleca łączenie ograniczeń aplikacji i API oraz sprawdzanie później rzeczywistego użycia w Metrics Explorer. Google Maps Platform: praktyki ochrony kluczy

To ważne również dlatego, że klucz działający w przeglądarce jest możliwy do odczytania przez użytkownika aplikacji. Samo ukrycie go w lokalnym pliku podczas pracy nie zastępuje ograniczeń jego użycia. Klucz przeznaczony do wywołań z serwera wymagałby osobnego sposobu przechowywania i ograniczenia dostępu. W tym przypadku nie było jeszcze powodu go tworzyć.

Limity: trzy liczby, trzy różne zachowania

W pierwszym etapie ustawiliśmy dwa limity dzienne:

Po włączeniu Places UI Kit dodaliśmy jeszcze limit 500 dziennych żądań sesji tej usługi. Agent nie tylko wpisał liczbę, ale przeszedł przez ekran ostrzeżenia o obniżeniu limitu, zapisał zmianę, a następnie ponownie odczytał wartość w konsoli.

Te limity nie są tym samym. Użytkownik może zobaczyć jedną mapę, ale podczas wpisywania adresu wygenerować kilka żądań podpowiedzi. Z kolei limit Places UI Kit mierzy własne żądania sesji. Nie wolno więc patrzeć na jedną liczbę i zakładać, że opisuje cały ruch mapowy.

Limit 500 sesji dziennie także nie gwarantuje zerowego kosztu miesięcznego. Przez 30 dni daje możliwość wykorzystania 15 000 sesji, a inne usługi mają własne jednostki rozliczeń. Dlatego po wdrożeniu trzeba obserwować faktyczny ruch oraz alerty budżetowe. Aktualne stawki i bezpłatne poziomy należy sprawdzić dla każdej używanej usługi w cenniku Google Maps Platform.

Co było dowodem, a co pozostało do sprawdzenia

W tej historii „gotowe” nie oznaczało komunikatu agenta. Dowodami były odczyty konsoli po każdej istotnej zmianie: utworzony projekt, połączone rozliczenia, zapisany budżet, aktywne API, dozwolone API klucza i widoczna wartość limitu 500 sesji.

Z kolei nie testowaliśmy jeszcze zachowania komponentu w samej aplikacji. Konfiguracja w Google Cloud jest przygotowaniem środowiska, nie dowodem działania formularza. Następny wykonawca powinien podłączyć klucz w lokalnym środowisku, wybrać adres przez Places UI Kit i sprawdzić:

• czy mapa ładuje się z lokalnej aplikacji;
• czy podpowiedź adresu zwraca wybrane miejsce;
• czy aplikacja pobiera tylko potrzebne pola;
• czy próba użycia klucza spoza dozwolonego lokalnego adresu zostaje odrzucona;
• czy po kilku testach w konsoli pojawia się spodziewane użycie właściwych API.

Do osobnego zaprojektowania pozostaje także trwałe przechowywanie danych Places. Nie traktuję współrzędnych lub adresu pobranego od Google automatycznie jako własnej, bezterminowej bazy danych. Przed zapisaniem ich w modelu biznesowym trzeba sprawdzić aktualne warunki usługi i zdecydować, które dane są źródłem własnym, a które mają okres przechowywania oraz zasady usunięcia.

Prompt, którego użyję ponownie

Poniższy szablon porządkuje kroki z tej pracy; nie jest dosłownym cytatem z rozmowy.

Skonfiguruj przez Computer Use nowy projekt Google Cloud dla lokalnego środowiska aplikacji webowej z mapą i podpowiadaniem adresu.

Najpierw odczytaj i pokaż mi: aktywne konto, organizację, planowaną nazwę projektu oraz konto rozliczeniowe. Przedstaw plan usług, ograniczeń i kosztów. Pracuj w zatwierdzonym zakresie. Osobno pokaż do decyzji warunki umów i zmiany rozszerzające ten zakres.

Po mojej zgodzie:
1. utwórz projekt i potwierdź powiązanie z właściwym billingiem;
2. utwórz budżet tylko dla tego projektu z kwotą i progami alertów, a potem wyjaśnij, że alert nie jest automatycznym limitem wydatków;
3. włącz wyłącznie API potrzebne do opisanej funkcji;
4. utwórz tylko klucz potrzebny teraz, zapisz go w uzgodnionym miejscu poza historią Git i nie pokazuj jego wartości w czacie ani logach;
5. ogranicz klucz jednocześnie do właściwych adresów aplikacji i do konkretnych API;
6. ustaw osobne limity dla mapy, podpowiedzi i komponentów UI, jeśli konsola pokazuje je osobno;
7. po każdej zmianie odczytaj zapisany stan i podaj, co jest faktem, a co wymaga testu w aplikacji.

Na końcu przygotuj tabelę: ustawienie, wartość, dowód w konsoli, pozostałe ryzyko. Raport nie może zawierać wartości kluczy, haseł ani tokenów.

Praktyczny rezultat tej pracy to skonfigurowany projekt dla lokalnego środowiska aplikacji: potrzebne usługi, ograniczony klucz, budżet i osobne limity. Ważną decyzją było pominięcie niepotrzebnego na tym etapie klucza serwerowego. Kolejny krok ma już inny cel: sprawdzić mapę i podpowiedzi w aplikacji. Dzięki temu wiadomo, co konfiguracja potwierdza, a czego jeszcze nie sprawdziliśmy.