59P by xguru 4달전 | favorite | 댓글 9개
  • 1년 정도 사용했고, 가능한 모든 프로젝트를 EdgeDB로 바꿨음
  • EdgeDB는 Postgres 위에 만든 Graph/Relational DB
    → 기존 엔진을 그대로 사용했지만, 사용자 측면에선 모든게 바뀜. 가장 큰 변화는 쿼리언어와 도구들(Tooling)

쿼리 언어

  • EdgeDB는 SQL이 없고 자체 언어인 EdgeQL을 사용하는데, 이게 게임체인저임
  • 한번 사용해보니, 다시는 SQL로 돌아가고 싶지 않음
    → 강력한 타입, 객체 지향, 딥쿼리가 엄청 쉬우며, 사람이 데이터를 쿼리하는 사고방식에 잘 매핑 됨(사람들이 JOIN 하는 방식으로 생각하지는 않으니까)
  • 예전에도 SQL의 팬은 아니었지만, 실제로 대체제가 없었음
  • 환상적인 책-스타일의 튜토리얼과 함께 몇 일 배우고 연습하고 나니, DB 스키마 모델링이 재미나고 가벼운 일이라는 걸 알게 되었음
    → SQL의 복잡성이 사라졌고, SQL이 쿼리언어로써 얼마나 비효율적이고 이상한지 알게되었음
  • EdgeQL은 배우기 쉽고, 퀵스타트와 오버뷰 만으로 80% 정도를 익힐 수 있음
  • 나는 EdgeQL이 너무 좋아서, 독립적인 표준이 되었으면 좋겠음. 그래서 예를 들어 파일 기반DB에서 EdgeQL사용이 가능한 EdgeDBLite 같은게 나오면 좋겠음

툴링

  • 바이너리 하나로 모든 것을 실행가능한 요즘 패턴을 따름 (go 나 flutter 같이)
    → 서버 설치 및 업데이트, DB 생성/삭제, REPL, 마이그레이션, 백업 & 프로젝트 관리 등
    → 그리고, 대부분의 경우 "It Just Works"
  • EdgeDB는 DB와 인터랙션 하는 방식을 Reinvent 했음
    → "Project" 컨셉으로 DB와 자동연결하여, DSN이나 설정 상관없이 그냥 동작함
    10년 넘게 localhost 에 root access 권한을 주기 위한 정확한 SQL 커맨드 를 찾아다니던 거랑 비교하면 매우 상쾌함

기능들

  • 엄청 쉬운 many-to-many 관계 모델링
  • 임베디드 GraphQL (프론트엔드에서 직접 연결 가능)
  • Computed 속성 rating := math::mean(.ratings.score)
  • backlinks : 링크를 역순으로 찾아가기
    select User.<author; User가 author 라는 이름의 필드로 연결된 테이블에서 검색
  • uuid, collection, scalar, abstract 및 여러 타입들 (나의 최애는 cal::local_datetime)
  • inheritance, constraints 와 Introspection 같은 무서운 것들

지금까지의 경험

  • 1년 정도 전부터 사용했음. 처음엔 작은 개인 프로젝트를 이관했고, 나중엔 회사의 프로젝트중 하나를 이관
  • 내 작업들 대부분은 소규모의 실용적인 사용자 대응 서비스들이어서, 종종 혼자 담당하면서 가장 적합한 도구를 선택하는 사치스러운 일이 가능했음
  • EdgeDB와 함께하는 동안 대부분은 "It Just Works" 경험이었음
  • 대부분의 것들은 쉽게 찾을 수 있고, 훌륭한 문서를 가지고 있어서 찾기 쉬움(진짜로 내가 본 가장 좋은 문서 사이트중 하나임)

프로덕션에 적합한지 여부

  • 지난 가을부터 "프로덕션에서 사용"중
  • 어떤 사람들은 "프로덕션에서 사용" 한다는 것에 "실제로 이용한다는 것"에 비해 좀 더 의미를 부여하긴 하지만..
  • 커맨드라인 도구가 리팩토링 되면서 자동화 스크립트를 살짝 바꾸긴 했지만, 큰일은 아니었음
  • 마음속으로는 얼리어답터로서의 위험에 대한 대가를 지불한 준비를 하고 있었지만, 지금까지는 문제가 없었음

EdgeQL의 표현력

  • 그동안 SQL에 대해서 구글링하고 ORM 제한과 회피방법들을 찾아다니던 것에서 해방되었음
  • EdgeQL은 내가 DB에서 찾고 싶은 것들만 딱 표현할 수 있고, 실제로 읽어서 이해할 수 있음 (다른 개발자도)
  • 종종 EdgeQL 때문에 트랜잭션도 피할수 있음. 싱글쿼리 안에서 다중 중첩 업데이트도 가능함.
    → "Simplicity is complicated"

Migrations

  • 가장 멋진 것중 하나는 마이그레이션 기능이 내장되어있다는 것
  • 스키마를 변경하고 edgedb migration create를 호출하면 마이그레이션 파일이 생성되고,
    서버에서 edgedb migration apply만 하면 바로 적용 됨
  • 마이그레이션 들은 해쉬로 연결되기 때문에, 랜덤으로 하나만 적용해서 모든걸 깨먹을 일이 없음
  • 새로운 마이그레이션 생성시 기본값은 인터랙티브여서, 커맨드라인에서 모든 변경을 컨펌 받음

