Aprenda a utilizar Phoenix Framework para divertirse creando aplicaciones web/móviles en tiempo real
que sean rápidos para los " usuarios finales ", confiables , escalables , mantenibles y ( fácilmente ) extensibles .
Como desarrolladores de aplicaciones web/móviles, debemos aprovechar el trabajo que han realizado otras personas ( realmente inteligentes ).
en lugar de construir cosas constantemente " desde cero " todo el tiempo; ¡Es por eso que usamos frameworks para construir nuestras aplicaciones!
Ver: " Las 10 razones principales por las que Phoenix " ( ¡más abajo en esta página! )
Hay muchos marcos para elegir ( algunos "populares" se mencionan a continuación en la sección " Preguntas " ).
Pero si nos guiamos por lo " popular " todavía estaríamos montando caballos ( y carros ) por todas partes y no se lograría ningún progreso .
Nota : ¡todas las razones " por qué " de Elixir también se aplican a Phoenix !
Échales un vistazo: https://github.com/dwyl/learn-elixir#why
¡Un marco de aplicación web sin concesiones !
La mayor " limitación " en cualquier proyecto tecnológico es la gente . Un "emprendedor"/"fundador" o "propietario de producto" puede tener todas las buenas ideas del mundo, si no puede convertir la idea en realidad , no tiene sentido .
Obviamente , debe ejecutar sus propios puntos de referencia en su propio hardware/nube y tomar decisiones informadas basadas en los requisitos de su aplicación/producto, pero... cuando leemos las estadísticas de cuántos usuarios simultáneos puede manejar una aplicación Phoenix ( con vivo Conexiones WebSocket ) ¡nos quedamos impresionados ! Significa que podemos crear nuestras aplicaciones en tiempo real con un 90 % menos de recursos.
Todo esto significa que usted gasta considerablemente menos dinero en hardware/infraestructura de nube para que su aplicación/empresa pueda obtener una ventaja competitiva en cuanto a costos .
Si tiene la suerte de considerar usar algo mucho mejor para su próximo proyecto, ¡no busque más que Phoenix!
Leer más: http://www.phoenixframework.org
¡Muchas personas/equipos/empresas ya están usando Erlang/Elixir y Phoenix y están obteniendo resultados fenomenales!
Incluyendo: Adobe, BBC, Spotify, Pinterest, Discord (aplicación Gamer Chat), Groupon (Fave), Lonely Planet, Brightcove, Slack...
Ver: https://github.com/doomspork/elixir-companies
No puedes crear una aplicación Phoenix sin conocer Elixir.
Si eres nuevo en Elixir, destaca this repositorio ( para que puedas volver a él mañana )
y luego vaya a: github.com/dwyl/learn-elixir, aprenda elixir hasta que sienta que comprende la sintaxis, luego regrese y aprenda Phoenix.
Específicamente deberías concentrarte en aprender los "Conceptos básicos" del Elixir:
Phoenix usa Node.js para compilar activos como archivos JavaScript y CSS ( usando Webpack).
Simplemente asegúrese de tener Node.js instalado . https://nodejs.org
No necesitas conocer Node para usar Phoenix.
Si ya aprendió algo de Elixir e instaló Node.js, entonces el primer paso para comenzar con Phoenix es la instalación.
La documentación de Phoenix es asombrosa, por lo que recomendamos seguir las instrucciones de instalación oficiales de Phoenix.
También necesitarás instalar PostgreSQL, hay un tutorial sobre cómo hacerlo vinculado en la guía de instalación de Phoenix vinculada arriba, pero también puedes consultar nuestro repositorio learn-postgresql para obtener instrucciones y plantear un problema si tienes algún problema. !
Si bien un conocimiento básico de JavaScript puede resultar útil en ocasiones, no es necesario saber cómo utilizar Node para utilizar Phoenix.
Si tiene curiosidad por saber por qué eligieron Brunch.io en lugar de " alternativas ",
la respuesta corta es: ¡Simplicidad y Velocidad! ver: http://brunch.io/docs/why-brunch
Nota : Phoenix v1.4 ( inédito en el momento de escribir este artículo ) utiliza WebPack para la compilación de recursos, consulte: CHANGELOG.md
Familiarícese con la guía "En funcionamiento" ( oficial ): https://hexdocs.pm/phoenix/up_and_running.html#content 
Una vez que haya instalado phoenix y haya seguido la guía oficial de "instalación y funcionamiento",
Vuelve y prueba estos ejemplos para principiantes :
Recomendamos que la gente compre ( o tome prestado ) el libro de @chrismccord: "Programming Phoenix"
ver: https://pragprog.com/book/phoenix14/programming-phoenix-1-4 
¡Los autores son individualmente impresionantes y colectivamente cubren Phoenix de manera integral como nadie más puede hacerlo ! Chris creó Phoenix, José creó Elixir y Bruce es un autor técnico muy experimentado con muchos libros exitosos a su nombre.
( es decir: ¡el libro es la opción obvia sobre cómo aprender Phoenix! )
https://youtu.be/MD3P7Qan3pw
https://youtu.be/srtMWzyqdp8
" Phoenix proporciona la productividad de Ruby-on-Rails
con la concurrencia y tolerancia a fallos de Erlang ".
Phoenix utiliza el lenguaje de programación Elixir , lo que significa que su aplicación se compila y ejecuta en la máquina virtual Erlang "BEAM".
Erlang es una máquina virtual altamente tolerante a fallas probada en batalla utilizada por muchas empresas de telecomunicaciones
WebSockets (" canales ") están integrados en el marco, lo que significa que crear aplicaciones con comunicación e interacción en "tiempo real" es mucho más fácil que prácticamente cualquier otro marco/plataforma. ( ¡No se necesita ningún módulo magic de terceros! ¡Todo lo que necesita ya está listo para servir a millones de personas! )
ver: http://www.phoenixframework.org/docs/channels
¡Fácil asincronía porque toda la programación en Phoenix ( Elixir ) es funcional ! Esto significa que es realmente sencillo abstraer funciones útiles como la autenticación de solicitudes, el registro y el procesamiento en " piplines " que son fácilmente legibles por humanos . ( ¡No se requiere ningún módulo async de terceros! ¡¡No hay "promesas", "generadores" ni "observables" para administrar! )
La mentalidad de seguridad y resiliencia es la default . El cifrado (SSL) es fácil en Phoenix/Elixir y tanto la mitigación de la inyección SQL como la protección Cross-site Scripting ( XSS ) y CSRF están integradas ( habilitadas de forma default ), por lo que es prácticamente imposible que un programador " novato " introduzca este tipo. de error de seguridad.
¡ El código conciso no puede subestimarse ! Podemos escribir muchas menos líneas que en la aplicación equivalente Node.js/Java/Rails/Go, esto significa que los desarrolladores son más productivos y hay menos código que mantener .
¡Comprobabilidad gracias a la programación funcional de todos los controladores!
Fácil implementación : https://hexdocs.pm/phoenix/heroku.html
¡La implementación sin tiempo de inactividad es gratuita ! ( de nuevo por Erlang ). ¡Erlang gestiona la transición de los usuarios " en vivo/activos " de la versión antigua a la nueva de su aplicación sin que se den cuenta de que se actualizó/actualizó!
La supervisión/administración integrada de su aplicación a través de supervisores de Erlang significa que sabe exactamente cómo se está desempeñando su aplicación, qué partes fallaron/reiniciaron y por qué. ¡Esta es una característica por la que pagamos ( mucho ) en otros marcos y aquí es gratis !
¿Se te ocurre otra razón por la que usar Phoenix es fantástico ?
Por favor comparte tus pensamientos en este hilo: #13
before probar/usar Phoenix?Sí . Ver: https://github.com/dwyl/learn-elixir
No . Puede comenzar a aprender/usar Elixir hoy y llamar a las funciones de Erlang cuando sea necesario.
¡Pero no necesitas conocer Erlang before poder usar Phoenix!
Hay muchos marcos de aplicaciones web entre los que podemos elegir: https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
Entonces, ¿ por qué alguien seleccionaría un marco escrito en un lenguaje de programación que no es " convencional "...?
Esto es desinformación . Todavía utilizamos Hapi.js para varios proyectos donde es apropiado .
Esto incluye varios proyectos de clientes y aplicaciones/herramientas internas de dwyl.
Decidimos utilizar Phoenix para nuestros nuevos proyectos por estas sencillas razones:
#LessIsMore #LessButBetter #SmallIsBeautiful #SyntaxMatters¡Para nuestros nuevos proyectos necesitamos tolerancia a fallos en múltiples centros de datos !
¡¡Conseguimos eso " gratis " usando Erlang -> Elixir -> Phoenix !!
En nuestra opinión, Hapi.js sigue siendo " el mejor " marco de Node.js y continue usándolo y recomendándolo .
para personas que necesitan aplicaciones simples , escalables y fáciles de mantener.
ver: https://github.com/dwyl/learn-hapi
Además, seguimos usando JavaScript para todos nuestros microservicios AWS Lambda, eso no va a cambiar.
¡Son simples, eficientes y escalan muy bien!
ver: https://github.com/dwyl/learn-aws-lambda
¡Los marcos web " productivos " originales fueron "Ruby-on-Rails" y "Django" ( python ) en 2005!
(¡ Usamos ambos durante períodos de nuestro " viaje " y podemos hablar sobre las ventajas de cada uno de ellos!)
No hay " nada de malo " en usar Rails o Django.
Creemos que todavía hay muchos casos de uso para ambos marcos.
Simplemente sabemos que es ( mucho ) más fácil construir "en tiempo real".
con Phoenix porque los "canales" ( WebSockets ) están integrados,
¡Y la concurrencia Elixir/Erlang es un juego de pelota completamente diferente!
Erlang (y por tanto Phoenix) puede manejar millones de usuarios simultáneos en un único servidor,
mientras que un servidor Rails/Django sólo puede manejar unos pocos miles ( ¡en el mejor de los casos !)
Si tu aplicación solo atiende a unos pocos miles de personas a la vez, ¡entonces estás bien!
Nos encanta el hecho de que Erlang utilice procesos " ligeros y de larga duración ",
lo que significa que podemos conectar millones de dispositivos ( IoT )... ¡Para IoT, Erlang es ( sin duda ) la respuesta!
Para aplicaciones web más simples donde sólo se esperan unos pocos usuarios por día, Rails/Django siguen siendo viables.
Pero ¿ por qué ceder si no es necesario ?
Si puedes tener un Tesla por el "precio" de un Ford Focus, ¿¡¿por qué no ?!?
¿Por qué conformarse con lo bueno cuando puedes tener o usar lo mejor fácilmente ?
Sí , GitHub todavía usa Rails para su sitio/aplicación web.
Pero pregúntele a cualquiera del equipo central de GitHub si ( si tuvieran la oportunidad de empezar de nuevo ) elegirían Rails.
para construir GitHub en 2017, y ver cuántos de ellos dicen " sí, por supuesto " ( con cara seria... )!
Además, GitHub hace muchas cosas con Scale Rails en segundo plano.
¡Y muchas de sus funciones más nuevas ( del lado del cliente ) están escritas en JavaScript! ver: https://github.com/github
La conclusión es: cualquier cosa se puede escalar usando "DevOps",
¡pero Phoenix está hecho a escala dedefaultporque Erlang (fue) inventado (a) escala!
" Hay dos tipos de lenguajes de programación: aquellos que nadie usa y aquellos de los que todo el mundo se queja " ~ Bjarne Stroustrup ( creador de
C++)
Ir es muy popular. En gran parte debido al hecho de que Google lo " patrocina ".
Estaba destinado a simplificar ( reemplazar ) C++ y Java dentro de Google...
¡Y en su mayor parte lo ha logrado!
Nos gusta mucho Go. Fue nuestra elección "número dos" al decidir qué lenguaje de programación
( después de Elixir ) en nuestra "pila posterior a JS"... La decisión de usar elixir en lugar de cualquier else fue fácil :
Lectura adicional:
Play Framework en su lugar ...? Si ya está acostumbrado a escribir Java o implementar en JVM, Play Framework es una excelente opción: https://www.playframework.com
¡Scala es un buen lenguaje de programación y todo el mundo debería aprenderlo! https://www.scala-lang.org/what-is-scala.html
¡Hemos usado Play varias veces ( antes de adoptar Node.js ) y realmente nos gustó!
Pero Scala es un lenguaje de programación "fregadero" ( multiparadigma ) que permite a las personas utilizar " todo Java "...
Creemos que la "interoperabilidad Java" de Scala significa que es "demasiado fácil" permitir complejidad en su código base. Específicamente "mutación POO"...
Entonces, ¿por qué nosotros (DWYL) ya no usamos "Play" para nuevos proyectos? En primer lugar, hicimos la transición a Hapi.js ( Node.js ) hace unos años porque era más " ligero " y nos permitía escribir programas pequeños que usaban solo unos pocos megas de RAM ( donde nuestras aplicaciones Play consumían muchos recursos). .! ¿Alguna vez has intentado ejecutar una aplicación Scala en una computadora portátil "básica" como una Chromebook...?
Resumen de "razones" para Phoenix en lugar de Play:
Simplemente pensamos que para nuestros proyectos, el modelo de concurrencia de Erlang funciona mejor y el código funcional que transforma datos inmutables es más fácil de probar y mantener .
Si tiene evidencia de que " Scala es más simple ", ¡nos encantaría saber de usted!
Cuéntanos: https://github.com/dwyl/learn-phoenix-web-development/issues
Si tanto te gusta la Programación Funcional ( FP ), ¿por qué no utilizar Haskell?
