본문 바로가기

Web Programming/Ruby on Rails

Rails 분석 Gem 비교(조회수, 방문통계 등)

특정 모델에 대해서 조회수 기능이 필요할 때나 웹 사이트에 대해서 방문자 통계, 이벤트 트래킹이 필요할 때가 있다. 레일즈에서는 이런 이벤트 트래킹 관련해서 여러가지로 활용할 수 있는 대표적인 Gem이 두가지가 있다. Impressionist Ahoy라는 Gem이다. 두 Gem 모두 많이 활용되는 Gem 이며 뚜렷한 장점이 있었다. 이번에 두 Gem 모두 써보게 되어서 나름의 간단한 비교를 해보려고 한다.


단순 정량 데이터 비교

 

출처

정량 데이터로만 보면 Ahoy 쪽이 조금 더 관리가 많이 되고 있고 일반적으로 더 선호하고 있다. 개인적으로 생각했을 때, 방문자 통계를 제공해주는 기능이 더 강력하고 Rails 프레임워크의 강점과 조금 더 잘맞는 Gem이어서 그런가싶다.

 

 


Impressionist

https://github.com/charlotte-ruby/impressionist

 

charlotte-ruby/impressionist

Rails Plugin that tracks impressions and page views - charlotte-ruby/impressionist

github.com

Impressions라는 이벤트 모델을 만들고 특정 모델에 대해서 이벤트들을 쌓을 수 있다. 이 쌓은 이벤트들로 조회수 라던지, 어떤 유저가 어떤 Event들로 상호작용했는지 등으로 활용할 수 있다. (이 이벤트 모델을 다른 데이터 모델에 종속시킬 때, counter_cache를 고려해야 한다).

 

impressionist 는 setting이 쉽고 Gem 자체도 상대적으로 가볍다는 점, 모델에 Event 모델을 종속시킬 수 있는 점이 장점인 듯하다.

 

하지만 기능이 상대적으로 부족하고, 동작하는 코드가 명시가 안되어 관리가 불편하다는 점, 처음 모델 생성 시 default로 딸려오는 인덱스가 너무 많다는 점(지우면 되니까 단점이 아닌 것 같기도..) 등이 불편했다.

 


Ahoy_matey

https://github.com/ankane/ahoy

 

ankane/ahoy

Simple, powerful, first-party analytics for Rails. Contribute to ankane/ahoy development by creating an account on GitHub.

github.com

사용법은 간단하다. Gemfile에 추가하고 github에 안내되어 있는 대로 커맨드를 입력하면 Ahoy::Visit 모델과 Ahoy::Event 모델이 생성된다. Ahoy::Visit 모델은 has_many로 Ahoy::Event 모델을 가지고 있게 된다. 

 

Ahoy의 데이터 모델

Ahoy::Visit 데이터는 처음 서버와 통신을 할 때, 생성되며 방문데이터의 개념으로 사용된다. 이 방문데이터는 token을 통해 고유성이 관리되는데, duration 값을 지정해서 이 고유성을 관리할 수 있다. 

 

Ahoy::Event 데이터는 특정 Controller의 특정 Method에 대해서 hook 해서 처리할 수 있다. 어떤 Visitor가 어떤 Event들을 요청했는지 데이터를 쌓고 관리할 수 있다. 

 

빠르고 강력하게 방문객, 이벤트 모델을 만들고 사용할 수 있고 지리정보나 클라이언트 API에 대해서도 정보를 관리할 수 있는 등 강점이 뚜렷했다.

 

하지만, Custom 컬럼을 처리하는 데 너무 많은 Wrapper Method들이 필요해진다는 점이나 명시적으로 어떻게 동작되는지 코드가 없어 관리가 안되는 점, 모델에 종속시키려면 쿼리를 꽤 많이 작성해야 한다는 점(인덱스도 같이 생각해보게 되는..), 딸려오는 Gem들이 있어 무거울 것 같다는 점이 불편했다.


Ps. 써보며 느낀건 Gem이 정말 내가 필요한 기능과 딱 맞는다면 쓰는게 좋겠지만, 일반적으로 그런 경우가 맞지 않을 때가 많은 것 같다. 이번에도 두 Gem 모두 원하는 기능에 딱 맞지 않았다. 그나마 Ahoy보다는 Impressionist가 조금 더 맞는 듯해서 사용했지만, 다음에 비슷한 경우가 있다면 직접 구현할 것 같다. 코드의 관리나 상황에 맞는 최적의 환경(? 로직?)을 세팅할 수 있기에 Gem에 의존하지 않는 서비스 환경을 구성할 수 있을 것 같다.