This message was deleted.

@MARU 먼저 정확하고 깊이 있는 답변을 해주셔서 감사드립니다. 각 서비스들의 기본 설명들을 해석하면서 공부했지만, 언어적 차이 때문에 모호하게 이해했던 점을 확실하게 잡을 수 있었습니다. 감사합니다 😍 [prisma2] 1. 기존 Prisma와 같이 db schema와 resolve 생성 및 관리 => prisma2에서 소개하는 3가지 서비스에 대해서 서로 통합 또는 연동에 대해서 어느정도 가능한지와 퀄리티는 어떤지 확인을 해야겠다는 생각이 드는 답변이였습니다. 독립적으로 지원하는것에 장점은 확실하게 있으나, 나눠진만큼 앞으로의 업데이트를 통해 '어쩔수없는' 연동 불가가 생길 수 있으니깐요. 2. 요청된 Graphql Query에 맞게 db쿼리 재조합 및 1:N관계의 쿼리 요청 최적화 => 설명해주신대로는 진짜 꿈같은 이야기입니다 ㅎㅎ 하나의 큰 서비스는 단일 DB로는 불가능한게 현실이도 서로 통합한다는 것 자체가 이슈 덩어리에 개발요소가 들어갈수밖에 없는 요소인데 이걸 해결해준다는 것에 감격할 수 밖에없네요. 말씀해주신 Photon의 행보를 추척해 나아가겠습니다. 3. 개발되는 서비스 API 서버안에서 Graphql 관련해서 사용되는 느낌. => 답변 해주신거에 hasura와 차이점을 통해 아키텍처 구상에 도움이 되었습니다. 감사합니다. [Hasura] 1. 요청된 Graphql Query에 맞게 db쿼리 재조합 및 1:N관계의 쿼리 요청 최적화 => 최적화에 너무나도 맘에 들고 Main이됬든 Sub가 됬든 하나의 독립적인 서비스를 위한 선택에 대해서는 과감하게 선택할만 한 것 같습니다 ㅎㅎ... (private성 강하게 하려면 Docker로 해야되는것만 빼면...) 2. 개발되는 서비스 API 서버와 별개로 backend, frontend 상관없이 최적의 Query로 data 사용(read,write)을 할 수 있는 서버, 그 외 서비스적 처리(알림전송, 정산금액계산등...)는 microservices단위 개발이 더 효율적 =>설명해주신 6가지의 지원 기능에 대해서 설명해주셔서 감사드립니다. 좀 더 명확한 아키텍터 구상에 도움이 됩니다 ㅠㅠ 제가 serverless 또는 microservies 단위 개발로 넘어가지 못한 이유가 '솔로'개발이기 때문에 개발효율 면에서 큰 이득 을 못가진점을 가장 크게 가졌었는데... 코드의 신뢰성, 데이터의 신뢰성을 어느정도 보장해줄 수 있는 기능이라고 생각되기에 충분한 검토를 해야되겠다는 생각이 드는 설명이였습니다. 다시 한번 질좋은 답변에 감사드립니다. 😀