현행 차단기능은 브라우저에서 차단목록을 조회한 후에 조회된 목록을 삭제해주고 있기 때문에 깜빡하고 노출이 되었다가 빈칸으로 변경되고 있습니다.
차단기능은 상호 차단이 아니라 차단당한 사람은 사람은 차단당한 사실을 알 수 없고 자신을 차단한 사람에게 댓글을 달거나 차단자가 자신에게 댓글을 다는 불편한 상황이 생기기도 합니다.
따라서 현행 차단기능은 불완전한 차단으로 인해 사용자에게 불편한 경험을 제공하고 있다고 생각하며 개편요구를 하고싶습니다.
하지만 저 혼자서 하는 개편요구에 힘이 실리지 않을것이라 생각하여 같은 불편함을 공유하시는 분들에게 개편요구 화력지원을 부탁드립니다.
개편요구의 핵심은 아래와 같습니다.
1. 브라우저에서 이루어지는 차단을 서버에서 처리하도록 변경할 것
2. 상호차단기능을 구현하고 이 역시 서버에서 처리하고도록 할 것
이 외의 개인적으로 불편사항이 있으시다면 이를 추가하여 루리웹 공식 창구인 ruli@ruliweb.com 으로 메일을 보내주시면 됩니다.
긴 글 봐주셔서 감사합니다.
그리고 차단 인원좀 늘려주세요..
서버에서 차단하게 하면 느려지는 거 아닌가? 차단한 놈이 나한테 댓글 달건 말건 알 바 아니라 두 번째는 왜 필요한 건지 모르겠고
차단기능 개편도 개편인데 차단 목록 제한 좀 늘려주면 좋겠음 하도 정떡1충 혐오1충 차단하니까 차단 목록이 수시로 꽉 차게 되더라
자작기타도 베스트 갈수 있을지 모르는데 일단 탭은 변경하였습니다.
서버 차단은 각 사용자가 게시물 요청할때마다 DB쿼리를 새로 날려야 하기 때문에, 서버측 부담이 커지게 되어서, 게시판형 커뮤니티 사이트가 클라이언트 차단으로 가는 이유이긴 하지. 게시판 커뮤니티가 서버에서 차단 적용한 DB쿼리 날리는 경우는 못 본 듯?
크롬에서 루리웹익스텐션 설치하면, 차단대상 깜빡이면서 보이는 현상 없어질 거예요.
서버에서 차단을 처리했을 때의 가장 큰 장점은 차단 대상이 페이지에 등장했을 때, 목록 아이템 숫자가 줄어드는 현상이 없어진다는 것인데, 이건 결국 매 페이지 조회를 각 사용자에게 맞춘 커스텀 DB쿼리를 날려야 한다는 것과 같고, (매 페이지가 검색결과인 것처럼) DB 부하 줄이려고, 각 페이지 목록까지 캐시에 넣으며 용쓰는 게시판 커뮤니티들이, 사용자 숫자만큼 쿼리요청을 허용할 가능성은 DB부하가 늘어나기 때문에 가능성이 매우 낮죠. 비용이 증가하니까요. 그래서 실제 적용하고 있는 곳도 없고..
많은 사람들의 도움이 필요한 거라면 탭 바꿔서 베스트에 올리는게 좋지 않을까?
자작기타도 베스트 갈수 있을지 모르는데 일단 탭은 변경하였습니다.
차단 궁금하면 클릭
차단기능 개편도 개편인데 차단 목록 제한 좀 늘려주면 좋겠음 하도 정떡1충 혐오1충 차단하니까 차단 목록이 수시로 꽉 차게 되더라
그리고 차단 인원좀 늘려주세요..
차단자가 자기 글 댓글 막는건 악용 요지가 있어어 안하는게 나을걸 악질 분탕이 싹다 차단 걸어서 자기 글에 댓글 못달게 할수도잇을건데
실제로 인벤에서 일어났던 일 ㅋㅋ 어그로가 더 신나게 사용해서, 인벤이 그 기능을 다시 철회했지..
차단 목록만 늘려주세요 아니면 적어도 차단 목록에서 아이디 클릭하면 그 유저 마이피로 넘어가게 해서 탈퇴한 계정인지 아닌지 확인할 수 있게 해주던가 차단한 사람이 내가 차단했다는걸 알게 해줄 필요는 있는지 모르겠음
댓글로 오해의 소지가 있어서 추가합니다. 차단 사실을 알려주자는것이 아니라 상호 차단을 선택적으로 구현하여 서로 조회되지 않도록 하는것입니다.
서버에서 차단하게 하면 느려지는 거 아닌가? 차단한 놈이 나한테 댓글 달건 말건 알 바 아니라 두 번째는 왜 필요한 건지 모르겠고
슈퍼아르헨틴백브레이커
서버 차단은 각 사용자가 게시물 요청할때마다 DB쿼리를 새로 날려야 하기 때문에, 서버측 부담이 커지게 되어서, 게시판형 커뮤니티 사이트가 클라이언트 차단으로 가는 이유이긴 하지. 게시판 커뮤니티가 서버에서 차단 적용한 DB쿼리 날리는 경우는 못 본 듯?
애초에 조회할때 한번 차단목록 조회 한번을 더 하고 차단대상을 삭제하기 때문에 서버에서 처리하나 클라이언트에서 한번 하나 부담은 크게 다르지 않습니다.
안드로스
서버에서 차단을 처리했을 때의 가장 큰 장점은 차단 대상이 페이지에 등장했을 때, 목록 아이템 숫자가 줄어드는 현상이 없어진다는 것인데, 이건 결국 매 페이지 조회를 각 사용자에게 맞춘 커스텀 DB쿼리를 날려야 한다는 것과 같고, (매 페이지가 검색결과인 것처럼) DB 부하 줄이려고, 각 페이지 목록까지 캐시에 넣으며 용쓰는 게시판 커뮤니티들이, 사용자 숫자만큼 쿼리요청을 허용할 가능성은 DB부하가 늘어나기 때문에 가능성이 매우 낮죠. 비용이 증가하니까요. 그래서 실제 적용하고 있는 곳도 없고..
실시간으로 갱신되는 게시판형태에서 캐싱을 한다구요? 메뉴나 베스트 처럼 갱신이 잦지 않은 형태에서는 가능하지만 게시판에서 캐싱을 사용한다는건 오히려 복잡도만 높아지고 실제 부하 개선에는 크게 효과가 없을걸로 생각되는데 제가 지식이 부족해서 잘 모르는걸지도 모르겠네요 현행 차단목록를 캐시로 넣어놓고 호출하지 않는 형태라면 모를까 캐시가 아니라면 차단 목록 테이블을 추가 join함으로서 오히려 2번 호출을 막아서 부하가 덜어질걸로 생각됩니다. 실제로 적용을 해본건 아니고 구조를 열어봐야 알겠지만 현행 루리웹에서는 부담만 되는 구조는 아니라고 판단하여 건의드려보려합니다. 개선요구가 많이 들어가도 이득이 없다는 답변을 받는다면 그냥 납득하고 이용하려고 하긴하지만 일단 개선요구는 해보고 싶네요
클라이언트 차단 구현이 차단목록을 매번 조회하는 걸로 가정을 하고 이야기를 꺼내신 것 같은데.. 커뮤니티 사이트들이 즐겨 사용하는 클라이언트 차단은 차단목록을 매번 요청하지 않습니다. 차단 정보는 다 클라이언트가 캐시해 놓으니까요. 그리고 서버에서 차단 목록 테이블을 join한다는 것은 커스텀 쿼리가 아닌, 통상적으로 나오는 리스트에 필터링을 가하는 방식을 하자고 하는 것 같은데... 사실 이건 지금 클라이언트 차단과 비교했을 때, 큰 장점이 있다고 보기엔 어렵죠. 현 클라이언트 처리처런, 결국 차단자가 있으면 목록이 줄어드니까요. 사실 지금 차단글이 깜빡거리면서 보이는 현상은 클라이언트 차단 방식의 단점이라고 100% 단정짓기엔 애매한 게, 분명 원인은 클라이언트 차단이 맞지만, 더 정확히 말하자면, '클라이언트 차단 구현을 깜빡거리게 만든 것'이 원인일 뿐이고, 클라이언트 차단도 안 깜빡거리게 충분히 만들 수 있죠. 다만 루리웹의 방식이 유독 느린 것 뿐... 여튼 커뮤니티 사이트는 DB쿼리 줄이는 것에 매우 민감하기 때문에 (이거 설계 잘못했다가 주기적으로 사이트 터져서 고생한 곳도 있고, 결국 여기도 게시물 목록 캐싱하는 방식 도입하더군요. 몇 초 단위로 끊어주기만 해도, 트래픽 갑자기 미친듯이 몰리는 타이밍에 도움이 되니), 루리웹이 바뀌는 건 아마도 어려울 듯...
확인해보니 차단목록자체는 로컬스토리지에 넣어놓는걸로 보이고 차단목록 접속하면 그때 한번 갱신하네요. DB쿼리 손대라는 요구는 현재 2번 호출이 아니니 손대긴 무리같고 서버에서 처리하는 방식은 받아들이기 힘들것 같네요. 사실 찾을라면 찾지만 복잡도가 올라가니 쉽게 요구하긴 힘들 것 같고... 안되면 클라이언트에서 처리하더라도 상호차단은 넣어 달라고 요청하고 싶은데 이건 이거대로 성능문제가 될 수 있어 보여서 답답하네요. 말씀하신것처럼 깜빡이는것 자체의 문제는 게시물 목록 뿌려주기 전에 클라이언트에서 필터링 하지 않는게 문제긴 합니다. 그냥 대대적으로 손보면 사이드이펙 날까봐 끼워넣은것 같아요. 어떤 요구를 어떻게 해야할지 되짚어보는 기회를 주셔서 감사합니다. 뭐... 그래도 일단 요구는 해보고 까이면 다시 개선해서 다시 개편요구 해보려구요. 좋은 의견 주셔서 정말 감사합니다.
안드로스
크롬에서 루리웹익스텐션 설치하면, 차단대상 깜빡이면서 보이는 현상 없어질 거예요.
사실 빈칸보이는 거랑 차단자가 댓글다는게 거슬리는게 커서요. 모바일 문제도 있고 이래저래 사이트 자체기능으로 지원해줬으면 하는게 크긴합니다. 갑자기 그게 안되고 있으니 익스텐션같은게 나왔겠지 싶긴하네요...