Для аутентификации в этом репозитории используется jwt токен. Технология известная, зарекомендовавшая себя.
Зарекомендовавшая себя дурной славой
Давайте в ней усомнимся. Как минимум - в целесообразности гонять в каждом http запросе такой большой кусок данных. Расскажите о проектах с вашим участием, где использовалась другая техника авторизации.
Везде, кроме маркетплейсов NiFi и Sportbooking использовались другие техники. В Telegram miniapp - технология похожая на JWT с данными и подписью, в играх и моих админках испольвался WS, который внутри себя имеет внутренний id. В ряде приложений использовалась сессия/токен
Так я и выбирал. JWT выбирал для сервиси загрузки и ресайза картинок. Если бы делал сервис аутентификации, как у гугла, то взял также
Чтобы не никак не связывать сервер картинок с базой
В каком проекте, в котором вы участвовали, вы бы наоборот, вместо jwt выбрали что-то другое и почему?
У меня не было проектов, где jwt был выбран ошибочно
В этом репозтории в некоторых таблицах для идентификации записи используется uuid. Эта техника удобна по нескольким параметрам.
Сложно представить, чтобы использование uuid во всех таблицах - как стандарта - создало бы где нибудь проблему.
Сложно представить, что человек, использующий uuid в таблицах выше джуна
Но может быть в вашей практике встречались случаи, где uuid как идентификатор стал проблемой или мог бы стать проблемой? Опишите где и почему.
В этом репозитории вообще происходит дичь. uuid передаётся с клиента. Даже если допустить, что он будет генерироваться на сервере - это всёравно плохо. Причина в том, что uuid, как число, длинный 16 байт, а процессор 8, надо два регистра, чтобы это обработать. Также в два раза больше читать из оперативки/диска и в 2 раза меньше влезет в кеш. В коде проекта он к тому же используется, как строка, что лютая дичь и ещё больше замедляет работу, ведь, каждая буква - 1 байт. В моих проектах такое не встречалось
В этом репозитории, серверный код сделан на базе NestJS. DI, services, controllers, middleware, decorators - в этом, как и во многих других подходах есть плюсы и выгоды.
Расскажите с примерами из опыта о реальной пользе того или иного механизма организации кода лично для вас или для вашей команды, а может быть - для компании.
DI - хорошо для тестов. Но если слишком глубоко вкладывать, то задолбаешься одно и тоже из класса в класс передавать. Services, controlles - норм. Хорошо выносить часть логики в отдельное место, и вообще mvc с его вариациями - благо. middleware - плохое решение, я его просто его не использую. decorators - хорошая штука на часто повторяющихся задачах, однако на редких, проще функцию написать, чем в декоратор это превращать, дебажить легче. Поэтому пользка каждого решения сомнительна, я использую более передовую архитектуру, где изменения на сервере мгновенно передаются на клиент и интерфейс перерисовывается. То есть с сервера можно управлять UI каждого клиента, но с вышеперечисленным тоже знаком
Если есть какой-то механим, который также - для вас, команды или компании наоборот - создавал сложности - тоже расскажите.
В этом репозитории, для интерфейса используется React. Его название связано с реактивным подходом к отрисовке интерфейса - мы меняем состояние, а интерфейс перерисовывается в соответствии с этим. Сам посыл подкупает - разработчик заботится о состоянии, остальное за него делает фреймворк. Такой подход, конечно, помимо React реализуют и многие другие фреймворки.
Были ли ситуации в вашем опыте, когда реактивность была не плюсом, а помехой? Если да, расскажите на примере.
Никогда. Такое только у криворуких
Если был опыт построения рендера интерфеса на другом принципе, раскажите на каком и какие были резльтаты?
Разные рендеры делал в своей жизни. Делал рендер на WebGL - там шейдеры надо писать - код, который обрабатывается для каждого пикселя. Было, что попиксельный рендер делал в canvas - там каждый tick в цикле идёт вычисление изменившихся областей и их перерисовка. Писал на jQuery давно, было много бойлерплейта
Расскажите на конкретных примерах, что вам доставляет неудобства в том, как реактивность реализована непосредственно во фреймворке React?
React не доставляет неудобств. Неудобство создают шизы которые его продолжают "развивать" и неумелые разработчики, которые не умеют с ним работать. Пока у руля был создатель, было всё норм. Потом пришли шизы и сделали хуки, в том числе useState. Вот, если пользоваться внешними хранилищами данных, такими, как mobx, то проблем нет никаких. Если же пользоваться useState - то начинается props hell, какие-то провайдеры, в которые всё оборачиваются и нечитаемый код, в котором, чтобы разобраться надо открывать по 10 файлов - это один из проектов, который я видел.
Что же касается самой реализации в фреймворке, то она достаточна проста и хороша. В React всё функция. Когда мы меняем state - реакт проходит по всем компонентам в цикле и смотрит зменения, связанных с ним значений. Если что-то поменялось, вызывает функцию генерации html - это если общими словами