상용 SaaS 프로젝트에서 Elixir Phoenix 사용하기

Linkly는 Elixir로 작성되었습니다.

저는 항상 Erlang 생태계에 대한 경험을 원했고, Elixir는 쉬운 접근 방법입니다.

여기서는 BEAM이나 Erlang의 이점을 직접 다루지 않겠습니다. 그것은 다른 곳에서 이미 다루어졌기 때문입니다. 대신, 실제 프로젝트에서 Elixir Phoenix를 사용하는 실용적인 측면에 초점을 맞추겠습니다.

Phoenix는 Elixir의 웹 프레임워크로 Rails에서 많은 영향을 받았기 때문에, 여러분이 Ruby on Rails가 무엇인지 알고 있다고 가정하겠습니다.

Elixir로 작성하는 것은 즐거운 경험입니다.

MVC를 포함한 Rails와 유사한 패러다임을 따르며, 심지어 비슷하게 보입니다.

Rails와 달리, 코드는 실행되기 전에 컴파일됩니다. 이는 그렇지 않으면 놓칠 수 있는 오류를 잡을 수 있게 해주므로 유용한 단계입니다.

Phoenix의 모델은 'Context'로 그룹화됩니다. 이것은 애플리케이션의 부분들(예: 사용자와 제품) 사이에 명확한 분리를 만들기 위한 추가적인 추상화 수준입니다. 각 컨텍스트는 여러 개의 모델을 포함할 수 있습니다.

다른 블로그에서 성능에 대해 많이 다루었으므로, 여기서는 실용적인 측면을 다루겠습니다.

완전한 기능을 갖춘 웹 프레임워크로서, 성능은 Rails보다 분명히 훨씬 빠르며, 실행하는 데 필요한 하드웨어도 상당히 적습니다.

mix phx.server 대 rails server를 실행할 때 '부팅' 시간이 더 빠릅니다. 노트북에서 개발할 때도 Phoenix를 사용하면 페이지가 눈에 띄게 빠르게 로드됩니다.

표면적으로는 여기에 차이가 있는 것처럼 보입니다. Rails는 수천 개의 gem을 가지고 있는 반면 Elixir의 Hex 저장소는 그렇지 않습니다.

실제로는, 실제로 사용할 거의 모든 것이 Elixir Hex 패키지 시스템에서 사용 가능합니다 - JSON 파서, HTTP 클라이언트, Markdown 포맷팅 및 파싱 도구 - 모두 있으며, 모듈 품질이 뛰어납니다.

Rails에는 훨씬 더 많은 gem이 있지만, 유지보수되지 않는 상태이거나 애플리케이션에 너무 많은 외부 종속성을 구축하는 것과 관련된 위험 때문에 실제 프로젝트에 포함하지 않을 것입니다.

Stripe 및 Recurly와 같은 플랫폼은 자체 API와 상호 작용하기 위한 자체 Rails gem을 유지 관리합니다. 이는 편리할 수 있지만, 일반적으로 Elixir에 대한 지원이 부족합니다.

그러나 저는 서비스의 HTTP 엔드포인트와 상호 작용하기 위해 Elixir의 Tesla 패키지를 사용하는 것이 매우 쉽다는 것을 발견했고, 결국에는 미리 패키징된 gem을 사용하는 것보다 이 방식으로 작업하는 것을 선호하게 되었습니다. 더 가볍고 무슨 일이 일어나고 있는지 이해할 수 있기 때문입니다.

Ecto는 ActiveRecord만큼 완전한 기능을 갖추지 않았습니다.

그럴 의도가 아닙니다.

Ecto는 데이터베이스 쿼리를 Elixir 객체에 매핑하는 간단한 데이터베이스 래퍼입니다.

처음에는 ActiveRecord처럼 작동하지 않는다는 것이 답답했습니다.

그러나 Ecto를 사용하면 매우 직관적인 방식으로 데이터베이스와 상호 작용할 수 있으며, 실제로 웹 애플리케이션 프로그래밍을 훨씬 쉽게 만듭니다.

ActiveRecord의 경우, 복잡한 쿼리를 만들기 시작하면 SQL로 쿼리를 작성하는 것보다 ActiveRecord를 이해하는 데 더 오래 걸립니다.

둘 다 사용해본 결과, Ecto와 같은 경량 데이터베이스 래퍼를 사용하는 것이 ActiveRecord와 같은 중량 추상화를 사용하는 것보다 쉽다는 것이 제 결론입니다.

데이터베이스 래퍼를 사용하는 안전성은 제공하면서, '너무 영리한' 추상화의 골칫거리와 무게는 없습니다.

둘 다 마이그레이션 및 롤백 기능을 포함합니다.

Phoenix 프로젝트의 기본 데이터베이스는 Postgres입니다.

NoSQL 데이터베이스를 사용하는 사람들을 위해, Ecto는 Mongo와 함께 작동합니다.

더 좋은 것은, Ecto가 Postgres의 NoSQL 기능과 함께 작동하여, Mongo 없이도 JSON을 저장하고 쿼리할 수 있다는 것입니다.

이것은 Elixir Phoenix가 부족한 부분입니다.

Rails에는 Devise 모듈이 있습니다. Phoenix에는 Coherence가 있지만, 현재 유지보수되지 않고 있습니다.

기본적인 사용자 이름 및 비밀번호 로그인을 사용하려면, 그 모든 단계를 직접 구축해야 합니다. 여기에는 비밀번호 해싱, 비밀번호 재설정 로직, '로그인 상태 유지' 설정 등이 포함됩니다.

이것은 지루하고 상당한 보안 위험을 수반합니다.

저는 Phoenix와 잘 작동하는 Auth0을 사용하기로 했습니다. 어쩌면 이것이 어쨌든 더 나은 해결책일 수 있지만, 선택의 여지가 있었으면 좋았을 것입니다.

Phoenix 앱의 주요 호스트는 Elixir 애호가들이 운영하는 미국의 작은 회사인 Gigalixir입니다.

Gigalixir는 Google Cloud에서 호스팅되므로 기본 인프라가 견고합니다.

Gigalixir의 빌드팩은 배포를 쉽게 만들고 Elixir의 모든 영리한 배포 전략(distillery, mix)을 지원합니다.

'직접 구축'하는 것보다 비싸지만, 대부분의 비용은 Postgres 데이터베이스 호스팅에 포함됩니다.

Elixir Phoenix는 너무 가벼워서 작은 도커 팟에서 실행할 수 있으며 여전히 매우 많은 수의 요청을 처리할 수 있습니다.

마크업에도 불구하고, 골칫거리를 없애기 위해서는 절대적으로 가치가 있습니다.

덧붙이자면, 그들의 고객 지원은 탁월합니다.

Elixir 프로그래머는 훨씬 적습니다.

Elixir는 "프로그래머의 언어"입니다 - 다른 것을 배운 후에 찾아오는 언어입니다.

그렇긴 하지만, Elixir를 하는 사람들은 일반적으로 더 나은 프로그래머입니다. 아마도 더 나은 언어를 선택하는 의식적인 선택 때문일 것입니다.

이것은 "록스타"만이 사용하는 것처럼 보였던 Rails의 초기 시절을 떠올리게 합니다(PHP 대비).

좋은 Rails 프로그래머라면 누구나 Elixir Phoenix를 배우는 데 문제가 없을 것이며, 며칠 내에 작동하게 될 것입니다.

물론입니다.

저는 많은 언어를 사용해 왔으며, Elixir는 제가 작업한 것 중 가장 쉽고 강력합니다.

Elixir를 작성하는 것을 기대합니다.