Вітаю всіх, мене звуть Алекс, це Ден. Ось ми тут у куточку. Сьогодні ми розповімо вам про Drizzle. Drizzle - це дощ, мої улюблені погодні умови. Та за щасливим збігом обставин, Drizzle - це ще один з найпопулярніших TypeScript-фреймворків на ринку. У нас вже 15 тисяч зірок на GitHub та 18 тисяч аудиторії у Twitter та Discord. Завітайте до нас, тут надзвичайно дешево. Дуже зручно та затишно. Шановні люди з State of Database провели опитування у 2023 році. Та Drizzle - це топ-2 ORM за всіма категоріями. Вони це підтвердили. Drizzle розробляється трьома чудовими хлопцями. Зліва - це Ендрю. Ось він там. Справа - це Ден. А посередині - це я. Ми обожнюємо SQL. Він надійний. SQL стає тільки кращим і кращим. З іншого боку, TypeScript має одну з найпотужніших систем типів, яка дозволяє нам - інструментаторам робити найпотужніші інструменти, які використовують розробники, тобто ви. Тому TypeScript та SQL - це любов. Це повага, яку ви маєте у своїй системі.

Деякі люди стверджують, що Drizzle - це не ORM, але це помилкова думка, що ґрунтується на застарілому стереотипі. Люди звикли вважати ORM Django або Springs Hibernate. Ми вважаємо, що це Data Framework. ORM, за визначенням, - це Object-Relational Mappers. Як ви бачите, Drizzle - це дуже Object-Relational, маппінгова бібліотека. Ось це моє улюблене та абсолютно правдиве твердження. Drizzle почався як тонкий шар поверх SQL, щоб ви мали мінімальний поріг входу з урахуванням ваших існуючих знань SQL. Отже, що таке Drizzle насправді?

Ми зазвичай називаємо його... Headless... Безголовий ORM з головою. Звучить цікаво, давайте розберемося. Так чому безголовий? Drizzle - це просто SQL, але краще. Ми надаємо вам типізований SQL і дозволяємо вам будувати свої бекенди так, як ви хочете. Ми не втручаємось у вашу архітектуру. Ми єдині, хто побудований з урахуванням різних діалектів. І в цьому сенсі Drizzle дуже не dry, тому що ми постійно повторюємо себе. Але це дозволяє нам швидко ітегрувати, додавати інші діалекти, а вам насолоджуватись діалект-специфічними речами, такими як views, schemas, lateral joints і так далі. Без жодних компромісів.

Drizzle працює з будь-якими базами даних, з будь-якими безсерверними драйверами і живе на краю. Drizzle швидкий. Ну, майже так. Справа в тому, що Drizzle не швидкий, але SQL швидкий. А Drizzle просто не сповільнює ваш SQL. Крім того, ми єдині, хто використовує API підготовлених запитів. І це робить речі ще швидшими для вас. Гаразд, все це добре, але де ж голова? У Drizzle є управління схемами та інтерфейс командного рядка, який автоматизує для вас міграції. У нас є реляційні запити. У нас є Drizzle Studio. І різноманітні розширення. А зараз Ден розповість вам про технічні особливості Drizzle.

Отже, давайте розглянемо знаки, які відрізняють Drizzle від інших ORM та query builders. По-перше, Drizzle був розроблений в першу чергу для використання з TypeScript. Він повністю написаний на TypeScript і використовується лише TypeScript. Отже, всі ваші колонки, таблиці та запити - це просто код TypeScript. Це означає, що вам не потрібно вчити нові DSL або синтаксиси. Ви просто пишете на TypeScript. Також ви можете помітити, що API для опису таблиць дуже схожий на те, як таблиці створюються в SQL. І це не випадковість. Використовуючи API, яке нагадує SQL, ви зможете застосовувати своє знання SQL у використанні ORM. Це евентуально дозволяє вам використовувати своє знання без зайвих абстракцій, які накладають інші ORM.

Наша філософія полягає в тому, що SQL - це потужний інструмент, і його не потрібно абстрагувати. Навпаки, його треба вивчати, використовувати і любити. Тому API Drizzle розроблено так, що, знаючи SQL, ви автоматично знаєте, як використовувати Drizzle. Також важливою рисою Drizzle є TypeScript як Source of Truth. Це означає, що вам потрібно описати ваші таблиці та колонки лише один раз. Все інше автоматично виводиться з цієї схеми. Це стосується не лише типів для запитів, але й міграцій.

Щодо міграцій, DrizzleKit, наша утиліта, допомагає автоматизувати їх створення. Вона генерує міграції на основі змін у вашій схемі. При цьому, ви можете змінювати схему, а DrizzleKit самостійно визначить, які зміни потрібно застосувати на базу даних, з урахуванням вашого відгуку. Наша команда також працює над зручним підходом до синхронізації схеми в коді та стану бази даних. За допомогою команди DrizzleKit Push ви можете автоматично застосовувати зміни у схемі на базу даних без генерації окремих міграцій.

