Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 24
Любопытный трюк!
Наверное, более правильным решением будем иметь единый список правил валидации в json, одинаково интерпретируемый и бэком и фронтом
Коллега, это гениально! Увидев только заголовок, мой не проснувшийся мозг построил другую траекторию - валидация на Go, в РНР через FFI, а в браузере - через WASM. Но так тоже хорошо! Вряд ли кто-то будет проделывать все эти телодвижения ради довольно простой и механически решаемой задачи (несколько строчек с правилами валидации) - особенно при наличии всех подводных камней, таких как устаревшая версия JS - но как идея это очень красиво!
Кстати, я сейчас подумал, что куда проще это всё решается двумя библиотеками с одинаковым синтаксисом валидации! Просто закинул с сервера массив
'title' => 'required|string|max:255|unique:posts',
'body' => 'required|string',
'category_id' => 'required|integer|exists:categories,id',
'published_at' => 'nullable|date',
И JS по ним всё провалидировал. Конечно, всё равно будут проблемы с валидациями, требующими доступа к БД, но их можно игнорировать и сделать сервер-онли.
Впрочем, в каком-нибудь Livewire это наверняка уже реализовано?
Согласен. Без вопросов. Есть и другие заходы на проблему, в том числе и два конструктора валидаторов из единого конфига. И использование третьего языа, который можно скомпилировать в язык и фронта и бэка. Можно посравнивать эти подходы на практике, но это уже будет другая статья.
Ага, тоже ожидал скомпилированный код под архитектуру wasm.
В 2020 была задача валидировать кучу произвольнах форм ввода, фронт-энд программист предложил на фронт кидать описание формы ввода, что бы создавать форму динамически в браузере из JS. Иначе ему приглось бы руками прописывать все базовые формы и потом тратииь время на разработку новых. Описание формы мы записывали как JSON. В описании формы ввода так же было описание правил валидации, в таком виде как я на бэке записывал их для Ларавель.
В итоге получилось делать формочку по спецификации из описания формы. Правила валидации были достаточно простыми: обязательность значения, тип, мин, макс, длина строки. Какие то специфичные проверялись только на бэке (например формат инн для юр лиц и для физ лиц)
При том что фронт получал описание формы с бэка у нас не было пролемы рассинхронизации проверок на сервере и в браузере.
Вариант с FFI идеальный, но требует индивидуального подхода. Для быстродействия с JS, получается надо выполнять сборку кода валиатора и написать динамическую подгрузку соотвествующих бинарников.
Своё решение с компиляцией на go если доведёте до ума, то думаю кто то решиться,попробовать применить.
Успехов !
PS
https://bun.sh/docs/bundler/executables
Инструкция как из JS кода сделать исполняемый файл под любую операционку.
или xsd. как язык описания проверок.
на сервере много лет работает вариант на php с простой трансляцией form-url-encoded в xml и дальнейшей проверке по схемам.
а для клиента был вариант с генерацией валидаторов на js из тех же схем...
а еще раньше это можно было декларативно прям в xforms описывать - и биндинги элементов к данным и т.д.
Есть похожее на Rails, но с jQuery (с 2010 года как-никак, но до сих пор развивается). Правила валидации записываются в data- аттрибуты.
Даже не знаю, не разделяю восхищение. Чтобы разработчику меньше набирать и не ошибиться, вы заставляете в рантайме гонять JavaScript на каждый запрос клиента в считай виртуальной машине. И правда кодогенераторы выглядят более разумным решением. Кстати, есть Zod для Go, правда как и положено в Go, со своим синтаксисом, ибо не дай бог разработчику надо набрать слово public, пусть не напрягается и просто жмет Shift - public функции с заглавной :-/
Спасибо за ссылочку. Для того и общаемся, чтобы в комментариях насыпали того, на что сам не сразу наскочишь.
Согласен. Кодогенерация на основе спецификации OpenAPI точно есть в Go и в Laravel. Для фронта наверняка тоже есть решения.
Пишешь yaml, на его основе генерируешь код с валидацией.
Тут интересна не задача, а подход к решению. С такого вот баловства начинаются серьёзные вещи. FFI в языке уже давно, но случаи использования всё ещё единичные. А с таких дурацких на вид примеров, глядишь, начнётся и более массовое использование.
Забавный эксперимент, но что делать, если участников больше двух? Например, добавляется мобилка на флаттере.
Мне больше нравится вариант с использованием общего формата описания правил валидации. Тем более, что самому с нуля формат описания правил можно и не придумывать, а взять готовый https://json-schema.org Стандартная схема позволяет описывать достаточно сложные случаи. Не хватает - всегда можно расширить.
А вот это хороший вопрос. Не думал, что делать для 3+ участников. Подумаю.
Что касается схемы, это понятно, что в 95% случаев использование библиотек с единой конфигурацией наиболее разумно. Я исследую вопрос с другого угла, хочу чтобы валидатор был не декларативными правилами, а исполнимым кодом. Так гибкость выше чем у любого конструктора правил.
А как насчет валидации, например, емейл уже такой зареган, ну и другие случаи, когда нужно сходить в базу. Или одно поле зависит от другого: если выбрали галочку "юр лицо" то появляются доп поля, где нужно валидировать инн.
Если нужно сходить в БД — это в любом случае не фронтовый валидатор, "не наш случай". "Одно поле зависит от другого" — это задача валидации, "появляются доп поля" — задача уже вне валидации. Я начал вторую часть статьи, реализация того же, но на wasm, попробую проанализировать в процессе случай с зависимыми полями, как он соотносится с идеей "один код валидации на фронте и бэке".
Что значит не наш случай, если это основная головная боль? :) Когда у вас появдяется зависимость одного поля от другого, это поле тоже надо валидировать. Да даже взять валидацию, когда поле становится required в зависимости от другого поля. Это 99% кода, а вы так аккуратно избегаете этого аспекта. Просто так проверить формат - ну комон, этого добра воз и маленькая тележка. Проще уж тогда валидировать на сервере и присылать ошиьэбки, чем дублировать валидирование
Почему не использовать например функционал json schema? Я например на стороне сервера уже лет 10 использую для проекта на php. Немного правда пришлось добавить функционала кастомных, чтобы при нескольких проверках выдавало ошибку именно по этой проверке а не просто общую ошибку.
Сейчас новый проект но уже на сервере на rust писан. Так же json схемы входящие данные проверяют
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Единый код валидаторов на фронте и бэке (PHP + FFI + Go + JS)