Historia kompilatora języka Apex

Apex – co właściwie oznacza ten skrót?

Skrót Apex można rozszyfrować jako Advanced Programming Experience. Nie ma co prawda nigdzie oficjalnego potwierdzenia, że tak właśnie należy go tłumaczyć, w dokumentacji brakuje wzmianki na ten temat. Jednak Salesforce zdążył nas już przyzwyczaić do nazewnictwa z wykorzystaniem słowa Experience, np. Lightning Experience czy też niedawno zmieniona nazwa Communities na Digital Experiences.

Na początku był interpreter

Wracając jednak do historii samego języka: jego pierwsze wdrożenie miało miejsce wraz z releasem Winter ‘07. Było jednak przeznaczone jedynie do wewnętrznego użytku Salesforce  i docelowo miało być udostępnione większym klientom dopiero po krótkiej fazie beta testów. Autor Apexa – Parker Harris (notabene jeden z założycieli Salesforce) stwierdził, że programiści „…muszą przyzwyczaić się do nowego języka programowania„, „to nie jest trudne zadanie, jeśli są oni przyzwyczajeni do składni języka bazy danych i Javy. Jeśli nie są to programiści baz danych, niektóre pojęcia mogą być dla nich jednak nowe„.

I rzeczywiście, Apex składniowo nie odbiegał wówczas od jednego z najpopularniejszych języków programowania – języka Java.

Harris założył też, że Apex nie będzie przeznaczony do budowania UI, gdyż jego głównym celem ma być zapewnienie dodatkowej warstwy abstrakcji nad transakcjami bazodanowymi, ich obsługa i umożliwienie prostej transformacji danych na obiekty. W tym samym roku Harris zaprezentował klientom technologię do tworzenia interfejsów użytkownika – VisualForce, która w połączeniu z Apexem stanowiła krok milowy w rozwoju platformy.

Strzał w dziesiątkę – czas na kompilator

Umożliwienie programistom pisania kodu i uruchamiania go na Platformie Salesforce dawało im nowe perspektywy. Od teraz możliwe stało się implementowanie skomplikowanych procesów biznesowych oraz dostarczanie rozwiązań “szytych na miarę”. W połączeniu z technologią VisualForce Salesforce z prostego CRM-a stał się środowiskiem uniwersalnym. Zmieniono więc koncepcję i popularny w początkach istnienia platformy slogan “No Software” zastąpiono nowym hasłem – “Platform as a Service”. Aby jednak utożsamić je z platformą, postanowiono nazwać ją Force.com. Ogłoszono to na konferencji Dreamforce w 2008 roku.

Wracając jednak do Apexa. Pierwsza wersja języka nie posiadała kompilatora, a cały kod był interpretowany w czasie wykonywania poleceń. Stwarzało to pewne niedogodności związane z wydajnością i możliwościami samego języka, np. niemożliwe było deserializowanie JSON-ów. Problemem było również znaczne zużycie heap ramu. Początkowo wartość heap na Platformie Salesforce wynosiła całe 3 MB.
Pomimo ogromnego sukcesu komercyjnego prace nad językiem nie zwalniały. Już w 2012 roku, po blisko 4 latach intensywnej pracy, Salesforce zaprezentował swój pierwszy kompilator języka Apex. Nie był to co prawda kompilator, jaki wyobrażamy sobie obecnie, gdyż wszystkie operacje kompilacji wykonywane były w chmurze (konkretnie – na platformie Force.com). Dzięki nowemu kompilatorowi kod Apexa kompilowany był bezpośrednio do bajtkodu, który następnie uruchamiany był na platformie Force.com. W tym samym roku zwiększono ilość heap ramu z 3 do 6 MB.

Macki ośmiornicy

Pierwszy kompilator nie był jednak idealny. W jednym z podcastów Chris Peterson – obecny Dyrektor Produktowy Apexa powiedział, że dołączył do Salesforce’a w momencie wdrożenia pierwszego kompilatora, który w owym czasie przypominał “macki ośmiornicy”. Użył tego porównania, ponieważ Apex był bardzo mocno zintegrowany ze wszystkimi systemami i serwisami Salesforce’a. Stanowiło to potencjalnie ogromny problem, z którym przyszło mu się zmierzyć.

