DevTalk #140 – O Salesforce CRM ze Stanisławem Zaniem

Mogę też rozwijać frontend poprzez języki JavaScript, powiedzmy, a chociaż technologii frontendowych na ten moment są trzy z jakiegoś powodu, bo Salesforce ogólnie lubi bardzo dużo zmian robić. I co chwilę coś tam dodaje albo coś usuwa. No i jest jeszcze szereg narzędzi nazywanych deklaratywnymi, które są takim drag and dropem, które pozwalają nam również programować i pewne procesy też automatyzować. Natomiast przechodząc do języka np. do tego backendowego, to jest to język Java podobny, obiektowy, nazywa się Apex. Ale jest on trochę inny i ma pewne ograniczenia. Ogólnie wszystkie te backendowe rzeczy, które w Salesforce chcemy zaprogramować, no to musimy respektować tzw.

limity platformy. I to powoduje, że kod, który napiszemy musi się skończyć wykonywać np. w 10 sekund. I nie może trwać ani sekundy dłużej, bo inaczej aplikacja nam po prostu przerwie działanie i... Z powrotem do bazy i jest nieużywana. Kolejnym nitem jest to, że pamięć nie może przekroczyć 3 MB albo nie możemy zrobić więcej niż 100 zapytań do bazy danych w czasie działania tego programu. Names mentioned. Mamy bezpośrednie połączenie do bazy danych na platformie, to nie korzystamy na ogół z żadnych ORM-ów, żadnych mapperów bazanowych, tylko jak chcemy sobie coś wyciągnąć z bazki, to sobie po prostu piszemy, lista równa się, nawias kwadratowy, zapytanie SOQL-owe w zasadzie i zwraca nam to wszystkie rekordy z bazy, które chcemy.

I Salesforce stara się rozwijać trochę te swoje narzędzia, więc raz na rok, raz na dwa lata dojdzie faktycznie coś, co pozwoli nam uprościć te poprzednie rzeczy i trochę to zoptymalizować. Więc takie podejście, że raz na Kolejny odcinek. Jak wygląda jakiś w Twojej pracy codziennej stosunek tego pisania w tym języku javopodobnym versus frontend versus przyciąganie klocków drag and drop?

Mamy tam, możemy sobie po prostu tak upraszczając chodzić po bazie danych i wyświetlać rzeczy w dynamiczny lub niedynamiczny sposób i faktycznie sobie te frontendowe rzeczy dostosowywać tym, co Salesforce nam gwarantuje i dopiero chcemy sobie to bardzo rozwinąć, dodać jakieś niesamowite kolorki, animacje, to dopiero przechodzimy do pisania tego frontendowego kodziku. Jeśli chodzi o stosunek pracy, no to raczej obecnie jest tak, że staramy się jak najwięcej wyklikiwać w narzędziach deklaratywnych i przeciągać te bloczki, które tak samo nam pozwalają odczytywać rekordy z bazy, zapisywać, iterować po nich, robić jakieś zmiany. Po prostu są takie ify i pętle. Zaniem, Stanisław.

50% tych declaratywnych, 30% backendowych i 20% frontendowych. Tak bym powiedział, że w moich ostatnich latach tak to wyglądało. Czy te designery, te budowanie tych workflows różnych, czy one są kierowane do osób także biznesowych, czy raczej właśnie do programistów, którzy tylko używają ich, żeby biznesowi dostarczyć te konkretne funkcje? To Salesforce to trochę rozgranicza u siebie w nomenklaturze wewnętrznej, ponieważ mamy taki podział kompetencji na konsultantów i na deweloperów powiedzmy. I to też w zależności od firmy wygląda trochę inaczej, natomiast modelowo według Salesforce konsultantem Jest osoba, która idzie sobie do takich osób z biznesu, robi z nimi analizę i jednocześnie jest w stanie właśnie tymi narzędziami drag and drop coś tam wyklikać i pokazać jakieś proste lub bardziej nawet skomplikowane procesy, żeby razem z nimi dewelopować, powiedzmy.

Jednym z projektów ostatnich na przykład to było, musieliśmy zaimplementować na produkcie Salesforce'a kalendarz do spotkań powiedzmy i trzeba było dokonfigurować dostępność ludzi, zasobów i to było dużo administracji jakby powiedzmy Po stronie bazy danych, żeby wszystkie te konfiguracje zasobów ludzi i miejsc dostosować do tego produktu. Dużo klikania w tych bloczkach, żeby formularz, który pozwala do wyklikania takiego spotkania też był dla klienta. Zaniem Zaniewicz.

