실시간 웹/모바일 앱을 재미있게 구축하기 위해 Phoenix Framework를 사용하는 방법을 알아보세요.
" 최종 사용자 "에게 빠르고 안정적 이고 확장 가능하며 유지 관리가 가능 하고 ( 쉽게 ) 확장 가능합니다 !
웹/모바일 앱 개발자로서 우리는 다른( 정말 똑똑한 ) 사람들이 수행한 작업을 활용 해야 합니다 .
항상 " 처음부터 " 끊임없이 구축하는 대신; 이것이 바로 우리가 앱을 구축하기 위해 프레임워크를 사용하는 이유 입니다!
참조: " Phoenix를 선택하는 10가지 이유 "( 이 페이지 아래에 더 자세히 나와 있습니다! )
선택할 수 있는 프레임워크는 많습니다 ( 몇 가지 "인기 있는" 프레임워크는 아래 " 질문 " 섹션에 언급되어 있습니다 ).
그러나 우리가 " 인기 있는 " 방법을 따른다면 우리는 여전히 어디에서나 말( 과 수레 )을 타고 있을 것이며 아무런 진전 도 없을 것입니다.
참고 : Elixir를 선택하는 " 왜 "라는 모든 이유는 Phoenix 에도 적용됩니다 !
확인해 보세요: https://github.com/dwyl/learn-elixir#why
타협 없는 웹 애플리케이션 프레임워크!
모든 기술 프로젝트에서 가장 큰 " 제약 "은 사람 입니다. "기업가"/"창업자" 또는 "제품 소유자"는 세상의 모든 좋은 아이디어를 가질 수 있지만, 아이디어를 현실 로 전환 할 수 없다면 그것은 의미가 없습니다 .
분명히 , 자체 하드웨어/클라우드에서 자체 벤치마크를 실행하고 앱/제품의 요구 사항 에 따라 정보에 근거한 결정을 내려야 하지만... Phoenix 앱이 처리할 수 있는 동시 사용자 수에 대한 통계를 읽을 때( 라이브 WebSocket 연결 ) 우리는 정말 놀랐 습니다! 이는 90% 더 적은 리소스로 실시간 앱을 구축할 수 있다는 의미입니다.
이 모든 것은 하드웨어/클라우드 인프라에 훨씬 적은 비용을 지출하므로 앱/회사가 비용 측면에서 경쟁 우위를 얻을 수 있음을 의미합니다.
다음 프로젝트에 훨씬 더 나은 것을 사용하는 것을 고려할 수 있는 행운의 위치에 있다면 Phoenix보다 더 나은 곳은 없습니다!
더 읽어보세요: http://www.phoenixframework.org
많은 사람/팀/회사가 이미 Erlang/Elixir 및 Phoenix를 사용하고 있으며 놀라운 결과를 보고 있습니다!
포함: Adobe, BBC, Spotify, Pinterest, Discord(게이머 채팅 앱), Groupon(Fave), Lonely Planet, Brightcove, Slack...
참조: https://github.com/doomspork/elixir-companies
Elixir를 모르면 Phoenix 앱을 만들 수 없습니다 .
Elixir를 처음 사용하신다면 this 저장소에 "별표"( 북마크 )를 표시해 주세요( 내일 다시 방문하실 수 있도록 ).
그런 다음 github.com/dwyl/learn-elixir 로 이동하세요. 구문을 이해했다고 느낄 때까지 elixir를 배운 다음 다시 돌아와서 Phoenix를 배우세요!
특히 엘릭서의 "기본"을 배우는 데 집중해야 합니다:
Phoenix는 Node.js를 사용하여 JavaScript 및 CSS 파일과 같은 자산을 컴파일합니다(Webpack 사용 ).
Node.js가 설치되어 있는지 확인하세요. https://nodejs.org
Phoenix를 사용하기 위해 Node를 알 필요는 없습니다.
이미 Elixir를 배우고 Node.js를 설치했다면 Phoenix를 시작하기 위한 첫 번째 단계는 설치입니다!
Phoenix 문서는 훌륭하므로 공식 Phoenix 설치 지침을 따르는 것이 좋습니다!
또한 PostgreSQL을 설치해야 합니다. 위에 링크된 Phoenix 설치 가이드에 링크된 설치 방법에 대한 튜토리얼이 있지만, learn-postgresql 저장소에서 지침을 확인하고 문제가 있는 경우 문제를 제기할 수도 있습니다. !
때때로 JavaScript에 대한 기본적인 이해가 유용 할 수 있지만 Phoenix를 사용하기 위해 Node를 사용하는 방법을 알 필요는 없습니다.
그들이 " 대안 "이 아닌 Brunch.io를 선택한 이유가 궁금하시다면,
짧은 대답은 다음과 같습니다: 단순성과 속도! 참조: http://brunch.io/docs/why-brunch
참고 : Phoenix v1.4( 작성 당시 출시되지 않음 )는 자산 컴파일을 위해 WebPack을 사용합니다. CHANGELOG.md를 참조하세요.
"Up and Running"( 공식 ) 가이드를 숙지하세요 : https://hexdocs.pm/phoenix/up_and_running.html#content 
Phoenix를 설치하고 공식 "작동 및 실행" 가이드를 따른 후,
돌아와서 초보자에게 친숙한 다음 예제를 시도해 보세요.
우리는 사람들이 @chrismccord의 책 "Programming Phoenix"를 구입 하거나 빌릴 것을 권장합니다 .
참조: https://pragprog.com/book/phoenix14/programming-phoenix-1-4 
저자들은 개인적으로 인상적 이며 전체적으로 다른 누구도 할 수 없는 피닉스를 포괄적으로 다루고 있습니다! Chris는 Phoenix를 만들었고 José는 Elixir를 만들었으며 Bruce는 그의 이름에 걸맞은 많은 성공적인 책을 낸 경험이 풍부한 기술 작가입니다!
( 즉, 이 책은 Phoenix를 배우는 방법에 대한 확실한 선택입니다! )
https://youtu.be/MD3P7Qan3pw
https://youtu.be/srtMWzyqdp8
" Phoenix는 Ruby-on-Rails의 생산성을 제공합니다.
Erlang 의 동시성 및 내결함성을 사용합니다 ."
Phoenix는 Elixir 프로그래밍 언어를 사용합니다. 이는 앱이 Erlang 가상 머신 "BEAM"에서 컴파일되고 실행된다는 의미입니다.
Erlang은 많은 통신 회사에서 사용하는 검증된 내결함성 VM입니다.
WebSocket (" 채널 ")은 프레임워크에 내장되어 있습니다. 즉, "실시간" 통신 및 상호 작용을 통해 앱을 구축하는 것이 사실상 다른 프레임워크/플랫폼보다 훨씬 쉽습니다! ( 타사의 magic 모듈이 필요하지 않습니다! 수백만 명의 사람들에게 서비스를 제공할 수 있도록 필요한 모든 것이 이미 준비되어 있습니다!! )
참조: http://www.phoenixframework.org/docs/channels
Phoenix( Elixir )의 모든 프로그래밍은 Functional 이기 때문에 비동기화가 쉽습니다 ! 이는 요청 인증, 로깅 및 처리와 같은 유용한 기능을 사람이 쉽게 읽을 수 있는 " 파이프라인 "으로 추상화하는 것이 정말 간단하다는 것을 의미합니다! ( 타사 async 모듈이 필요하지 않습니다! 관리할 "약속", "생성기" 또는 "관찰 가능 항목"이 없습니다!! )
보안 및 탄력성 사고방식 이 default 입니다. Phoenix/Elixir에서는 암호화 (SSL)가 쉽고 SQL 주입 완화 , XSS ( Cross-site Scripting ) 및 CSRF 보호가 모두 내장되어 있으므로( default 으로 활성화됨 ) " 초보 " 프로그래머가 이 유형을 도입하는 것은 사실상 불가능합니다. 보안 버그.
간결한 코드는 과소평가 될 수 없습니다! 동등한 Node.js/Java/Rails/Go 앱보다 훨씬 적은 줄을 작성할 수 있습니다. 이는 개발자의 생산성이 향상되고 유지 관리할 코드가 적다 는 것을 의미합니다!
모든 컨트롤러의 기능적 프로그래밍으로 인한 테스트 가능성 !
쉬운 배포 : https://hexdocs.pm/phoenix/heroku.html
다운타임 없는 배포는 무료 입니다! ( 다시 Erlang 때문에 ). Erlang은 " 라이브/활성 " 사용자가 앱이 업그레이드/업데이트되었다는 사실조차 인지하지 못한 채 이전 버전에서 새 버전으로 전환하는 것을 관리합니다!!
Erlang 감독자를 통한 앱 모니터링/관리 기능이 내장되어 있어 앱이 어떻게 작동하는지, 어떤 부분이 충돌/다시 시작되었는지, 그 이유를 정확히 알 수 있습니다! 이것은 우리가 다른 프레임워크에서 ( 많은 ) 비용을 지불하는 기능인데 여기서는 무료 입니다!!
Phoenix를 사용하는 것이 멋진 또 다른 이유 를 생각해 볼 수 있나요?!
이 스레드에서 여러분의 생각을 공유해 주세요 : #13
before Elixir를 배워야 합니까?예 . 참조: https://github.com/dwyl/learn-elixir
아니요 . 오늘부터 Elixir 학습/사용을 시작하고 필요할 때 Erlang 함수를 호출할 수 있습니다.
하지만 Phoenix를 사용하기 before Erlang을 알 필요는 없습니다 !
귀하가 선택할 수 있는 많은 웹 애플리케이션 프레임워크가 있습니다: https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
그렇다면 왜 " 주류 "가 아닌 프로그래밍 언어로 작성된 프레임워크를 선택 하겠습니까 ?
이것은 잘못된 정보 입니다. 우리는 여전히 적절한 여러 프로젝트에 Hapi.js를 사용하고 있습니다 .
여기에는 여러 클라이언트 프로젝트와 내부 dwyl 앱/도구가 포함됩니다.
우리는 다음과 같은 간단한 이유로 새 프로젝트에 Phoenix를 사용하기로 결정했습니다 .
#LessIsMore #LessButBetter #SmallIsBeautiful #SyntaxMatters새로운 프로젝트에는 다중 데이터 센터 내결함성이 필요합니다 !
Erlang -> Elixir -> Phoenix를 사용하면 " 무료 "로 얻을 수 있습니다 !!
우리 생각 에는 Hapi.js가 여전히 " 최고의 " Node.js 프레임워크이며 continue 사용하고 권장할 것 입니다.
확장 가능하고 유지 관리가 쉬운 간단한 앱이 필요한 사람들에게 적합합니다.
참조: https://github.com/dwyl/learn-hapi
또한 우리는 모든 AWS Lambda 마이크로 서비스에 여전히 JavaScript를 사용하고 있으며 이는 변하지 않을 것입니다.
간단하고 효율적이며 확장성이 뛰어납니다!
참조: https://github.com/dwyl/learn-aws-lambda
원래의 " 생산적인 " 웹 프레임워크는 2005년에 "Ruby-on-Rails"와 "Django"( python )였습니다!
(우리는 " 여정 " 동안 이 두 가지를 모두 사용했으며 각각의 장점 에 대해 말할 수 있습니다!)
Rails나 Django를 사용하는 데는 " 아무것도 잘못된 " 것이 없습니다.
우리는 두 프레임워크 모두에 대한 사용 사례가 여전히 많다고 생각합니다.
우리는 "실시간"을 구축하는 것이 ( 많이 ) 더 쉽다 는 것을 알고 있습니다 .
Phoenix에서는 "채널"( WebSockets )이 구워졌기 때문에
Elixir/Erlang 동시성은 완전히 다른 게임입니다!
Erlang(및 Phoenix)은 단일 서버에서 수백만 명의 동시 사용자를 처리할 수 있습니다.
반면 Rails/Django 서버는 수천 개( 기껏해야 !)만 처리할 수 있습니다.
귀하의 앱이 한 번에 수천 명에게만 서비스를 제공한다면 괜찮습니다!!
우리는 Erlang이 " 가벼운 수명이 긴 " 프로세스를 사용한다는 사실을 좋아합니다 .
이는 수백만 개의 ( IoT ) 장치를 연결할 수 있다는 것을 의미합니다. IoT의 경우 Erlang이 ( 의심할 여지 없이 ) 답입니다!
하루에 소수의 사용자만 예상되는 간단한 웹 앱의 경우 Rails/Django가 여전히 실행 가능합니다.
하지만 그럴 필요가 없는데 왜 타협합니까 ?
Ford Focus의 "가격"으로 Tesla 를 구입할 수 있다면 왜 그렇지 않습니까 ?!?
최고의 것을 쉽게 소유/사용할 수 있는데 왜 선 에 안주합니까 ?
예 , GitHub는 여전히 웹 앱/사이트에 Rails를 사용하고 있습니다.
하지만 ( 다시 시작할 기회가 주어진 다면) Rails를 선택할 것인지 GitHub의 핵심 팀 에게 물어보세요.
2017년에 GitHub를 구축하고 얼마나 많은 사람들이 " 물론이죠 "( 무표정한 얼굴로... )라고 말하는지 확인하세요!
또한 GitHub는 백그라운드에서 Scale Rails를 위해 많은 작업을 수행합니다.
그리고 최신 ( 클라이언트 측 ) 기능 중 다수 는 JavaScript로 작성되었습니다! 참조: https://github.com/github
요점은 "DevOps"를 사용하여 모든 것을 확장 할 수 있다는 것입니다.
하지만 Phoenix는default으로 Erlang이 확장을 위해 발명 되었기 때문에 확장 이 가능하도록 만들어졌습니다 !
" 프로그래밍 언어에는 두 가지 종류가 있습니다. 아무도 사용하지 않는 언어와 모두가 불평하는 언어입니다. " ~ Bjarne Stroustrup(
C++창시자 )
바둑은 매우 인기가 있습니다. 주로 Google이 이를 " 후원 "한다는 사실 때문입니다.
이는 Google 내부에서 C++ 및 Java를 단순화( 대체 )하기 위한 것이었습니다.
그리고 대부분 성공했습니다!
우리는 바둑을 정말 좋아해요. 프로그래밍 언어를 결정할 때 이것이 우리의 "두 번째" 선택이었습니다.
( Elixir 이후 ) "post JS 스택"에서... else 대신 에 elixir 사용하기 로 한 결정은 쉬웠 습니다.
추가 자료:
Play Framework를 사용 하지 않는 이유는 무엇입니까? Java를 작성하거나 JVM에 배포하는 데 이미 익숙하다면 Play Framework가 탁월한 선택입니다. https://www.playframework.com
Scala는 좋은 프로그래밍 언어이므로 모두가 배워야 합니다! https://www.scala-lang.org/what-is-scala.html
우리는 ( Node.js를 채택하기 전에 ) Play를 몇 번 사용해 보았는데 정말 마음에 들었습니다!
하지만 스칼라는 사람들이 " 모든 Java "를 사용할 수 있게 해주는 "주방 싱크대"( 멀티 패러다임 ) 프로그래밍 언어입니다.
우리는 Scala의 "Java 상호 운용성"이 코드 베이스에 복잡성을 허용하는 것이 "너무 쉽다"는 것을 의미한다고 생각합니다. 특히 "OOP 돌연변이"...
그렇다면 우리(DWYL)는 왜 새 프로젝트에 더 이상 "Play"를 사용 하지 않습니까 ? 첫째, 우리는 몇 년 전에 Hapi.js( Node.js )로 전환했는데, 그 이유는 Hapi.js가 더 " 가벼워서 " 몇 메가 RAM만 사용하는 작은 프로그램을 작성할 수 있었기 때문입니다( Play 앱은 리소스를 많이 소모했습니다. .! Chromebook과 같은 "기본" 노트북에서 Scala 앱을 실행해 본 적이 있습니까?
Play 대신 Phoenix의 "이유" 요약:
우리 프로젝트에서는 Erlang의 동시성 모델이 더 잘 작동 하고 불변 데이터를 변환하는 기능 코드가 테스트 및 유지 관리가 더 쉽다고 생각합니다 .
" Scala가 더 단순하다 "는 증거가 있다면 우리는 여러분의 의견을 듣고 싶습니다 !
알려주세요: https://github.com/dwyl/learn-phoenix-web-development/issues
함수형 프로그래밍 ( FP )을 그토록 좋아한다면 Haskell을 사용해 보는 것은 어떨까요?
