Спасибо, было интересно

В ресте 404 и 410 - костыли в чистом виде. Предпочитаю не смешивать транспорт и логику. Во всех ответах возвращаю поля data, IsSuccess и массив errors. Это покрывает 100% ситуаций. И позволяет на клиенте написать единый типизированный обработчик. Рест в чистом виде годится только для обучалок. Шаг в сторону и начинаются костыли, типа 410, когда непонятно - нет пластыря в аптеке или нет аптеки.

@SMuxa

5 ай бұрын

Вот раньше тоже упарывался за коды возвращаемых ошибок. А теперь только когда какую то хрень присылают возвращаю 400 и вроде всем понятно.

@9285550

5 ай бұрын

@@SMuxa да. Всегда 200, на валидацию 400 и всё. Остальное на откуп либам авторизации и транспорта.

@tt0nix

5 ай бұрын

Для body возвращаемых ошибок отлично подходит Problem Details (RFC 9457). В .NET он отлично поддерживается из коробки.

"Обратная совместимость не нужна" - довольно спорное заявление

@tt0nix

5 ай бұрын

На том уровне, на котором были порождены эти костыли. Ну действительно, стоит ли всему новому коду в мире страдать потому что существует шанс наличия старого кода с именем класса "record" (с маленькой буквы)? Да нет конечно. Иначе экосистема не сможет эволюционировать и превратится в джаву. Обратная совместимость должна быть не слепая и тотальная, а разумная и гибкая.

с MemoryPack засада небольшая. Если, не дай бог, будет платформа с другой endianess, то совместимости не будет.

@tt0nix

5 ай бұрын

Это же массив байт. Как его интерпритировать зависит полностью от сериализатора. Как может платформа тут что-то поменять? Есть ссылка на issue или документацию почитать?

@VoroninPavel

5 ай бұрын

@@tt0nix Так прям в репе мемори пака написано ж: Endian must be Little Endian. However, reference C# implementation does not care about endianness so can not use on big-endian machine. However, modern computers are usually little-endian.

@tt0nix

5 ай бұрын

@@VoroninPavel, reference C# implementation does not care about endianness так это ко всему .NET'у относится. Ну т.е. на тех машинах на которых не будет работать .NET, не будет и мемори пак. да. Разве это проблема?

@VoroninPavel

5 ай бұрын

@@tt0nix он еще и для тупоскрипта вроде работает, как я понял.

@tt0nix

5 ай бұрын

@@VoroninPavel , так и есть. Но кажется что это приятный бонус. Основной таргет это .NET.

json-patch моментально превращается в тыкву, если что-то серьезнее CRUD'а

@tt0nix

5 ай бұрын

Вот поэтому тут должно быть два выхода: 1. Есть либа, которую все используют и она гарантирует нормальное применение патча 2. Не использовать этого монстра вовсе, дабы не вводить в заблуждение потребителей частичной поддержкой

Что-то я про Id'шники с префиксами и их отдачу в виде строки первый раз слышу Может опыта у меня не так много, но ни разу не встречал и для меня это звучит как что-то из страшного мира легаси Много кто так делает?

@tt0nix

5 ай бұрын

Страшное легаси это Int, просто легаси это GUID. А то как надо делать это string :) Но тут конечно же всё зависит от потребностей. Для самых простых случаев хватит и int. Именно поэтому данный подход самый популярный. Для самых сложных нужен string. Guid - где-то посередине. Так как string это самые сложные случаи, то и распространённость у него будет меньше. Но я бы не сказал что это связанно со сложностью. Просто индустрия ещё не доросла до массовости string'а. Например многие базы данных неэффективно запрашивают сущности по несортированносму ключу. И такая низкоуровневая особенность может служить поводом для извращения всех процессов. Как пример использования: RavenDB Working with Document Identifiers.

@user-fr1rt5in6c

5 ай бұрын

@@tt0nix Ну вот в моем понимании это болото - постоянно парсить это всё, где-то будет падать, где-то кто-то будет не ту строку отсылать, в общем прямо огромное раздолье для багов и нарушения контракта. А Guid он и в Африке Guid, и практически гарантирует уникальность, и строгое соблюдение контракта, туда не засунуть int/float/ещё какую-нибудь белиберду. Просто звучит как использовать везде object, туда можно затолкать что угодно, но удобно ли это? Отнюдь

@tt0nix

5 ай бұрын

@r1rt5in6c , конечно эта строка закрывается с помощью value object, поэтому невозможно её с чем то спутать. Более того, 2 Guid'а местами перепутать очень легко, а вот два идентификатора в виде разных value object - невозможно. Так что типизация и проверка на уровне компилятора тут максимально-возможные. Парсить руками ничего не надо. Существуют конвертеры, на ASP, на EF, на AutoMapper, на любой JSON, protobuf, на куда угодно. Они позволяют прозрачно сериализовать и десериализовать наши идентификаторы на любом уровне. Поэтому все описываемые проблемы на практике не встречаются. А вот проблем с GUID'ов очень много остаётся.

@user-fr1rt5in6c

5 ай бұрын

@@tt0nix звучит неплохо, в принципе) правда к Guid это также применимо, обернул и не перепутаешь, да и конвертируется всё без танцев с бубном. Но поинт я уловил, правда в продакшене ни разу не видел

@tt0nix

4 ай бұрын

@@user-fr1rt5in6c, префикс в подходе со string делает невозможным перепутать два идентификатора, даже когда они пришли от внешнего источника. Два гуйда могли прийти откуда угодно, они могли перепутаться местами и пока нет запроса в базу, невозможно сказать нормальные это данные или нет. А вот пришедшие строки имеют префикс (сервис и сущность). Я на уровне входа в контроллер, перед парсом, могу сказать валидные это идентификаторы для данной сущности или нет.

binary formatter вначале сказали что был лучше по перфомансу чем ньютон и текст а на бенчмарке сильно хуже оказалось у Стивена

@tt0nix

5 ай бұрын

Да, у него в статье есть такая странность. Он пишет что не хочет json сериализатор, потому что они медленные и потом в конце даёт график на котором они рвут его binary как Тузик. В общем, в начале веков, binary сериализатор действительно славился отличной скоростью. Но сейчас на эту скорость без слёз не взглянешь.

@ArseniySergeev

5 ай бұрын

@@tt0nix это потому что они старые и без span'ов)))

@tt0nix

5 ай бұрын

@@ArseniySergeev, со времён binary serializer появилось много разных способов оптимизации производительности. Было бы интересно увидеть их полную эволюцию. Но и до спанов уже там было чем померяться.

А вот не надо вообще возвращать синтетические id.