Tak mi się wydaje, chociaż wiem, że są firmy, gdzie jest bardziej sztywne rozgraniczenie na tych deweloperów właśnie i konsultantów. No i w niektórych firmach tak faktycznie jest, że deweloper jest tylko odpisem tego apexa, on z nikim nie rozmawia, natomiast z tego co wiem, to jest to rzadkość. Raczej się wymaga od deweloperów minimum proaktywności. Pamiętam jak ja pracowałem kiedyś właśnie czy w SharePoint, czy w takim narzędziu FIM, Forefront Identity Manager, również od Microsoftu, to tam też były najróżniejsze ograniczenia i faktycznie czasami jak się jakieś pokonało, czy znalazło się obejście jakiegoś haka, no to to była mega satysfakcja. Chociaż tych narzędzi nienawidziłem, ale generalnie to... Satysfakcję o tym także pamiętam. Ale czekaj, bo Ty mówiłeś, że jest wymaganie oprócz tych różnych ograniczeń wydajnościowych czysto, czyli ile tam rekordów z bazy możesz pobrać, czy ile czasów może trwać request, czy jakaś tam operacja.

Kilkaset linii w klasie to jest raczej większa klasa już u nas. Kilku tysięczników to nie spotkamy za bardzo. A jakieś uzasadnianie decyzji? Nawet nie będę tu koncepcji ADR-ów przywoływał, ale na przykład skąd wiesz, dlaczego zostało coś zrobione w taki, a nie inny sposób przez powiedzmy programisty, który pracował tam przed tobą dwa lata temu, jeśli nie ma żadnej historii, żadnego gita, żadnego loga, ani nic. No to właśnie bardzo często nie wiem, no po prostu i muszę grzebać, tak. Jeżeli projekt jest bardziej tak ludzko kierowany, no to jest jakaś dokumentacja w Confluence, albo prowadzimy Jira, natomiast to są projekty, gdzie nawet i tego nie ma. I po prostu trzeba wszystko odczytywać z kodu i z tych komentarzy, które tam zostały, które już są oczywiście nieaktualne.

Zdjęcia i montaż. Zdjęcia i montaż. Wymaga tego, że jak tych użytkowników i rekordów jest dużo, no to muszą się przeliczać dostępy do tych rekordów i faktycznie jak mamy więcej niż 10 tysięcy, to możemy wpaść w taką pętlę, że to się nigdy nie może do końca doliczyć. No i wtedy faktycznie musimy sobie to już na poziomie bazy danych podzielić troszeczkę inaczej. Dzień dobry.

Więc tak, ale no ja w moich projektach się nie spotkałem z jakimś intensywnym przetoporzeniem na zewnątrz, to nie. Zakładam, że czasem jest to konieczne. Natomiast no Salesforce też nie jest dobrą maszynką do trzymania danych, że tak powiem, bo jest dość drogi. To nie jest nasz system, w sensie nie jest to nasz serwer, do którego sobie po prostu dołożymy kolejny dysk. Ok. Rozumiem też, że jakiegoś bezpośredniego dostępu do bazy też raczej nie ma pewnie, żeby sobie z zewnątrz do niej tam się podpiąć i porobić sobie operacji tyle, ile chcemy.

To pytanie, o co pytasz. Mamy dostęp do bazy, która jest w naszej instancji, natomiast przez to, że to środowisko jest multi-tenant i jest takie elastyczne, to jakbyśmy chcieli czytać, jak to działa pod spodem, to tak naprawdę my działamy na zwirtualizowanym, zdormalizowanym modelu, który się na bieżąco dla naszej instancji Salesforce'a buduje. Więc my operujemy w zasadzie na takich dużych widokach. I jestem w stanie jako developer, jako użytkownik sobie zrobić SQL-kę do bazy. Nie ma problemu. Mogę zrobić DML-a, dodać jakieś rekordy albo usunąć. Natomiast jak to wygląda faktycznie na serwerze Salesforce pod spodem, no to tam już dostępu nie mamy. I na przykład jak chcemy sobie zrobić jakieś lepsze indeksy, to też trzeba do Salesforce pisać, żeby nam po swojej stronie włączył indeks na konkretnym polu, żeby nam QR-ka szybciej działała, no bo po naszej stronie mamy trochę ograniczone te możliwości indeksowania.

Z jednej strony jestem do tyłu, powiedzmy, technologii, w stosunku do innych programistów technologii, no bo nie bardzo wiem, co to są te Kubernetesy, te wszystkie Kafka, Dockery i tak dalej, no bo nie potrzebujemy tego robić. Z drugiej strony... Nie jest tak, że jak przychodzi do mnie biznes i prosi, że potrzebuje, żeby ten raport mu się pokazywał inaczej, albo żeby dać dodatkowe pole na bazie danych, albo żeby mu automatycznie przeliczało jakieś tam dane w kontrakcie, no to ja to jestem w stanie zrobić od ręki w ciągu godziny, dwóch godzin dnia, czegoś takiego. Nie muszę sobie rekompilować bazy, nie muszę sobie ustawiać JVM ani nic takiego, po prostu sobie przychodzę, siedzę, klepię i jest gotowe i mogę to szybko pokazać. Więc taki Szybkość dostarczania rozwiązań jest to na pewno czymś fajnym, no tylko, że z drugiej strony się to rozbija o biznes, który bardzo często, jak widzi Salesforce'a, no to jest mu to sprzedawane na poziomie, głównie przez Salesforce'a jako niesamowita platforma, która zrobi wszystko.