QueryPie는 왜 React & Typescript를 선택하게 되었나
QueryPie 개발기 #8: Front-end 개발 배경에 대해서
“세상에서 가장 빠른 것은 아마도 시간이 아닐까 싶다.”
첫 번째 스프린트를 시작하면서 앞으로 일어날 일들에 대한 기대로 마냥 설레였던게 어제 같은데 벌써 3번째 스프린트가 끝났다. 그런데 두 번째 글을 마치고, 다음 내용을 고민하다가 개발기의 시작이 잘못된 건 아닐까라는 생각이 들었다.
개발기가 시작되기 전에 왜 이런 글을 쓰게 되었는지, 그리고 내가 왜 이렇게 개발하게 되었는지를 이야기해야하지 않았을까?
사실 QueryPie를 개발하는 일은 그동안 수 없이 만들었던 고객사의 홈페이지나 ERP(외주용역 or SI) 등을 만드는 일처럼 서둘러 기획하고 디자인 및 개발할 수 없는 일이었다. 그래서 개발하면서 겪었던 어려운 문제나 새로운 발견들을 글로 엮어내면 좋겠다고 생각했고, 개발 배경에 대해서는 반드시 한 번 이야기하고 넘어가고 싶다. 오늘은 다시 시간을 거슬러 어디에서부터 이 모든 것이 시작되었는지 이야기하려고 한다.
오픈소스(Open Source) 활동의 시작
AXISJ 프로젝트
나는 2013년부터 직접 만든 Javascript UI component를 오픈소스를 발표하고 외부활동을 하기 시작했다. AXISJ라는 이름의 오픈소스 프로젝트였다. 내 인생을 통틀어 돈이 되지 않는 일을 그렇게 열심히 해본적이 없었다. 심지어는 내 돈을 더 써야 했다. (지금 AXISJ 프로젝트는 리뉴얼을 거쳐 AX5UI라는 프로젝트로 재탄생하였다.)
‘오픈소스를 열심히 해서 유명해지고 싶었다.’
왜 유명해지고 싶은지는 몰랐지만 이번 인생에서 사람들에게 한 번쯤은 주목받고 싶었던 것 같다. 천재적인 재능이 있는 스타일은 아니었지만 누구보다 꾸준하고 열심히 하는 일에는 자신이 있었기에 어느 정도 성과를 낼 수 있었다. 개발자 대회에 몇 차례 나가서 상도 받게 되고 대단히 쓸모 있는 사람이 된 것 같은 기분이 들었다.
하지만 즐거움보다는 힘든 일이 더욱 많았다. 하고 싶은 일과 돈을 버는 일 사이에 밸런스를 유지하는 고통스러운 시간이 계속 되었고 그 속에서 점점 떨어지는 체력을 유지하는 일은 쉽지 않았다. 물론 후회해본 적은 단연코 절대 없다. 그리고 오픈소스 활동에 대한 보상으로 좋은 사람들을 알게 되어서 모든 고통을 잊을 수 있었다.
사실 지금 어떻게 개발하고 있는지는 그 동안 만났던 사람들의 이야기를 빼놓을 수 없으므로 간략하게 그 역사를 이야기하고자 한다.
CHEQUER로 함께하게 된 인연들
우선 Benjamin은 오픈소스를 막 시작한 나에게 무턱대고 와서 친해질 것을 요구했다. 그는 SQLGate라는 데이터베이스 관리 툴을 만드는 개발자이자 CEO였다. 특유의 친화력으로 AXISJ 프로젝트에 후원했던 모든 사람들에 나를 도와주라고 권유했고, 그 덕분에 좋은 사람을 만날 기회가 더욱 많아졌다.
Brant 역시 평생 만나본 적 없는 특별한 사람이었는데, 초등학교 때부터 컴퓨터 프로그래밍에 빠져 고등학교 입학 한달 만에 자퇴하고 독학으로 대학 진학을 했다. 그 후 KAKAO의 소프트엔지니어로 입사하고 KAIST에 입학한 인재였다. Brant와는 카카오 퇴사 후에도 계속 연락을 하며 지냈고 함께 회사를 설립하기로 했다. 그 회사가 CHEQUER다.
CHEQUER는 이렇듯 개발자 2명이 세운 회사이기 때문에 우리가 어떤 비즈니스를 할 지보다 개발을 어떻게 잘 할 것인가에 관심이 많았다. 그러던 중 회사가 만들어지고 얼마 안되어서 Benjamin이 CHEQUER에 입사하겠다고 했다. 본인이 가진 모든 것을 걸테니 함께하자는 제안이었다. 우리는 SQLGate를 전 세계인이 사용하는 소프트웨어로 만들자는데 뜻이 통했고 함께하기로 했다.
그리고 후에 만난 Woo는 내가 React & Typescript로 개발하는 데 결정적인 역할을 한 사람이다. 뒤에서 다시 언급하겠지만 개발을 하면서 겪는 한계로 React, VueJS, AngularJS 등의 새로운 개발 언어를 두고 고민을 하고 있었고, 역시 오픈소스 활동을 하면서 만나게 된 인연인 Woo의 조언이 큰 도움이 되었다. 그는 백과사전같은 사람이었는데, React가 나에게 더 맞는다고 이야기했고 그 말에 힘을 얻은 나는 React 튜토리얼을 학습하고 관련 공부와 React로 DataGrid를 만드는 일을 병행했다.
배경 이야기가 너무 길어서 짧게 쓰려고 엄청 신경쓰며 적었다. 막상 정리해서 적고 돌아보니 간단하게 느껴지는게 ‘그동안 마셨던 소주들은 무슨 의미 였을까’ 라는 생각을 하게 된다.
SQLGate 5의 시제품을 만들면서
드디어 본론으로 들어가면 SQLGate는 윈도우에서만 작동되는 소프트웨어였다. 위에서 언급한 것처럼 전 세계인이 사용하는 소프트웨어가 되려면 OS를 가리지 않고 작동할 수 있어야 한다고 생각했고, 새로운 소프트웨어를 만드는 방법을 고민해야 했다.
그래서 NodeWebkit이나 JXBrowser를 이용하면 우리가 원하는 소프트웨어를 만들 수 있다고 생각했다. 이들은 WebView를 Renderer로 사용하는데 이렇게 하면 애플리케이션의 View부분이 OS 의존성에서 자유로워질 수 있고 만드는 방법도 웹기술의 경험을 살려서 개발할 수 있다. 사실 이런 개발방법은 오늘날 그리 어렵지 않게 접할 수 있다. Slack, VSCode, Atom, GitKraken 등 많은 소프트웨어들이 이런 방법을 이용하여 멀티 OS를 지원하는 서비스를 하고있다.
과거에는 이런 하이브리드 형태의 애플리케이션이 UI 반응속도가 떨어지고 OS 자원을 효과적으로 다루지 못해 많은 관심을 받지 못했지만 요즘은 하드웨어의 성능이 좋아지면서 성능이슈를 극복해가고 있다.
WebView를 이용하여 개발을 한다고 해도 새로 만드는 소프트웨어에 기존 SQLGate의 기능을 모두 반영하는 것은 현재 우리가 가진 리소스로는 불가능하다는 판단을 했다. 그리고 이런 방법으로 개발하는 것이 얼마나 효율적인지 확인하는 것이 우선이라고 생각했다.
그래서 일단 SQLGate 5라는 이름으로 시제품을 만들어 보기로 했다.
2달 동안 시제품을 만들어보고 앞으로 방향을 어떻게 잡아야 할지, 우리의 생각이 맞는 생각인지 확인해보고 싶었다. Back-end는 JAVA를 베이스로 개발하고, Front-end는 jQuery와 직접 만든 AX5UI를 이용했으며 JAVA와 궁합이 좋은 JXBrowser를 이용하여 애플리케이션을 만들었다.
시제품을 만들고나니 결과는 꽤 괜찮았지만, Front-end 개발자로서 고민이 많아졌다. 애플리케이션 개발자로 산다면 배포가 되고난 후 걱정은 죽을 때까지 해야겠지만 그 중 세 가지 고민이 내 발목을 잡았다. 그리고 현재의 애플리케이션은 몇 가지 아쉬운 점을 가지고 있다는 결론에 이르렀다.
- 애플리케이션을 언제든지 원하는대로 빠르게 변경할 수 있을까?
- DOM 컨트롤을 좀 더 편리하고 안전하게 만들 수 있을까?
- 문제가 있는지 실시간으로 확인할 수 있을까?
문제 1. 기능 추가 및 변경의 복잡성
간단한 애플리케이션을 제작하는 경우는 컴포넌트(위 그림에서 Search ToolBar, Contents와 같은)중심으로 제작하는 방법이 효율적일 때가 많다. 컴포넌트에 사용자의 행동으로 예상되는 기능들을 담아서 번들링해두면 애플리케이션의 다른 화면 혹은 다른 애플리케이션을 제작할 때에 코드를 붙여넣고 컴포넌트에 입력값을 전달하거나 가져오는 작업, 그리고 컴포넌트 안에서 발생되는 이벤트 핸들러를 맞춰주어 손쉽게 완성도 높은 화면을 구성할 수 있기 때문이다.
이렇게 컴포넌트 중심의 화면개발 방식이 익숙하고 편했지만 우리가 만드는 시제품에서는 상황이 달랐다.
컴포넌트의 종류와 개수가 평소에 만들던 웹사이트나 웹어드민 시스템들과는 차원이 다르게 많았고, 컴포넌트의 액션을 처리하는 함수 또한 그랬다.
개수가 많은 문제는 오랜 개발구력으로 극복할 수 있었지만 함수들과 컴포넌트들 간에 상호작용이 엉킨 실타래 처럼 되어버려서 기능을 추가하거나 변경할 때마다 사이드 이펙트(Side effect)가 발생할까 두려웠다.
사이드이펙트 문제는 테스트 코드를 활용하여 극복할 수도 있다지만, 발견된 에러를 수정하는 일은 머리속에 ‘도쿄 지하철 노선도’를 매 번 다시 그려야 할 정도로 복잡하고 어려운 일이었다.
문제 2. 깔끔하지 못한 DOM 컨트롤
우리가 만드는 소프트웨어가 데이터베이스의 각종 정보를 조회하고 사용자가 원하는 쿼리를 요청하여 결과를 보는 툴이다 보니 자연스레 DOM을 변경해야 하는 작업을 많이 해야 한다. 그것도 아주 많은 양의 데이터를 출력하면서 말이다.
DOM Node를 추가/변경/삭제하는 가장 빠른 방법은 VanillaJS(개발자들이 부르는 일종의 은어. 프레임워크나 라이브러리 없이 표준 API만을 이용하는 방법)가 가장 빠르다. 하지만 실제 개발환경에서 템플릿 엔진의 도움없이 화면을 만드는 일은 원시적이고 비생산적이다.
그래서 성능 좋고 다루기 편리한 템플릿 엔진을 찾아서 각 화면들에 필요한 템플릿 코드들이 쓸데없이 만들어지지 않도록 잘 관리해야만 했다. 하지만 아쉽게도 설계 문서에 템플릿들의 목록을 잘 정리하고 머리 속에 담아두는 일은 금방 한계를 드러냈다.
그리고 더욱 큰 문제는 템플릿 코드를 템플릿 엔진으로 변환한 후에 변경이 적용될 DOM Node가 출력할 때 깜박이는 현상이 있다는 것이었다. 또 DOM Node에 바인딩해둔 이벤트들은 화면이 다시 그려지기 전에 unbinding하고 다시 그린 뒤에 binding 해줘야는 문제점이 있었다.
그 사이에 가비지 컬렉션(Garbage collection)은 잘 되고 있는지 메모리 누수(Memory Leak) 현상은 없는지 우려가 되었지만 짧은 시간동안 일일이 확인 하는 일은 불가능 했다.
다시 랜더링되어야 하는 타겟을 할 수 있는 만큼 잘게 쪼개고 관리한다면 이런 문제는 극복할 수 있을 거라 생각했지만, 이렇게 만든 애플리케이션을 사용했을 때 느껴지는 미세한 이질감은 어떻게 할 수 없는 문제였다.
문제 3. 부족한 에러 리포트
만약 새로 오픈한 식당 주인이 손님이 느끼는 모든 것을 알 수 있다면 그 집은 반드시 맛집으로 대박이 날 것이다. 음식의 맛에서부터 분위기, 청결, 음악, 서비스까지 어디에서 만족하고 불만족하는지를 모두 알기란 참으로 쉽지 않은 일이다.
하지만 우리가 만드는 애플리케이션에 있어서는 최대한 그런 것들을 알 수 있게끔 만들고 싶었다. 사용 중 에러 혹은 불편한 점은 없었는지, 사실 만드는 사람의 입장에서는 모든 것을 알고 싶기 마련이다. 그렇지만 현실은 window.onerror 핸들러를 이용하여 서버로 에러 내용을 전달하는 일이 전부였다.
이렇게 문제점들을 보고나니 새로운 개발 환경을 고려하게 되었고, 이것이 지금의 QueryPie가 탄생하게 된 배경이다.
React & Typescript로의 전환
10년 간 써왔던 jQuery
나는 jQuery를 2009년부터 사용했다. 그 당시에는 브라우저 파편화(Web Browser Fragmentation)가 심했기 때문에 jQuery는 굉장히 많은 사람들이 사용했고 나 역시 그랬다.
10여년 가까이 써온 정든 jQuery를 이제 그만써야 한다는 결론을 내리기는 정말 어려웠다. 더욱이 나의 경우엔 AX5UI를 1년 가량 혼자 만들어왔기 때문에 새로운 환경으로 전환을 결정하는 일은 너무 두려웠다. 하지만 앞서 시제품을 만들면서 부딪혔던 문제점, 그리고 결정적으로 Woo와의 이야기를 통해 변화가 필요하다는 생각이 들었다.
그래서 React로 개발을 고려하기 시작했고, 기존에 만들어오던 UI 컴포넌트들을 React에서 작동하도록 감싸서 사용하거나 (하지만 이렇게 하면 React코드 안에 jQuery가 함께 담기게 된다. 이런 일은 개발자로서 도저히 참을 수 없는 일이다.) 기존에 만들어 오던 UI 컴포넌트들을 React로 다시 만들어야 했다.
물론 애플리케이션을 구성하는데 필요한 기본적인 UI 컴포넌트들은 잘 만들어진 React용 UI Framework를 선택해서 해결할 수도 있지만 DataGrid는 꼭 직접 만들어야한다고 생각했다.
세 번의 리팩토링을 거친 DataGrid
이렇게 만들기 시작한 DataGrid는 총 3번의 리팩토링을 거쳐왔다. 첫 번째는 TypeScript를 도입하면서 코드를 전부 다시 만들었을 때이고, 두 번째는 Redux를 걷어내고 ContextAPI를 사용하면서 의존성이 없는 컴포넌트로 변신하면서, 그리고 마지막으로는 내부에서 사용되는 state와 외부에서 전달받는 props을 정리하면서다.
React & Typescript로 만드는 QueryPie
그렇다면 오늘 글을 쓰게 되었던 진짜 주제로 넘어가서, 앞서 부딪혔던 3가지 고민들을 React를 사용하면 어떻게 달라지는지 살펴보자.
해결 1. 기능 추가 및 변경의 유연성
React & Typescript로 개발하면서 애플리케이션에 기능을 추가하는 상황을 생각해보자. 특정 화면을 만들어 둔 상태에서 요구사항이 변경되어 목록의 검색조건을 추가해야한다고 가정해보겠다.
이럴 때는 기존에 만들어져 있는 List 컴포넌트에 검색 UI를 추가하지 않고 별도의 Filter컴포넌트를 추가한 후 List와 Filter를 조합하여 사용할 수 있다. 위 그림의 코드는 몇 줄 안되는 간단한 형태이지만 우리가 실제 만나게 되는 컴포넌트들은 거대하고 까다로울 수 있다.
그래서List 컴포넌트에서 filter Prop을 받을 수 있도록 수정하고 새로운 Filter컴포넌트를 만들어서 Filter에서 입력받은 filter값을 List컴포넌트에 전달되도록 해주어야 한다. List에서는 List밖에서 일어나는 일들에대해서는 고려하지 않고 filter에 따라 목록이 출력되도록 할 수 있다.
이런 방법으로 개발할 수 있기 때문에 컴포넌트의 의존성을 최소화 할 수 있고 기능을 추가 하거나 변경할 때 좀 더 유연하고 ‘사이드이펙트’가 적은 코드를 작성할 수 있게 된다.
새로운 기능이 추가되면서 기존 코드인 List컴포넌트의 변경은 아래와 같이 최소화되고 새로 추가된 Filter컴포넌트에 의존성이 없기 때문에 향후 List가 다른 컴포넌트와 조합이 된다고 해도 (대부분의 경우) 큰 문제없이 재사용이 가능하다.
이렇게 React를 이용하면서 얻게되는 모듈 코딩의 장점은 ES6와 TypeScript를 사용하면 그 효과가 더욱 극대화 된다.
ES6부터 추가된 구조 분해 할당(destructuring assignment)과 화살표 함수(arrow function)등은 JSX코드를 간결하게 만들수 있게 해주고 TypeScript는 컴포넌트와 함수들이 사용하는 Props과 Argument의 스펙을 따로 학습하지 않아도 사용할 수 있게 해주기 때문이다.
그리고 QueryPie 개발팀의 경우 Mobx와 MST를 사용하고 있는데, 모델과 컴포넌트를 분리하면 모델과 API가 통신하여 모델의 Store를 변경하고 컴포넌트는 모델에 담겨있는 데이터만 보면서 개발을 진행 할 수 있다.
보다 자세한 내용은 Woo Gim이 작성한 글에서 얻을 수 있습니다.
해결 2. 편리하고 안전한 DOM 컨트롤
앞서 이야기했던 Framework dom 조작 성능에서 볼 수 있듯이 React를 이용하여 랜더링을 제어하는 것만이 랜더링 속도를 높일 수 있는 방법은 아니다.
하지만 속도의 차이라고 해봤자 눈 깜박이는 속도(평균 100~150ms)보다 훨씬 짧은 시간이고 UX경험은 산술적인 수치보다는 사용자가 느끼는 감정이 더욱 중요하다고 생각한다.
React Virtual DOM을 만들어 랜더링하기 때문에 효율적이라는 이야기는 아마도 다들 들어봤을 것 같다. 물론 내가 Virtual DOM을 만들지도 않았고 내부의 작동 원리와 구조에 대해서는 잘 알지 못하기 때문에 자세히 설명하는 것은 어렵다고 생각한다.(언젠가는 할 수 있겠지만) 그렇지만 React로 만들었을 때와 기존에 내가 사용하던 방식으로 만들었을 때의 차이에 대해서는 이야기 할 수 있다.
위에서 볼 수 있듯이 스크롤을 하면 출력할 엘리먼트를 table부터 다시 만들어주고 있는 것을 확인할 수 있다. 또 빠르게 스크롤 할 때 깜박이는 현상도 있다. 이는 IE와 같은 브라우저에서 스크롤 속도가 느린 문제를 해결하기 위해 휠 이벤트가 발생될 때마다 랜더링을 다이렉트로 하지 않고 Throttled 처리를 해주고 있기 때문이다.
그렇다면 React로 만든 Datagrid는 어떻게 다를까?
React로 만들었기 때문에 스크롤이 될 때마다 변경해야 할 DOM의 각 부분을 React가 찾아내어 변경해주고 있다.
React로 개발하면 DOM의 구조가 변경되지 않고 내용이나 속성만 변경되기때문에 사용자가 느끼기에 더욱 자연스럽고 부드럽게 데이터가 변경되고 있다는 생각이 들게 해준다.
그리고 React의 render 함수가 실행되는 속도를 개발자가 직접 제어하지 않기 때문에 데이터에 잦은 변경이 일어나도 걱정할 필요가 없다. React는 이미 많은 글로벌 서비스에서 사용되고 있기 때문에 전 세계인이 테스트를 대신 해주었다고 할 수 있고, React 개발진을 직접 만나보지는 못했지만 적어도 우리 팀원들의 몇 배 이상의 자원을 이 프로젝트에 쓰고 있음은 확실하기 때문이다.
해결 3. 에러 리포트 개선
에러 리포트를 이야기하기 전에 개발자가 언제 어떤 에러를 많이 내는지 이야기 해보자.
사실 에러리포트와 관련한 작업은 아직 준비 중에 있기 때문에 자세한 경험기는 쓰기 어렵습니다. 죄송합니다. ㅜ.ㅜ;
개발자가 만들어 내는 대부분의 에러는 ‘오타’ 때문이다. 주변에서 하루종일 에러를 찾았는데 결국은 오타 때문이었다는 이야기는 익히 들었을 것이다.
그렇다. 사실 오타만 없어도 우리는 많은 시간을 절약할 수 있을 것이다. 오타를 방지하는 방법 중에 TypeScript를 사용하는 것은 내가 경험한 방법들 중에 가장 만족스러운 방법 이었다.
(1) VSCode + TypeScript
6개월 전만 해도 나는 IntelliJ유저였다. IntelliJ는 강력한 툴이고 여전히 주변의 많은 개발자가 사용 중이지만 적어도 React와 TypeScript로 개발하는 Front-end 개발자에게는 불편한 도구라 생각된다.
VScode로 개발을 하면 JSX태그에 쓰는 컴포넌트, 컴포넌트 속성, 함수, 함수의 인자 등을 팝업으로 확인하면서 개발할 수 있다.
AntD와 같은 UI Framework를 사용할 때 가장 어려운 점은 직접 만든 코드를 사용하는 것이 아니기 때문에 어떤 속성이 있는지, 또 속성은 어떻게 사용해야하는지 암기하는 것이다.(요즘에는 모르겠지만 옛날 사람들은 전부 외워서 해결했다…) 이런 점도 VSCode를 사용하면 쉽게 확인할 수 있기 때문에 편리하고, 에러를 줄이는 데 훨씬 도움이 된다.
(2) 공유할 수 있는 코드: 모든 변수와 함수는 정의할 수 있다
자바스크립트를 오랜 시간 개발하고 잘하는 분들이 주변에 많은 편이다. 그 분들의 특징은 응용력이 뛰어나다는 것이다. ES5까지 자바스크립트를 개발하려면 그래야했다. Class를 만드는 방법도 여러가지이고 그 외에 코딩을 하는 스타일도 개발자마다 모두 제 각각이었다.
하지만 뛰어난 개인이 모든 것을 다 만들어내는 장인의 시대 끝났다. 이제는 팀워크가 더욱 중요하다. 앞으로 소프트웨어는 점점 더 복잡해지고 더욱 많은 일을 할 수 있어야하기 때문에 코딩하는 방법도 집단이 함께 이해하고 만들어 갈 수 있어야 한다. 만약 우리가 만든 코드를 모듈로 내보내어 다른 개발자가 사용하게 한다면 위와 같이 할 수 있다.
위 코드는 axui-datagrid의 타입정의파일의 일부분이다. 이렇게 정의하고 빌드할 때 declaration:true 조건을 주면 d.ts파일이 만들어진다.
이렇게 개발한다면 개발한 작업물에 대해 문서를 따로 정리할 필요가 줄어들 것이다. 사실 개발문서의 90%는 함수가 어떤 인자를 사용하고 어떤 결과를 리턴하는지 기록하는 것이다. 물론 문서가 제대로 업데이트되지 않는다면 무용지물이 되기 십상이다.
(3) Error Tracking
사실 React 작동 방식에 대해 어느 정도 이해를 한 후에 에러 트랙킹은 얼마든지 가능할 것이라고 생각했다. 모든 Rendering이 React.Component Class에서 일어나고 있기 때문에 가능할 것이라 생각했다.(하지만 붙여본적은 없음)
그래서 여기에서 더욱 자세한 이야기를 하기보다는 Woo에게 추천 받은 링크를 투척하는 것으로 Error Tracking 관련 이야기를 마치겠다.
맺음말: 모든 변화에 유연하게 대처하자
기존의 익숙한 방식을 새로운 방식으로 바꾸는 일은 정말 어렵고 고통이 따른다. 하지만 소프트웨어 분야에서 영원한 것은 없고 언제나 새로운 기술이 오래된 기술을 대체한다.
지금 우리가 좋아하고 익숙한 것은 또 언젠가 새롭고 더욱 편리한 방식으로 대체 될 것이다. 그렇다면 우리는 무엇을 해야 할까? 우리는 리듬에 몸을 맡기고 즐겨야 한다. 좋아하는 유행가의 리듬이 바뀌었다고 멈추어서는 안된다. 변화를 귀찮고 힘든 것이 아니라 기존에 알지 못했던 새로운 기쁨으로 받아들일 자세만 있으면 된다.
SQLGate는 이제 QueryPie라는 새로운 희망으로 그 생명을 연장하려고 하고있다. 그 시작에 작은 힘이나마 보탤 수 있어서 기쁘고, 보다 많은 사람들이 우리의 작업물을 이용하게 되기를 간절히 바란다.
📑영어(English Version)- https://medium.com/p/56c9b2ab352/
