Clojure/Dart vs Java vs JS pod backend aplikacji mobilnych

0

Chciałbym ugryźć temat pisania backendów pod aplikacje mobilne. Od razu mówię, pomimo kilku lat doświadczenia, mam zerowe doświadczenie w kwestiach webowych, więc przepraszam za ignorancję.

Potrzebuję bazy danych, obsługi użytkowników i drobnej logiki, które będzie komunikowała się po REST API z aplikacją. Mam trzy koncepcje jak się do tego zabrać:

  1. Clojure/Dart : Wiem że to niepopularny wybór, ale oba języki mnie zwyczajnie ciekawią. Ma ktoś z was doświadczenie, z tym jak wygląda dostępność narzędzi i produktywność w tych technologiach?

  2. Java: Znam całkiem dobrze ten język i wiem, że jest szeroko używany. Bezpieczny, tylko trochę nudny wybór.

  3. JS : Słyszałem między innymi o Meteor.js który wydaje się tym, czego potrzebuję. Z drugiej strony, składnia JS to straszny burdel i ciężko się połapać przy większej ilości kodu.

Jakie jest wasze podejście do tego? Od czego powinienem zacząć? O czym powinienem wiedzieć? Potrzebuję jakiegoś punktu zaczepienia, od którego mógłbym wgryźć się w temat i później samemu zdecydować, czego potrzebuję.

1

Na pewno nie wybrał JS bo dla mnie ten język to rak. Zostaje Clojure/Dart vs Java. Na darcie się nie znam ale jednak Clojure nie jest prosty i raczej cięko mi sobie w nim wyobrazić pisanie API (czysto funkcyjny język). Clojure może być dobry ew for fun, ale w życiu nie napisałbym w nim całkowicie kodu backendowego w projekcie komercyjnym . Możesz zrobić ew. mix - przeciez Clojure i Java stoją na JVM więc powinno jako tako dać się to połączyć :D

0

Niestety, ale rozwiązanie pewnie jakie potrzebujesz najszybciej i najprościej uzyskasz w PHP.

Inne języki o jakich myślisz to próba ucieczki od celu na zasadzie: "nic chce mi się tego kodować, ale jeśli użyje clojure/dart to przynajmniej dobrze mi będzie"

EDIT: dodam jeszcze, że dopóki nie potrzebujesz websocketów to takie rozwiązania ma sens (chyba, że masz osobisty problem z php, wtedy możesz to robić z python/ruby). Jak masz problem z dynamiczymi jezykami wtedy patrz c#/java. Natomiast jeśli Twoja apka ma polegać na websocketach wtedyw zależności od potrzeb i osobitych preferencji popatrz w kierunku nodejs / elixir / go / clojure.

3

A dlaczego pisać w PHP, nawet jak nie potrzebujesz socketów to Elixir IMHO będzie zdecydowanie wygodniejszy, już nawet pomijając estetykę kodu. Polemizowałbym też z tym "najszybciej i najprościej", bo to bardzo mocno zależy od tego co OP już umie. Z tego co napisał, to zna Javę, więc wielce wątpię czy nauka PHP by napisać serwis będzie "szybsza" niż nauka jak zrobić to samo w Javie, którą już zna.

@Kamil Raju pytanie, czy jest to projekt do pracy, czy do samorozwoju? Jeśli to drugie, to weź tę technologię, która jest wg Ciebie najciekawsza (ja od siebie polecę Elixira). Jeśli jednak chcesz to zrobić do pracy i musisz zrobić to stosunkowo szybko, to weź Javę, którą twierdzisz, że znasz.

0

PHP, Python, Ruby i C# odpadają. Są to albo języki które mi totalnie nie leżą (Ruby), albo których ewentualna nauka była dla mnie zupełnie nierozwijająca (C#/Python).

@hauleth
Jestem freelancerem, więc dopóki wszystko działa, mam pole do popisu. Potrzebuję czegoś, co w pierwszej kolejności będzie produktywne, gdy już to opanuje. Dla mnie czas to pieniądz. Z drugiej, świetnie gdyby technologia była na tyle egzotyczna, żeby rozruszać trochę neurony. Nauka nowego języka mi zupełnie nie przeszkadza.

Elixir wydaje się ciekawy. Jak ze społecznością i bazą gotowych pluginów/SDK? W JS z tego co się orientuję, 90% problemów ma już gotowe rozwiązania, które tylko skleja się w gotową aplikacje jak Meteor.js. Tak samo PHP.

2

@Kamil Raju Node miał problemy jakich żaden inny język nie zna, bo JS nie ma biblioteki standardowej, więc wszystko trzeba pisać samemu (w tym nieszczęsny i legendarny left-pad). Co rozumiesz przez "pluginy/SDK"? Pluginy mogą być co najwyżej do frameworków a jeśli jako SDK rozumiesz biblioteki, to też są, zależy co chcesz zrobić, bo w ogólnym sensie, to ciężko mi jest cokolwiek powiedzieć. Przykładowo w PHP pewnie masz gazylion bibliotek do uwierzytelniania, natomiast ja w Elixirze preferuję pisać to samemu, bo to naprawdę jest 30 minut roboty (mimo tego powstało parę bibliotek do tego jak Pow czy inne, nie wiem nie używam).