Цей підхід особливо зручний для локальної розробки, де ви можете швидко вносити зміни у схему та одразу ж їх застосовувати. При цьому, для більшої безпеки, ви все одно можете створити міграцію, щоб вона відображала всі зміни, зроблені під час розробки, і застосувати її в продакшн. Але це не дуже гарна ідея, бо це щось на кшталт руками лізти в production базу та щось в ній змінювати. Технічно це, звичайно, можливо, але потім тих літ дізнається і по рукам вам надає. І навіть якщо ви все ж таки вирішили застосувати push на production базу, DrizzleKit вас попередить, якщо в результаті цих дій буде щось видалене. Чи це якась колонка. Чи може потенційно зникнути якісь дані.

Отже, ніяких раптових змін не відбудеться. Але ми всі знаємо, як розробники бачать питання так чи ні і одразу тиснуть так, навіть не дочитавши, що в них питають. Отже, ми розглянули декларацію схеми, розглянули міграції. Тепер давайте поговоримо про найголовніше. Як, власне, писати квері в базу. Власне, так само, як описувати таблиці. Ви просто згадуєте, як би ви написали квері на SQL і пишете її на TypeScript. Наприклад, розглянемо квері. Вона обирає з бази юзернейми перших п'яти користувачів, які були створені цього року, та повертає їх відсортованими по даті створіння. Достатньо базова, проста кверя. Ось як вона виглядатиме в Drizzle. Майже таке саме API. І найважливіше, це правильно типізований результат. Так як ми пам'ятаємо, що у нас все в TypeScript. І в результаті, в типі результату буде рівно одна колонка, яку ми самі обирали.

Обирати записи з однієї таблиці. Це, звичайно, добре. Але ми знаємо, що SQL — це, в першу чергу, реляційні бази даних. Та дуже часто use case — це обрати дані з декількох зав'язаних таблиць одночасно. Для чого в SQL є joiner? Drizzle, звичайно, має першокласну підтримку джойнерів. І ми витратили дуже багато часу, щоб розробити для них найкращий DX, балансуючи між Type Safety та гнучкістю API. Наприклад, нам потрібно обрати юзерів і до кожного юзера додати інформацію його профілю. І припустимо, що нам потрібно, що у юзера може бути або не бути профілю, але нам все одно потрібні всі юзери, навіть ті, у яких немає профілю. Тобто нам потрібен left join. І тепер знову ж таки порівняємо це з query на Drizzle. Виглядає майже так само. Такий самий left join, такий самий набір полів. Одне, що ви можете побачити, — це що поля у профілі згруповані у вкладений об'єкт, але це такий convenience synthesis. Який ми спеціально розробили для таких випадків, щоб простіше було перевіряти, чи заджойнілись дані з профілю або ні.

Отже, розробник, просто знаючи, як йому написати join в SQL, пише рівно такий самий join за допомогою Drizzle. І у багатьох випадках йому навіть не доведеться відкривати документацію нашу, щоб подивитись, як написати потрібну йому query. І ми це вважаємо найбільш правильним підходом до архітектури ORM, який робить поріг входу в Drizzle майже нульовим. І усі інші типи query, як insert, update, delete, пишуться рівно так само. Ви просто думаєте, як би ви написали це на SQL, і пишете те саме на Drizzle. Окрім звичайного коду, в Drizzle є ще одна API, яка може бути підтримана. Яка називається additional queries. Щоб зрозуміти, що вона така і навіщо потрібна, давайте розглянемо ще один приклад.

Припустимо, у нас є таблиця юзерів і таблиця міст у відношенні many-to-one. І нам потрібно обрати з бази міста та масив юзерів у кожному місті. Якщо ми в цьому випадку застосуємо join, то отримуємо якийсь такий результат. Тобто, якщо в нас є n міст та m юзерів, результатом такої query буде n помножити на m записів. І щоб отримати з цього результат, який нам власне був, потрібен з самого початку, тобто список міст, і у кожного міста список юзерів. Нам потрібно ще буде зробити агрегацію в коді на цьому результаті. Знову ж таки, для цього випадку це не дуже складно написати. Хоча й може зайняти якийсь час, якщо ви це робите вперше. Але такий підхід погано масштабується для більшої вкладеності.

