2025년 2학기 운영을 앞두고, 어드민 기능 보완 작업을 진행합니다.
최근, 크롤러에는 크롤링하는 역할만 부여하고 그 외 다른 비즈니스 로직들은 allcll-backend로 옮기는 방향으로 논의되었습니다.
allcll-backend로 옮기는 의도는 다음과 같습니다.
- 유지보수가 용이합니다.
- 크롤러는 서브 모듈로 관리되고 있습니다. 따라서, 크롤러의 변경 범위를 최소화 한다면 유지보수가 용이해집니다. 현재 개발 진행 시, 항상 서브 모듈의 변경 사항을 가져와서 작업하고 있습니다. 하지만, 변경 가능성이 높은 크롤링 외 비즈니스 로직들을 allcll-backend로 옮기게 된다면, 서브 모듈에서 작업 -> 메인 모듈에서 변경 사항을 가져와서 작업하는 프로세스가 한 단계 줄어듭니다.
- 테스트 코드의 부재입니다.
- 크롤러에는 테스트 코드가 없습니다. 하지만, allcll-backend에는 테스트 코드 작성이 의무화 되어있기 때문에 테스트 코드를 작성하여 보다 안정적인 서비스를 이어나갈 수 있습니다.
하지만, 우려 사항이 있습니다.
- 한 번에 많은 클래스를 옮기게 된다면 휴먼 에러로 인해 제대로 동작하지 않을 수 있습니다.
- 실제로, subject나 seat 관련 api의 경우 생각보다 많은 클래스들이 결합되어 있습니다. 이는 휴먼 에러를 유발할 가능성이 있습니다.
- 기존 크롤러 코드는 private으로 설정되어 있어, 민감한 정보가 노출되지 않습니다. 하지만, 크롤링을 제외한 나머지 비즈니스 로직 및 클래스들을 옮기면 민감한 정보가 노출될 위험이 있다고 생각합니다. ex) 인증 정보 세팅 api의 경우, 해당 필드값이 노출됨.
- 관리 측면에서도 생각해봅시다. allcll-backend와 allcll-crawler의 클래스들이 합쳐졌을 때 한 패키지에 너무 많은 클래스가 존재해 오히려 유지보수하기 힘들어질 수 있습니다. 하지만 이는 패키지 분리로 해결 가능하다고 생각합니다.
이러한 컨텍스트에 따라, 생각한 어드민 API 구현 방안은 총 세가지입니다.
- 크롤러 의존도를 신경 쓰지 않고 api만 백엔드로 가져와서 구현합니다.
- 이 방법은 안전하다는 장점이 있지만 크롤러 의존성이 강해, 추후 리팩토링이 필요합니다.
- 어드민 페이지에 필요한 기능 중, 크롤러를 건드리는 로직은 크롤러에 유지하고 백엔드를 건드려야 하는 api는 백엔드로 옮깁니다.
- 즉, 크롤러를 건드리는 api는 해당 api만 가져와서 작업합니다. 백엔드를 건드려야 하는 api는 백엔드에서 작업합니다.
- 크롤러 의존도를 최소화 하고자, 크롤링 하는 로직 외 비즈니스 로직은 다 백엔드에 옮겨서 작업합니다.
크롤러 의존도를 최소화 하는 3번 방안이 제일 끌렸지만, 오늘 코드를 분석해보며 구상한 결과 변경 범위가 생각보다 많아 <클래스 이동 작업 + 검증 + 프론트와 연동>까지 시간적 여유가 부족하다고 판단했습니다.
운영의 편의성도 물론 중요하지만 기능이 정상적으로 동작하는 것이 최우선이기 때문에 안정적으로 단계적인 방법을 선택했습니다.
1번을 빠르게 시행 후 검증 -> 시간적 여유가 남을 시에 3번 방향으로 진행하는 게 좋을 것 같아요.
이에 대해 의견주시면 감사하겠습니다!
크롤러 api 중
변경 범위가 적은 인증 정보, 학과 도메인의 경우, 3번 방향으로 시도해보겠습니다!
변경 범위가 많은 과목, 여석 도메인의 경우, 1번 -> 3번으로 진행하도록 하겠습니다!
2025년 2학기 운영을 앞두고, 어드민 기능 보완 작업을 진행합니다.
최근, 크롤러에는 크롤링하는 역할만 부여하고 그 외 다른 비즈니스 로직들은 allcll-backend로 옮기는 방향으로 논의되었습니다.
allcll-backend로 옮기는 의도는 다음과 같습니다.
하지만,
우려 사항이 있습니다.이러한 컨텍스트에 따라, 생각한 어드민 API 구현 방안은 총 세가지입니다.
크롤러 의존도를 최소화 하는 3번 방안이 제일 끌렸지만, 오늘 코드를 분석해보며 구상한 결과 변경 범위가 생각보다 많아 <클래스 이동 작업 + 검증 + 프론트와 연동>까지 시간적 여유가 부족하다고 판단했습니다.
운영의 편의성도 물론 중요하지만 기능이 정상적으로 동작하는 것이 최우선이기 때문에 안정적으로 단계적인 방법을 선택했습니다.
1번을 빠르게 시행 후 검증 -> 시간적 여유가 남을 시에 3번 방향으로 진행하는 게 좋을 것 같아요.
이에 대해 의견주시면 감사하겠습니다!
크롤러 api 중
변경 범위가 적은 인증 정보, 학과 도메인의 경우, 3번 방향으로 시도해보겠습니다!
변경 범위가 많은 과목, 여석 도메인의 경우, 1번 -> 3번으로 진행하도록 하겠습니다!