dwyl / learn-phoenix-framework

Impara come usare Phoenix Framework per divertirti a costruire applicazioni web/mobile in tempo reale
che siano veloci per gli “utenti finali”, affidabili, scalabili, mantenibili e (facilmente) estensibili!

Perché?

Come sviluppatori di app web/mobile abbiamo bisogno di sfruttare il lavoro che altre persone (molto intelligenti) hanno fatto
invece di costruire costantemente cose “da zero” per tutto il tempo; ecco perché usiamo i framework per costruire le nostre app! “Top 10 Reasons Why Phoenix” (più in basso in questa pagina!)

Ci sono molti framework tra cui scegliere (alcuni “popolari” sono menzionati sotto nella sezione “Domande”).
Ma se ci basiamo su ciò che è “popolare” continueremmo a cavalcare cavalli (e carri) ovunque e non si farebbe alcun progresso.

Nota: tutte le ragioni “Perché” per Elixir valgono anche per Phoenix!
controlla: https://github.com/dwyl/learn-elixir#why

Cosa?

Un framework per applicazioni web senza compromessi!

Gioia dello sviluppatore

Il più grande “vincolo” in qualsiasi progetto tecnologico sono le persone. Un “imprenditore”/”fondatore” o “proprietario del prodotto” può avere tutte le buone idee del mondo, se non è in grado di convertire l’idea in realtà, non ha senso.

(Dovrei preoccuparmi dei) Benchmark?

Ovviamente, dovresti eseguire i tuoi benchmark sul tuo hardware/cloud e prendere decisioni informate basate sui requisiti della tua app/prodotto, ma …. quando abbiamo letto le statistiche di quanti utenti concorrenti Phoenix App può gestire (con connessioni WebSocket dal vivo) siamo stati spazzati via! Significa che possiamo costruire le nostre app in tempo reale con il 90% di risorse in meno.

Performance Highlights

• latenza e tempo di risposta alle richieste notevolmente inferiori a qualsiasi altra cosa! (grazie ai processi leggeri di Erlang e alla gestione ultra-efficiente della rete e dei messaggi)
• 4 volte più richieste al secondo dell’equivalente app Node.js (Express.js).
• 9 volte più throughput di un’app basata su Python 2.7. (il blocco fa davvero schifo!)
• 10x – 100x più richieste gestite rispetto a Ruby-on-Rails (a seconda del tipo di app!)
• Prestazioni simili a Go su un singolo server, ma un modello di concorrenza multi-server molto più semplice, quindi lo scaling orizzontale su più data center (“availability zones”) è molto più facile! (Erlang gestisce le risorse per più server/processori come una singola app “flotta” e delega le richieste/elaborazione a loro attraverso cluster/zone!)

Tutto questo significa che spendi molto meno soldi per l’hardware/infrastruttura cloud così la tua app/compagnia può guadagnare un vantaggio competitivo sui costi.

Se sei nella fortunata posizione di considerare di usare qualcosa di meglio per il tuo prossimo progetto, non guardare oltre Phoenix!
Leggi di più: http://www.phoenixframework.org

Chi?

Molte persone/team/aziende stanno già usando Erlang/Elixir e Phoenix e vedono risultati fenomenali!
Compresi: Adobe, BBC, Spotify, Pinterest, Discord (Gamer Chat App), Groupon (Fave), Lonely Planet, Brightcove, Slack …
Vedi: https://github.com/doomspork/elixir-companies

Chi dovrebbe imparare Phoenix?

• Persone che vogliono un modo semplice di costruire un’app con tutte le convenienze moderne dei “generatori”, interfaccia di database incorporata (“ORM”) e WebSockets di prima classe per il “tempo reale” mentre ottengono un’affidabilità leggendaria.
• Squadre che hanno bisogno della produttività degli sviluppatori o di Ruby-on-Rails o Django, ma vogliono meno “magia” (cioè vogliono capire come funziona tutto!).
• Aziende che vogliono spendere il 90% in meno sia per i costi degli sviluppatori che delle infrastrutture, in modo da poter servire più persone con meno risorse.

