TeamGenik은 Elixir와 Phoenix LiveView로 만들어져 있습니다

프로그래밍 언어 Elixir

TeamGenik의 핵심 시스템은 함수형 프로그래밍 언어 인 Elixir에 의해 설명되어 있습니다.

Elixir는 2012 년에 태어난 새로운 언어입니다. 1972 년에 태어난 C, 1991 년에 태어난 Python, 1995 년에 태어난 Java, Ruby 등에 비해 아직 알려지지 않았지만 웹 및 IoT 분야에서 인기를 얻고 있습니다. 2019 년 10 월에 발표 된 InfoQ의 Programming Languages InfoQ Trends Report에 따르면, Elixir는 "혁신" 단계에 들어 섰습니다.

Phoenix Framework

TeamGenik은 Elixir 기반의 Web 어플리케이션 개발 프레임 워크 인 Phoenix Framework ("Phoenix")를 채용하고 있습니다.

Phoenix는 Ruby on Rails의 영향을 많이받습니다. 특히 라우팅 및 컨트롤러 메커니즘은 매우 유사합니다. Phoenix가 데이터베이스 작업에 사용하는 라이브러리 Ecto는 Active Record와 유사합니다. Ruby on Rails에 익숙한 사람들에게는 Phoenix가 매우 자연스러운 선택이었습니다.

Phoenix LiveView

TeamGenik은 Phoenix LiveView를 사용하여 HTML 코드를 렌더링합니다. Phoenix LiveView는 두 단계로 HTML 코드를 생성합니다.

• 앱 외부에서 발생하는 이벤트를 받고 응용 프로그램의 "상태"를 새로운 "상태"로 변환.
• "상태"의 변화를 감지하여 HTML 코드를 생성합니다.

Phoenix LiveView는 WebSocket을 통해 브라우저와 서버 사이를 상시 연결합니다.

Phoenix LiveView는 "상태"의 변화에 ​​따라 HTML 코드에 생긴 '차이'만을 브라우저에 쓰기 때문에 브라우저와 서버 간의 통신량은 낮게 누를 수 있습니다.

단일 페이지 응용 프로그램 (SPA) 개발의 신조류

TeamGenik은 단일 페이지 응용 프로그램 (SPA)로 만들어져 있습니다. 즉, 사용자가 링크를 클릭 할 때마다 화면 전환을 발생시키는 것이 아니라 그 자리에서 화면의 일부를 변화시키고 있습니다.

2010 년대 후반에는 SPA 개발이 융성 해져, React, Angular, Vue로 대표되는 JavaScript 프레임 워크가 널리 사용되게되었습니다.

그러나 우리는 2020 년대 이후의 흐름을 내다보고 Phoenix LiveView를 채용했습니다. Phoenix LiveView에 따르면 SPA 개발은 서버 측 중심이라는 점에서 기존의 것과 다릅니다.

위의 그림은 JavaScript 프레임 워크를 사용한 시스템 구성 및 Phoenix LiveView를 이용한 시스템 구성을 비교 한 것입니다. "State"라고 적힌 2 개의 타원은 응용 프로그램이 보유하는 데이터 (상태)를 나타냅니다. 어떤 시스템 구성도이 "State"에서 HTML 코드가 생성됩니다. 사용자 조작으로 인해 "State"가 변경되면 HTML 코드가 그에 따라 변경되고 브라우저 화면이 변경됩니다.

왼쪽의 시스템 구성에서 "State"가 브라우저에 있습니다. 이 "State"를 다시 "State"에서 HTML 코드를 생성하는 데 큰 JavaScript 프로그램을 브라우저상에서 움직이는 것입니다. 한편, 오른쪽 Phoenix LiveView를 이용한 시스템 구성에서 "State"이 서버 측에 있습니다. 서버에서 Elixir 프로그램이 동작하고, "State"를 다시 "State"에서 HTML 코드를 생성합니다. 그리고 브라우저상에서 움직이는 작은 JavaScript 프로그램과 WebSocket 연결하고 브라우저에서 이벤트를 받고, HTML 코드의 차이를 브라우저에 보내기도합니다.

개발의 초점이 프론트 엔드 (브라우저 측)에서 서버 측으로 이동 한 데는 4 가지 주요 이유가 있습니다.

• 비 함수형 언어 인 JavaScript로 프로그래밍이 거의 불필요해진다. 즉, 시스템의 거의 전체를 1 개의 언어 (Elixir)에서 개발할 수있다.
• 프런트 엔드에서 문의를받는 API를 구현할 필요는 없습니다.
• 프런트 엔드 서버 사이드에서 유사한 기능 (검증 등)를 중복하여 만들 필요가 없어진다.
• 악의적 인 사용자가 JavaScript 소스 코드를 분석하여 시스템 공격 팁을 얻고, 기업 비밀을 폭로 할 수 없게된다.

물론 그로 인해 잃는 것도 있습니다. 사용자의 컴퓨터에서 수행되던 작업의 일부가 서버 측에 움직이는 것은 서버에 부담이 증가하는 것을 의미합니다. 또한 프런트 엔드 서버 사이드의 사이에 발생하는 트래픽이 증가합니다. 또한 브라우저와 서버 간의 네트워크 적으로 떨어져있는 경우 사용자가 반응의 지연을 느끼는 빈도가 늘어날지도 모릅니다.

피닉스 라이브 뷰 (Phoenix LiveView)의 개발 및 수용이 진행됨에 따라 이러한 단점을 극복 할 수있을 것으로 확신합니다. 어쨌든, 2019 년 8 월에 버전 0.1이 나왔을뿐, 아직 버전 1.0에 도달하지 않기 때문입니다.

LiveView Socket 브라우저와 1 대 1로 대응

전통적인 Web 시스템에서는 약간 Web 어플리케이션이 매우 많은 브라우저에서 액세스에 응답합니다 (그림 참조).

하나의 웹 응용 프로그램이 여러 브라우저의 요청을 순서대로 처리합니다. 또한 어떤 웹 응용 프로그램이 특정 브라우저의 요청을 담당하는지는 일정하지 않습니다. 결과적으로 웹 응용 프로그램은 특정 브라우저 별 데이터를 보유 할 수 없습니다. 데이터는 데이터베이스 또는 브라우저의 "State"에 저장됩니다.

한편, LiveView를 이용한 시스템에서는 다음 그림과 같이 LiveView Socket 브라우저와 1 대 1로 대응합니다. 양자는 WebSocket을 통해 항상 연결 상태입니다.

각 LiveView 소켓은 매우 작아서 단일 서버에서 수천 또는 수만 개를 계속 실행할 수 있습니다. 그리고 각 LiveView 소켓에는 고유 한 "State"가 있습니다.

이와 같이, Phoenix LiveView를 사용하면 Web 시스템을 만드는 방법이 근본적으로 변화하고 있습니다.