성능

  • 나는 큰 사이즈의 데이터를 처리하는게 아니기 때문에, 고성능의 DB가 필요하지는 않음
  • 하지만 하단에 Postgres를 이용하고 있어서 다른 DB에 비해서 성능상 문제가 되지 않음
  • EdgeDB 자체는 Python으로 작성되어 있음(Go라면 좋았겠지만, 개발자들이 Python에 더 익숙한 듯)

Go 클라이언트 라이브러리

  • 내가 Go를 사용하기 때문에 EdgeQL용 네이티브 Go 라이브러리가 있는 것이 좋았음
  • Typescript/Javascript, Python, Go 용 공식 라이브러리가 있고, .Net 과 Elixir 는 커뮤니티가 지원

업그레이드

  • EdgeDB는 서버의 버전과 업데이트에 대한 복잡성들을 추상화함
  • EdgeDB CLI가 기본적으로 알아서 처리. 새 업데이트가 있으면 보여주고 업그레이드 함.
    → 의심스러울 정도로 부드러움
  • 현재는 2.0 RC가 나왔지만, 전혀 걱정이 되지 않음. 지금까지의 경험들이 안전하고 쉬울거라고 믿게함

커뮤니케이션과 지원

  • 얼리어답터로서 공식 EdgeDB 채널에서 엄청 빠른 답변과 도움을 받고 있는 것에 만족

EdgeDB 2.0

  • 내일 릴리즈되는 2.0 에서는 좋은 기능들이 추가됨
    • EdgeDB UI : 비쥬얼 스키마 편집기, REPL 등이 포함된 웹앱
    • 그룹 쿼리, 글로벌 스키마 변수, 객체 단위 보안, Direct EdgeQL over HTTP 등

내가 싫어하거나 걱정하는 것

  • 호환성에 대한 약속
    • 지금까진 다 좋았음. 호환성을 깨지 않는 마이너 업데이트들
    • 호환성에 대한 약속을 해주면(commitment) 좋을 것 같음
  • 늘어나는 기능 셋
    • 이미 내가 원하는 것보다 많은 기능들이 있지만, 점점 늘어나는 중
    • EdgeQL이 강력해 질수록, DB와 서버간의 경계를 흐리게 하면서 "이거 백엔드에 들어가야 하나, 아니면 똑똑한 DB스키마에 넣어야 하나" 고민하게 됨
    • 임베디드 HTTP 서버를 사용해서, 대부분 프로젝트에서 백엔드 서버를 완전히 대체하는 방향으로 푸시하는게 합리적으로 보이지만.. 이 멋진 쿼리언어와 엔진을 갖춘 안정적인 DB를 가지고 싶음
  • 아무튼, EdgeDB가 안정적이고 일관적이면서, 기능이 너무 많이 늘어나지 않기를 바람. 현재 기능세트로도 훌륭

결론

  • 난 앞으로의 프로젝트에선 기존 RDB는 고려할 생각이 없음
  • SQL로 돌아가는 것은 Flutter 에서 Ncurses로 가거나, Go에서 어셈블리 언어로 돌아가는 것과 마찬가지임
  • 나에겐, EdgeDB가 지난 20년간 DB 분야에서 가장 큰 발전임.
  • 앞으로 더 많은 경험을 하면 바뀔수도 있겠지만, 1년 넘게 사용하면서 이 기쁨을 해치는 일이 아무것도 없었음
  • 사용하면 할수록 EdgeDB를 신뢰하게 됨
  • EdgeDB 팀이 EdgeDB 자체와 언어,웹사이트,도구,커뮤니티를 만드는 일등에 한 모든 것들이 엄청 인상적임
    → "Mad respect to the team"
  • 그리고 그들은 이제 겨우 워밍업 한 것 같음

엄청난 칭찬이네요. 7/28 오전 10시(PT)에 2.0을 발표한다고 합니다.

EdgeDB 1.0 릴리즈
EdgeDB - 개발자를 위한 차세대 오픈소스 ORDB

prisma와 비슷한 길을 가는걸로 보이네요. prisma 잘 쓰고 있지만 퍼포먼스 면에서 아쉬운 점이 많은데 벤치마크 결과가 약간 땡기는데요?
문법은 별로 제 스타일이 아니지만..(protobuf도 쓰고있는데 컨버전 샘플코드 또한 좀...)

다른 분들은 이렇게 graphQL 같은 문법을 선호하시나요? 저는 결국 뒷단은 RDS니 중간에 컨버전을 해줄텐데 그게 명확하게 드러나지 않으면 좀 꺼리는 편이라..

이 게시물을 보고 흥미가 생겨서 계속 공부중입니다.
그런데 아직 초기라 그런지 막히는 부분이 생기면 검색 결과가 많이 나오질 않네요.
디스코드 채널이 있긴 한데 국내 개발자분들 편하게 질문/답변하면 좋을 것 같아서 오픈 채팅방을 하나 만들었습니다.
https://open.kakao.com/o/gtGY0Gve

저도 사용해보고 싶어서 메모해 놨습니다.

이 글 보고서 튜토리얼 완주하고 나니 더욱더 설득이 되네요.

흥미롭네요. SQL 없는 세상으로 돌아갈 수 없다니..

관심이가네요

인상적입니다!

graphdb 류에서는 ArangoDB 를 관심있게 보고있었는데, EdgeDB 도 한번 살펴봐야겠어요