Chi non dovrebbe imparare Phoenix?

• Chi ha bisogno di usare il framework o il linguaggio “più popolare” (per qualsiasi motivo).
• Aziende che hanno già un sacco di legacy Java/PHP/etc. e non possono investire il tempo per imparare/usare qualcosa di nuovo.
• Sviluppatori che vogliono la “sicurezza del lavoro” correggendo bug nel codice inaffidabile.

Come?

Presupposti / pre-requisiti?

Elixir

Non puoi costruire un’applicazione Phoenix senza conoscere Elixir.
Se sei nuovo di Elixir, “star” (segnalibro) this repo (così puoi tornarci domani)
e poi vai su:github.com/dwyl/learn-elixirlearn elixir fino a quando ti sembra di capire la sintassi, poi torna e impara Phoenix!

Specificamente dovresti concentrarti sull’apprendimento delle “basi” di Elixir:

• tipi di dati
• atomi
• corrispondenza di pattern
• mappe
• definizioni di funzioni
• moduli

Node.js

Phoenix usa Node.js per compilare i file JavaScript e CSS (usando Webpack).
Assicurati semplicemente di avere Node.js installato. https://nodejs.org
Non è necessario conoscere Node per usare Phoenix.

Installazione

Se hai già imparato un po’ di Elixir e installato Node.js, il primo passo per iniziare con Phoenix è l’installazione!

La documentazione di Phoenix è fantastica, quindi ti consigliamo di seguire le istruzioni ufficiali di installazione di Phoenix!

Avrete anche bisogno di installare PostgreSQL, c’è un tutorial su come fare solinked nella guida all’installazione di Phoenix collegata sopra, ma potete anche controllare il nostro learn-postgresql repo per le istruzioni, e sollevare un problema se avete qualche problema!

Mentre una conoscenza di base di JavaScript può essere utile a volte, non è necessario sapere come usare Node per usare Phoenix.

Se siete curiosi di sapere perché hanno scelto Brunch.io rispetto alle “alternative”,
la risposta breve è: Semplicità & Velocità! http://brunch.io/docs/why-brunch
Nota: Phoenix v1.4 (non rilasciato al momento della scrittura) usa WebPack per la compilazione delle risorse, vedi: CHANGELOG.md

Avanti?

Familiarizzare con la guida “Up and Running” (ufficiale):https://hexdocs.pm/phoenix/up_and_running.html#content

Esempi pratici?

Una volta che avete installato Phoenix e seguito la guida ufficiale “up and running”,
ritornate a provare questi esempi per principianti:

• Counter (contatore condiviso in tempo reale usando Phoenix LiveView):https://github.com/dwyl/phoenix-liveview-counter-tutorial
• Todo List (tutorial passo-passo che mostra come costruire un clone di TodoMVC completamente funzionale):https://github.com/dwyl/phoenix-todo-list-tutorial
• Chat (UI/UX in tempo reale usando WebSockets):https://github.com/dwyl/phoenix-chat-example
• Encryption (sicurezza):https://github.com/dwyl/phoenix-ecto-encryption-example
• Append-only Log (come salvare i dati della tua App):https://github.com/dwyl/phoenix-ecto-append-only-log-example

Book?

Raccomandiamo alle persone di comprare (o prendere in prestito) il libro di @chrismccord: “Programmare Phoenix”
vedi: https://pragprog.com/book/phoenix14/programming-phoenix-1-4

Gli autori sono individualmente impressionanti e collettivamente coprono Phoenix come nessun altro può fare! Chris ha creato Phoenix, José ha creato Elixir e Bruce è un autore tecnico ultra-esperto con molti libri di successo a suo nome!
(cioè: il libro è la scelta più ovvia per imparare Phoenix!)

Video Intro di José Valim (Creatore di Elixir)

https://youtu.be/MD3P7Qan3pw

https://youtu.be/srtMWzyqdp8

Risorse

• Elixir vs Ruby Showdown – Phoenix vs Rails: https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails
• Benchmark: https://github.com/mroth/phoenix-showdown

