This message was deleted.

혹시 혼자 개발하시나용? 팀 상황은 어떠한가요?

@Hyeseong Kim 님 안녕하세요! 항상 좋은 아티클들 공유해주셔서 감사합니다. 덕분에 매일 많이 배워갑니다. 우선은 질문 주신거에 답변을 드려보겠습니다. • 혹시 혼자 개발하시나용? 팀 상황은 어떠한가요? 기존에 셋업해두셨던 개발자분이 계셨는데 최근에 퇴사해서 지금은 혼자서 개발업무를 맡고 있습니다. 현재 디자이너와 개발자를 추가채용중에 있으며, 기획, 디자인 개발은 거의 혼자 하고 있다고 보시면 됩니다! 서비스는 총 3개가 있고, 1개는 prisma2 나머지 2개는 prisma1으로 개발이 되었으며, 처음 셋업 당시보다 사용자나 매출이 10배 이상 증가하면서부터 prisma1에서 여러가지 문제들이 발생했고, github issue라던가 문의 해보았는데 prisma1에 고질적인 문제라고 듣고, prisma2를 사용하라는 이야기만 들은 상태입니다. 신사업팀이다보니 빠른 검증 후 계속할지 아닐지가 중요하여 각 서비스마다 서버, DB 등 모두 각각 생성되어있으며, 마침 어느정도 검증이 되어 서비스3개에 대하여 통합하기로 협의가 되었고, 모든 구조를 제로베이스에서부터 다시 쌓아올리게 되었습니다. 그러면서 기존에 prisma1이 갖고 있던 문제도 이참에 해결하려고 하는데 가장 큰 문제는 리소스가 너무 없다보니 prisma2가 가장 나을 것 같다는 판단은 하였지만, 또 다른 이슈들이 있는가 싶어서 이렇게 질문을 드렸습니다! • 겪으신 문제, 풀어야하는 문제, 만드는 제품 종류, 팀 상황 등등에 따라 필요한 내용이 달라질 것 같아서... 가능하면 케이스를 조금만 더 구체적으로 소개해주시면 좋을것가탕요 팀 상황은 위 내용으로 충분히 전달이 될 것 같다고 생각되어, 말씀주신 다른 부분에 대해서 적겠습니다. 만드는 제품은 3개 서비스 모두 이커머스 관련 개발을 진행하고 있으며, 상시몰과 폐쇄몰 기반으로 개발되어가고 있습니다. prisma1을 사용하면서 겪었던 문제 중 대표적으로는 아래와 같은 사례들이 있는 것 같습니다. 1. schema 추가나 변경등으로 prisma deploy 시 반영이 되지 않아 새로운 이름으로 db를 생성하고, deploy한 후 기존 db를 dump해서 마이그레이션해야하는 문제 2. 정산이나 통계자료 처럼 쿼리가 복잡하고 데이터양이 많아지면 문제가 발생하며, 쿼리튜닝이나 서버 스케일업, 서버에서 메모리와 관련된 설정을 수정하더라도 계속해서 이러한 에러가 발생합니다.

java.util.concurrent.RejectedExecutionException: Task slick.basic.BasicBackend$DatabaseDef$$anon$3@34f239f rejected from slick.util.AsyncExecutor$$anon$1$$anon$2@7bf7de3f[Running, pool size = 9, active threads = 9, queued tasks = 1000, completed tasks = 1294690]

위 내용에 대해서는 prisma1에서 문제를 해결하지 않고, 이러한 문제들을 해결한 부분이 prisma2에 진행되었다고 하여 prisma2를 이용하라고 했습니다. • GraphQL 이라기 보단 GraphQL과 잘 어울리는 ORM에 대한 질문이라고 생각되는데 의도하신게 맞을까요? 넵 ORM과 같은 graphQL을 더 잘 사용하기 위한 구성에 대한 질문이 더 맞는 것 같습니다. 내용에 적어둔 것 처럼 prisma2를 바로 사용하기에는 아직 많은 정보가 없어서요.ㅠㅠ

일단 생각나는 의견으로는 • Prisma 1은 Scala Sangria 기반으로 되있었던지라 빠르게 기능 제공할 수 있었지만 반대로 구성 문제가 생기거나 혼자 못고치는 부분이 많았어요. Prisma 2는 이 부분 많이 개선하고 지금은 Prisma 1 기능도 거의 다 따라잡은걸로 보입니다. • 문제가 됐던 마이그레이션은 스키마를 기반으로 하는 "선언적 마이그레이션" 전략인데 Prisma 2에서도 아직 개발중입니다. 일단 그냥 다른 여타 프레임워크들 하듯 별도의 마이그레이션 도구를 사용하도록 가이드 하고 있어요. (Prisma 클라이언트를 그대로 써도 되기 때문에 기능개발하듯이 수월하긴 할거에요) • 거의 혼자 개발하시게된 상황만 놓고보면 서비스들 통합하는건 좋은 선택일 것 같아요. • 다만 ORM의 경우 어느쪽이던 의견이나 문제점들이 있는 상황은 피할 수 없을 것 같아요. 저는 반대로 백엔드에 레거시 TypeORM 코드들 때문에 골치아픈 상황이 있는데, 이거 보면서 느낀점은 이 부분은 아키텍처 수준에서 정리하고 시작할 필요가 있다는 것입니다. 전통적인 접근방식으로요 • Prisma 던 TypeORM이던 Sequelize 던 서비스 인터페이스 정의 뒤로 가려서 추상화에 의존하도록 하고 의존성 주입 패턴을 적극 활용하는게 좋을 것 같습니다. TypeORM 에 싱글톤 인스턴스 그대로 import 해서 쓰거나 Prisma 클라이언트 그대로 컨텍스트에서 그대로 빼다 쓰기 편하긴 했는데 나중에 돌아보면 다 패착이였던 것 같아요. • 정돈만 잘되면 이상적으로는 어떤 ORM을 의존하던지 GraphQL 서버 쪽은 상관없게 됩니다. 완벽한 ORM을 고르는 것 보단 완벽하지 않은 ORM 골라놓더라도 변경이 필요할 때 API나 비즈니스 코드에 영향이 없도록 하는게 중요한 것 같아요. 일단 저도 프론트엔드 위주로 개발하고 있고 ORM들을 헤비하게 써보질 않아서 답변드리기 좀 애매한데.. 다른 분들도 보시고 답변주시거나 실사용 후기를 던져주시면 좋을 것 같습니다.

좋은 답변 감사합니다. 아무래도 팀빌딩부터 기술스택까지 지금은 빠르게 진행이 필요로 했지만 이제는 어느정도 검증이 끝났고 속도는 조금 늦추더라도 안정적인 방향성을 검토해보려고 하다보니 혼자만의 생각보다는 다른 분들 의견이 많이 궁금했었습니다 ㅎㅎ