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

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

JSON просто з бази даних у браузер

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

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

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

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

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

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

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