Le nostre 10 ragioni principali per cui Phoenix

“Phoenix fornisce la produttività di Ruby-on-Rails
con la concorrenza e la tolleranza agli errori di Erlang.”

1. Al di là di tutti i (fantastici) vantaggi tecnici, ciò che ci attrae in Phoenix è la grande comunità di persone in tutto il mondo che sono entusiaste di fare di Phoenix uno strumento incredibile per costruire applicazioni web!
   Avere persone ben disposte che ti

• aiutano quando sei bloccato, spiegando pazientemente le cose
• rispondono alle domande (sia “noob” che “avanzate”) e
• discutono apertamente le (tue) idee di miglioramento: https://elixirforum.com/t/phoenix-v1-3-0-rc-0-released/3947

1. Phoenix usa il linguaggio di programmazione Elixir che significa che la tua applicazione è compilata ed eseguita sulla macchina virtuale Erlang “BEAM”.
   Erlang è una VM collaudata e altamente tollerante usata da molte compagnie di telecomunicazioni

2. I WebSockets (“canali”) sono incorporati nel framework, il che significa che costruire applicazioni con comunicazione e interazione “in tempo reale” è molto più facile di qualsiasi altro framework/piattaforma! (nessun modulo di terze parti magicnecessario! tutto ciò di cui hai bisogno è già lì pronto per te per servire milioni di persone!)
   vedi: http://www.phoenixframework.org/docs/channels

3. Facile asincronia perché tutta la programmazione in Phoenix (Elixir) è funzionale! Questo significa che è molto semplice astrarre funzionalità utili come l’autenticazione delle richieste, la registrazione e l’elaborazione in “piplines” che sono facilmente leggibili dall’uomo! (nessun modulo di terze parti async richiesto! nessuna “promessa”, “generatori” o “osservabili” da gestire!)

4. Security & Resilience Mindset è il default.La crittografia (SSL) è facile in Phoenix/Elixir e sia la mitigazione di SQL injection, Cross-site Scripting (XSS) e la protezione CSRF sono incorporate (abilitate da default) così è virtualmente impossibile per un programmatore “principiante” introdurre questo tipo di bug di sicurezza.

5. Codice preciso non può essere sottovalutato! Possiamo scrivere molte meno righe che nell’equivalente app Node.js/Java/Rails/Go, questo significa che gli sviluppatori sono più produttivi e c’è meno codice da mantenere!

6. Testabilità grazie alla programmazione funzionale di tutti i controllori!

7. Deployment facile: http://www.phoenixframework.org/docs/heroku

8. Il deployment a tempo zero è gratuito! (sempre grazie a Erlang). Erlang gestisce la transizione degli utenti “live/attivi” dalla vecchia alla nuova versione della tua app senza che essi si accorgano che è stata aggiornata!

9. Monitoraggio/gestione incorporata della tua app attraverso supervisori Erlang significa che sai esattamente come la tua app sta funzionando, quali parti si sono bloccate/riavviate e perché! Questa è una caratteristica che paghiamo (molto) in altri framework e qui è gratis!

Puoi pensare ad un’altra ragione per cui usare Phoenix è fantastico?
Per favore condividi i tuoi pensieri in questo thread:https://github.com/dwyl/learn-phoenix-framework/issues/13

Domande?

Ho bisogno di imparare Elixir prima di provare/usare Phoenix?

Sì. Vedi: https://github.com/dwyl/learn-elixir

Ho bisogno di conoscere Erlang per usare Elixir & Phoenix…?

No. Puoi iniziare ad imparare/usare Elixir oggi e chiamare funzioni Erlang quando necessario,
ma non hai bisogno di conoscere Erlangbefore puoi usare Phoenix!

Ma Phoenix non è “Mainstream” … Dovrei/dovremmo usarlo…?

Ci sono molti framework di applicazioni web tra cui scegliere:https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
Perché qualcuno dovrebbe scegliere un framework scritto in un linguaggio di programmazione che non è “mainstream”…?

Perché non stiamo più usando Hapi.js…?

