Перейти до вмісту

Спроєктувала архітектуру наскрізної передачі JSON, у якій функції PostgreSQL повертають повний JSON, що дослівно пересилається через Go API, усунувши проміжну десеріалізацію (unmarshalling) та унезалежнивши фронтенд від змін схеми.

JSON напряму з бази даних у браузер

Ситуація. Звичний шлях даних від бази до браузера — це естафета перетворень. База даних віддає API рядки, API десеріалізує їх у структури, перекомпоновує, знову серіалізує в JSON, і лише тоді дані вирушають далі. Кожен такий перехід — це код, який треба написати, код, який треба протестувати, і ще одне місце, де уявлення API про дані та уявлення про них бази даних можуть розійтися.

Завдання. Ідея полягала в тому, щоб обійтися без естафети. Якби база даних повертала готову відповідь, API міг би просто передавати її далі, а фронтенд залежав би безпосередньо від форми даних у базі, а не від підтримуваної вручну копії цієї форми в Go.

Дія. Тож систему побудовано як пряму передачу. Функції PostgreSQL збирають усю відповідь у JSON — формувати її є справою SQL, і відбувається це там, де вже лежать дані. Обробник на Go отримує її як json.RawMessage і пересилає без змін; він ніколи не розбирає її на частини й ніколи не перекодовує. Невелика допоміжна функція QueryJSON зробила цей патерн шляхом найменшого опору, а не тим, про що треба щоразу пам’ятати. Відпала вся проміжна машинерія, якою зазвичай обростає класичний багаторівневий API, — DTO, мапери, структури відповідей.

Результат. Код обробників різко скоротився, а головне — фронтенд перестав бути прив’язаним до Go. Досить змінити те, що повертає функція, і нова форма даних доходить просто до клієнта, а в коді обробників не треба правити жодного рядка. Менше рухомих частин, а цілого класу розбіжностей між рівнями тут просто немає.

Одна частина довшого переліку — і він увесь на цьому сайті.

Кожен запис написано однаково: ситуація, завдання, що ми зробили і що змінилося.

Переглянути весь перелік