Poza samymi bibliotekami Elixira masz też dostęp do wszystkich bibliotek Erlangowych, bo wywoływanie tego drugiego z Elixira jest naprawdę proste (w drugą stronę jest to troszeczkę mniej intuicyjne). Społeczność jest całkiem niemała, jeśli chodzi o Polskę, to społeczności masz na 100% w Poznaniu (moja poprzednia firma organizuje spotkania, polecam), Warszawie, Wrocławiu i Krakowie (gdzie w tym ostatnim mieszka Jose, twórca Elixira).

Z ciekawych rozwiązań jakie są dostępne:

  • Phoenix framework RESTowy oraz WebSockets, który jest zbudowany na Plug minimalnej bibliotece do obsługi zapytań HTTP
  • Absinthe - do pisania serwerów GraphQLowych, całkiem spoko integruje się z Phoeniksem
  • Ecto - biblioteka do obsługi DB i walidacji danych (bardziej wzorzec repozytorium niż ORM)
  • Membrane - sam do końca nie wiem co to, bo jeszcze się nie bawiłem, ale wygląda na framework do obsługi streamingu dźwięku
  • Scenic - budowanie interfesów (UI) dla IoT, ma parę bardzo ciekawych rozwiązań
  • Nerves - framework I biblioteki do pracy z urządzeniami IoT, które można programować przy pomocy języków BEAM (IIRC nie jest to ograniczone do Elixira), przykładowo można łatwo tworzyć projekty działające na RPi (możesz fajnie połączyć ze Scenic wymienionym wyżej)
0

@hauleth:
Elixir wydaje się dosyć ciekawy, chociaż pierwszy raz o nim słyszę. Jeszcze jedno, praktyczne, pytanie. Konsultujesz średniej wielkości projekt, powiedzmy sieć miejskich parkomatów (one działają online?). Uważasz, że Elixir jest wystarczająco 'production ready' żeby go wykorzystać, czy postawiłbyś na bezpieczniejszą Jave/JS? Czy Elixir nadaje się do komercyjnych projektów, czy to bardziej niszowa ciekawostka, jak Haskell ?

2

@Kamil Raju a o Discordzie słyszał? U nich wszystko jest w Elixirze. Pinterest na 100% używa. Dodatkowo Elixir jest zbudowany na Erlangu, który ma ponad 30 lat produkcyjnego użycia z dostępnością na poziomie 9 dziewiątek (czyt. mniej niż 1 sekunda downtime w ciagu 30 lat). Z innych firm które używają (lub używały) Erlanga:

  • GitHub - serwer gita był (jest?) w Erlangu
  • WhatsApp - cała komunikacja idzie przez serwery Erlangowe
  • Facebook - Messenger kiedyś był obsługiwany przez ejabberd - Erlangową implementację Jabbera, nie wiem jak jest teraz
  • Heroku - z tego co wiem dalej używają Erlanga jako routera
  • jakiekolwiek firmy używające CouchDB czy RabbitMQ
  • Klarna
  • Bet365
  • Basho - autorzy Riak, ale już upadli i część projektów przejęło Bet365
  • Goldman&Sachs - z tego co pamiętam to ich cały system HFT jest w Erlangu
1
Kamil Raju napisał(a):

@hauleth:
Konsultujesz średniej wielkości projekt, powiedzmy sieć miejskich parkomatów (one działają online?). Uważasz, że Elixir jest wystarczająco 'production ready' żeby go wykorzystać

Jak najbardziej. Masz Nerves, więc nawet na samych parkomatach jesteś w stanie odpalić Elixira. Jak do tego dorzucisz Scenic to masz i UI. Więc za jednym zamachem masz:

  • firmware
  • UI (możesz nawet "na żywo" śledzić jak użytkownik używa aplikacji)
  • deployment

Po stronie serwera odpalasz sobie Elixira do którego łączą się wszystkie nody i tam masz totalną kontrolę. Nawet zamiast łączyć się przez jakieś HTTP czy inne łączysz się poprzez Distributed Erlang i możesz sobie ogarnąć wszystko tak jakby to praktycznie było w obrębie jednej maszyny wirtualnej, po prostu każdy parkomat to jeden process w systemie, który wysyła wiadomości do "głównego" serwera i czeka na odpowiedź czy udało się zapłacić czy nie. Akurat parkometry byłyby ciekawym rozwiązaniem i widzę coś takiego oczami wyobraźni całkiem ładnie.

1

Jeśli znasz Javę to zainteresuj się połączeniem Kotlin + Ktor

Jesli mialbym coś zacząć od zera teraz to skorzystałbym wlasnie z tego szczególnie, że na Androida teraz też pisze się w Kotlinie (jest świetny)

0

@dbCooper: robiłeś jakiś większy projekt w ktorze? Ten zestaw kotlin + ktor powinien być chyba zdecydowanie lżejszy od sparingach i javy

1 użytkowników online, w tym zalogowanych: 0, gości: 1