정확히는 프론트 따로 백 따로 있는 서비스에 Django로 백서버를 구현할 경우 백사이드만 쓰기엔 Django 특유의 풀스택스러움에서 오는 덩치가 부담스러운 것도 있었고, Django에 RESTful함을 더하기 위해 같이 사용한 DRF에 너무 큰 의존성을 갖게 되는 게 불쾌했습니다..
특히 DRF 자체가 Django ORM에 강하게 엮여있는 것에서 오는 종속성과 DRF를 자주, 많은 곳에 사용할수록 아무 곳에서나 DjangoORM을 사용할 수 있게 되면서 오는 파편화, DB 접근 가능성 등이 불안함으로 다가오는 점, DRF에서 제공하는 serializer가 이름 그대로의 데이터 직렬화, 데이터 검증 그 이상으로의 역할과 가능성을 갖고 있는 것에 더해 serializer를 쓰면 쓸 수록 점점 MVC의 구분이 무의미해지는 것 등등.. 이럴 거면 굳이 Django+DRF 조합을 쓸 게 아니라 다른 프레임워크로 백단 구현하는 게 더 안정적이겠다 싶은 생각이 많이 들었었죠. 그래서 실제로 어느 순간부터는 FastAPI를 우선 선택하게 되었네요.
정확히는 프론트 따로 백 따로 있는 서비스에 Django로 백서버를 구현할 경우 백사이드만 쓰기엔 Django 특유의 풀스택스러움에서 오는 덩치가 부담스러운 것도 있었고, Django에 RESTful함을 더하기 위해 같이 사용한 DRF에 너무 큰 의존성을 갖게 되는 게 불쾌했습니다..
특히 DRF 자체가 Django ORM에 강하게 엮여있는 것에서 오는 종속성과 DRF를 자주, 많은 곳에 사용할수록 아무 곳에서나 DjangoORM을 사용할 수 있게 되면서 오는 파편화, DB 접근 가능성 등이 불안함으로 다가오는 점, DRF에서 제공하는 serializer가 이름 그대로의 데이터 직렬화, 데이터 검증 그 이상으로의 역할과 가능성을 갖고 있는 것에 더해 serializer를 쓰면 쓸 수록 점점 MVC의 구분이 무의미해지는 것 등등.. 이럴 거면 굳이 Django+DRF 조합을 쓸 게 아니라 다른 프레임워크로 백단 구현하는 게 더 안정적이겠다 싶은 생각이 많이 들었었죠. 그래서 실제로 어느 순간부터는 FastAPI를 우선 선택하게 되었네요.