Questa è disinformazione. Stiamo ancora usando Hapi.jsper una serie di progetti in cui è appropriato.
Questo include diversi progetti client e applicazioni/strumenti interni di dwyl.

Abbiamo deciso di usare Phoenix per i nostri nuovi progetti per queste semplici ragioni:

• Elixir è un linguaggio più bello di JavaScript.#LessIsMore #LessButBetter #SmallIsBeautiful #SyntaxMatters
• JS può essere funzionale, mentre Elixir è (sempre) funzionale!
  Con la programmazione “funzionale”, i programmi sono molto più facili da pensare mentre li stai scrivendo/mantenendo!
• Elixir usa la VM Erlang che è molto più efficiente/potente di “V8”
• La VM Erlang scala molto più facilmente a multi-core multi-server multi-data-center che a Node.js
  (o praticamente qualsiasi altra cosa per quella materia!)

Per i nostri nuovi progetti abbiamo bisogno di fault-tolerance multi-data-center!
Lo otteniamo “gratis” usando Erlang -> Elixir -> Phoenix!!!

Secondo noi Hapi.js è ancora “il miglior” framework Node.js e lo continueuseremo e raccomanderemo
alle persone che hanno bisogno di app semplici che scalano e sono facili da mantenere.
vedi: https://github.com/dwyl/learn-hapi

Inoltre usiamo ancora JavaScript per tutti i nostri microservizi AWS Lambda, questo non cambierà.
Sono semplici, efficienti e scalano davvero bene!
vedi: https://github.com/dwyl/learn-aws-lambda

Cosa c’è di “sbagliato” nell’usare Rails o Django?

I framework web “produttivi” originali erano “Ruby-on-Rails” e “Django” (python) nel 2005!
(Li abbiamo usati entrambi per periodi nel nostro “viaggio” e possiamo parlare dei vantaggi di ciascuno di essi!)

Non c’è “niente di sbagliato” nell’usare Rails o Django.
Pensiamo che ci siano ancora molti casi d’uso per entrambi i framework.
Sappiamo solo che è (molto) più facile costruire “in tempo reale”
con Phoenix perché i “Canali” (WebSockets) sono integrati,
e la concorrenza di Elixir/Erlang è un gioco completamente diverso!
Erlang (e quindi Phoenix) può gestire milioni di utenti concorrenti su un singolo server,
mentre un server Rails/Django può gestirne solo qualche migliaio (nel migliore dei casi!)
se la vostra applicazione serve solo poche migliaia di persone alla volta, allora siete a posto!

Abbiamo apprezzato il fatto che Erlang utilizza processi “lighweight long-lived”,
il che significa che possiamo connettere milioni di dispositivi (IoT) …Per l’IoT Erlang è (indiscutibilmente) la risposta!
Per applicazioni web più semplici dove ci si aspetta solo pochi utenti al giorno, Rails/Django sono ancora validi.

Ma perché scendere a compromessi se non è necessario?
Se puoi avere una Tesla al “prezzo” di una Ford Focus, perché non dovresti?
Perché accontentarsi del buono quando si può facilmente avere/utilizzare il meglio?

Ma GitHub usa ancora Rails … Sicuramente GitHub è “Scalabile”?

Sì, GitHub usa ancora Rails per la sua Web App/Sito.
Ma chiedete a qualsiasi membro del core team di GitHub se (data la possibilità di ricominciare) sceglierebbe Rails
per costruire GitHub nel 2017, e vedete quanti di loro dicono “sì, certo” (con una faccia seria…)!

Inoltre, GitHub fa un sacco di cose per scalare Rails in background.
E molte delle loro caratteristiche più recenti (lato client) sono scritte in JavaScript! https://github.com/github

La linea di fondo è: qualsiasi cosa può essere fatta scalare usando “DevOps”,
ma Phoenix è fatto per scalare da defaultperché Erlang (è stato) inventato (per) scalare!

Perché NON usare Go?

“Ci sono due tipi di linguaggi di programmazione – quelli che nessuno usa e quelli di cui tutti si lamentano” ~ Bjarne Stroustrup(creatore di C++)