Pytanie brzmi: dlaczego?

Na horyzoncie pojawiała się wizja napisania nowego (i znacznie lepszego) środowiska programistycznego z wykorzystaniem edytora Visual Studio Code. Miał on niezaprzeczalną zaletę – pozwalał w prosty sposób używać protokołu Language Server, stworzonego przez Microsoft. Dzięki temu nie trzeba było definiować składni języka i walidacji bezpośrednio w edytorze, można było wykorzystać do tego lokalny kompilator (uruchamiany na własnym komputerze) i poprzez serwer sprawdzać w czasie rzeczywistym składnię pisanego kodu. Jednak ówczesny kompilator nie nadawał się do tego zadania, ponieważ był zbyt mocno zintegrowany ze wszystkimi usługami Salesforce’a (co uniemożliwiało mu działanie poza platformą). Po raz kolejny zespół produktowy musiał udoskonalić kompilator.

Nowa jakość

Po kilku latach nowy kompilator był gotowy. W 2017 roku pojawiła się wtyczka do VSCode, umożliwiająca pracę z kodem za pomocą protokołu Language Server. Najprawdopodobniej prace nad tym rozwiązaniem trwały od dłuższego czasu – brakuje dokładnych informacji, ale szacuje się, że były to lata 2015-2017. Chris Peterson wspomina, że w momencie wypuszczenia pluginu do VSCode użytkownicy otrzymali również lokalny kompilator kodu Apexa. Nie był to jednak “pełnoprawny” kompilator, gdyż wynik kompilacji nie był nigdzie zapisywany oraz brakowało mu pełnej integracji z serwisami i usługami Salesforce’a.
Był to jednak kolejny krok naprzód w rozwoju kompilatora, jak i samego języka. Zespół Chrisa (o czym mało kto wie) wypuszczał i wypuszcza cotygodniowe patche do Apexa (lub gdy problem jest poważniejszy – raz na release). Sam język nie ewoluuje składniowo zbyt mocno, jednak jest ciągle udoskonalany.

Evergreen, czyli Salesforce Functions

Dochodzimy w końcu do teraźniejszości i kolejnego wyzwania, jakie stoi przed Apexem. Jakiś czas temu Salesforce zaprezentował projekt Evergreen – obecnie nazwany Salesforce Functions. Polega on w dużym uproszczeniu na wydzieleniu fragmentu kodu do funkcji i uruchomienie jej w chmurze (analogicznie jak ma to miejsce w przypadku AWS Lambda). Docelowo kod może być pisany w kilku popularnych językach programowania – w tym również w Apexie. Wyzwaniem jest jednak nadal mocne zintegrowanie Apexa z wewnętrznymi serwisami i usługami platformy. Dlatego opracowywany jest kolejny kompilator, który wyposażony ma być w standardową bibliotekę, a wszelkie integracje z usługami mają być realizowane poprzez API. Jest to niezbędne, ponieważ jedną z możliwości Salesforce Functions ma być uruchomienie funkcji lokalnie w celu przeprowadzenia testów. Dlatego właśnie wszelkie integracje z usługami i serwisami muszą być niejako poza kompilatorem.

W chwili obecnej wiadomo już, że Salesforce Functions mają być udostępnione publicznie (GA) w kolejnym releasie, więc prace nad kolejną wersją kompilatora są najpewniej na finiszu.

Podsumowanie

Apex od momentu powstania miał ściśle określone zadanie, które spełnia do dziś. Składniowo otrzymał kilka ciekawych usprawnień, jak np. lepszą kontrolę nad zwracaniem nulla (Safe Navigation Operator, pisałem o nim w artykule “Wartość null w Salesforce – Safe Navigation Operator”), usprawnienia do zapytań SOQL (klauzula FIELDS) czy też dziedziczenie sharingów klas. Jednak to, co najbardziej się rozwija, jest niewidoczne dla developerów – stabilność języka czy też szybkość przetwarzania instrukcji.