Наприклад, якщо б у нас була ще таблиця друзів, і нам було потрібно для кожного юзера обрати список його друзів. Тому саме для таких сценаріїв, де нам потрібно обрати глибоко вкладені реалізаційні дані, ми розробили API relational queries. І щоб отримати такий самий результат з використанням relational queries, нам потрібно написати ось таку query. І вона одразу ж поверне вам дані у потрібному форматі, без ніяких агрегацій з вашої сторони. А в випадку, де нам потрібно ще й обрати друзів для кожного юзера, це б виглядало ось так. І це API виявилось дуже популярним саме серед розробників, які вже мали досвід з іншим ORM, наприклад, з цим SQLize або PRISM, і хотіли мігрувати з них на Drizzle. Бо саме це API для них виглядало найбільш знайомим. Крім того, воно не тільки зручне, але ще й доволі ефективне. Бо кожен такий виклик робить рівно один запит в базу. На відміну від тієї ж бази. У PRISM, у якої є схожий API, але в ній, в принципі, немає концепції join-ів. Якщо ви не знали, то для кожної такої зв'язаної таблиці вона робить декілька окремих запитів в базу. Через що працює значно повільніше. І я передаю слово Алекс.

Дякую. Так, давайте ще раз, щоб ви запам'ятали. В Drizzle є relational queries та CRUD. Хто знає, що таке CRUD? Звісно, це select, insert, update і delete. А ось так виглядає API Drizzle для relational queries. Отже, чому Drizzle — це поганий вибір? Drizzle ще досі не досягло v1. Та це означає, що ми можемо змінювати API. І ми можемо, і ми змінюємо, ми покращуємо його. Але це призводить до того, що деякі користувачі почувають, що API — це не стабільно. І вони починають скаржитися. І незважаючи на те, що ми робимо це згідно з CMBR. Отже, так, це є мінус для нас. Але плюсом є те, що ми дуже близько до бажаного API. До v1, я маю на увазі. Так само багато людей скаржиться, що DrizzleKit не є open source. І це, звісно, так. Ми плануємо його опенсорсити в v1. Разом з v1 релізом. У нас просто не було часу привести його до ладу. Отже, хто знає, що таке AWS, CloudFormation, Terraform? А хто знає, що таке SST? Ніхто? SST — це конкурент Serverless Framework, конкурент Terraform. А ось це — це співзасновник та core-розробник. Він є виробником цього SST. І ось, що він каже про Drizzle. Вибачте за той твіт. Ось. DAX каже, що наша API топ. І що наша команда знала, що робить. Звісно, це не так. Це лише гарний збіг обставин. Хто знає, що таке Pilot? Ось. Pilot CMS. CMS використовує Drizzle. Вони мігрували з Mongo Only на Mongo Plus SQL бази даних. Та вони використовують Drizzle ORM як first-class API. Та Drizzle Kit для того, щоб інтернелі робити міграції даних. І ось, що каже засновник Pilot — James McRoot. Каже, що все гаразд. T3Stack. Хто знає, що таке T3Stack? Клас. Три чоловіки. Це один з найпопулярніших, навіть найпопулярніший стек, який дозволяє вам швидко розгорнути FullStack, ApplicationStack. Та Drizzle — це одна з двох ORM-ок на вибір нарівні з Prisma. Це Whoop. Я не знаю, хто вони, але у них 9,2 мільйони візитів за квартал, та вони використовують Drizzle. Хто знає, що таке open source? Є дуже багато проєктів, які використовують Drizzle. AnswerOverflow. Вони використовують Drizzle, та ми використовуємо AnswerOverflow. У нас в Discord. OpenStatus використовує Drizzle. Anki, вони підняли 1,5 мільйона, та вони також використовують Drizzle. Отже, багато хто вже в продакшені давно використовує Drizzle. Це гарно.

Які у нас плани? Ми плануємо додати підтримку MS SQL, MariaDB та CockroachDB. Ми запланували реліз V1 на січень 2024. Та ми відкриваємо джерело для DrizzleKit разом з релізом V1 RMK. А також ми плануємо запустити DrizzleThemes для нашої DrizzleStudio. У нас не було бенчмарків. Нам потрібно створити TypeScript Playground, SQL Query Runner у DrizzleStudio. Також я хочу сказати кілька слів про SQL LSP. Drizzle ми вже зробили теми. Вони виглядають ось так. Ви можете створювати ваші власні теми для DrizzleStudio або встановлювати ті, що вже створені. Вже є понад 100 тем для DrizzleStudio, які люди створили за останні кілька днів. Бенчмарки також готові. Вони виглядають ось так. Вони доступні на нашому веб-сайті ORM-ки. Завітайте та спробуйте. Вони дуже добре налаштовані. Ми також створили TypeScript Playground. Ось він у DrizzleStudio, у лівому верхньому куті. Ви можете писати TypeScript з автодоповненням. Ви можете виконувати його, дивитись на результат у форматі JSON, SQL, таблиці, а також експортувати у JSON та CSV. Упс. Я також хотів сказати декілька слів про SQL LSP. Отже, ми плануємо створити власний SQL LSP для Drizzle. Мряка, нехай проблеми та незгоди не роблять вам в житті погоди. Приєднуйтесь до поїзда Drizzle. Дякую.