Go è molto popolare. In gran parte dovuto al fatto che Google lo “sponsorizza”.
Era destinato a semplificare (sostituire) C++ e Java all’interno di Google …
e per la maggior parte, ci è riuscito!

Ci piace molto Go. Era la nostra scelta “numero due” quando abbiamo deciso quale linguaggio di programmazione
(dopo Elixir) nel nostro “stack post JS”…La decisione di usare elixir invece di qualsiasi cosa else è stata facile:

• Elixir è funzionale (molto più semplice da leggere/scrivere/mantenere/estendere)
• Le funzioni di Elixir si compongono in modo molto elegante come “plugs”/”pipelines”
• I dati sono immutabili, il che rende lo stato dell’applicazione prevedibile (non si indovina!)
• I tipi sono dinamici e dedotti (non c’è bisogno di dichiararli manualmente) ma ci sono regole che semplificano le cose e il compilatore li controlla dando un avvertimento appropriato.
• Erlang rende le applicazioni distribuite molto più facili e il nostro piano è di costruire sistemi IOT che significheranno connettere molti (milioni) dispositivi con connessioni persistenti, Erlang è fatto per questo!
• Phoenix include molte cose utili out-of-the box incluse diverse caratteristiche di sicurezza a cui la maggior parte delle persone non penserà nemmeno.

Altra lettura:

• Perché Go non è buono: http://yager.io/programming/go.html
• Go Web Frameworks: https://medium.com/code-zen/why-i-don-t-use-go-web-frameworks-1087e1facfa4
• Perché tutti odiano Go: https://npf.io/2014/10/why-everyone-hates-go/(titolo click-bait, alcuni punti validi…)
• Discussione: https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_compare_to_elixir

(Cercasi aiuto per espandere questa risposta…)

Perché non usare Scala + Play Framework invece…?

Se sei già abituato a scrivere Java o a distribuire sulla JVM, Play Framework è una scelta superba: https://www.playframework.com
Scala è un buon linguaggio di programmazione e tutti dovrebbero impararlo! https://www.scala-lang.org/what-is-scala.html

Abbiamo usato Play alcune volte (prima di adottare Node.js) e ci è piaciuto molto!
Ma Scala è un linguaggio di programmazione “kitchen sink” (multi-paradigma) che permette alle persone di usare “tutto Java” …
Pensiamo che la “Java Interoperability” di Scala significhi che è “troppo facile” permettere la complessità nel tuo codebase. In particolare “OOP Mutation” …

Perché noi (DWYL) non usiamo più “Play” per i nuovi progetti? In primo luogo, siamo passati a Hapi.js (Node.js) qualche anno fa perché era più “leggero” e ci permetteva di scrivere piccoli programmi che usavano solo pochi Meg di RAM (mentre le nostre applicazioni Play erano molto avide di risorse..! Avete mai provato ad eseguire un’applicazione Scala su un portatile “base” come un Chromebook…?)

Sommario delle “ragioni” per Phoenix invece di Play:

• Sosteniamo che Play/Scala ha ancora molti casi d’uso validi.
• Elixir è molto più semplice di Scala.
• La VM Erlang è molto meglio della JVM per quanto riguarda la concorrenza.
• Abbiamo apprezzato il fatto che tutti i dati sono immutabili in Elixir.
• Abbiamo apprezzato le poche risorse necessarie per eseguire un’applicazione Phoenix (ad esempio su un Raspberry Pi!)

Pensiamo solo che per i nostri progetti il modello di concorrenza di Erlang funzioni meglio e che il codice funzionale che trasforma i dati immutabili sia più facile da testare e mantenere.

Se hai la prova che “Scala è più semplice” ci piacerebbe sentirla da te!
Diccelo: https://github.com/dwyl/learn-phoenix-web-development/issues

Perché non usare Haskell?

Se ti piace così tanto la programmazione funzionale (FP), perché non usare Haskell? https://github.com/dwyl/learn-phoenix-framework/issues