https://docs.nestjs.com/techniques/serialization
https://docs.nestjs.com/techniques/validation
Не дуже багато писав на несті, але здається, що посилання вказують на потрібні доки.
А скажіть, будь ласка, які бенчмарки взяті за основу? Конкретно про швидкість json'у

нестовские методы используют методы файстифая под капотом? если да, то какие используются в случае express? насколько я помню, они для совместимости платформ не юзают фичи фастифая.

бенчи https://github.com/fastify/benchmarks/
фастифай использует fast-json-stringify https://www.fastify.io/docs/latest/Validation-and-Serialization/#serialization соотв бенчи https://github.com/fastify/fast-json-stringify#benchmarks

Ну так і де порівняння з нестом в цих бенчах? І до чого тут експрес взагалі?)

І щоб закрити дану бесіду додам, що немає якихось сумнівів, що фастіфай швидше за нест. Мені цікаво було почути, які додаткові фічі має фастіфай в порівнянні з нестом. Принаймні ви сказали, що вони є :) Виявилося, що фіча та ж сама, але можливо (треба порівняльні бенчі) швидше працює) :)

Такой вопрос..
Есть ли какой-то “бинарный” сериализируемый протокол трансфера данных между сервером и браузером поверх http?
(возможно, конечно, мне стоит включить просто компрессию:))

Скажем, JSON - специфический формат для больших данных, так как одна double цифра будет занимать не 8 байт, а столько байт, сколько “тексто-цифер” в ней есть. Скажем, цифра 12345.67891232143 будет занимать 16 байт, а “something”: null - будет занимать аж 4 байта (и это еще без учета имени самого поля).

Кто-то, может, пробовал/решал проблему с пересылкой больших объемов данных между сервером и браузером? Как именно решали? Какие-нибудь интересные сериализаторы использовали? Или просто компрессией? Буду рад наводкам, спасибо:)

Может, protobuf?

Бинарные и текстовые форматы не этим отличаются. Числа обычно целые передают, а 1234 занимает 4 байта как строка и в бинарном формате int64 это 8 байт. Основеая проблема по размеру в том, что имена полей много раз одинаковые повторяются если передавать массив объектов. Но это нужно gzip включать и все.

Ненавижу протобаф )

HTTP2 - он быстрый и бинарный с кучей других плюшек, поверх него protobuf, а поверх него еще gRPC. Но можно только HTTP2 использовать.

Подскажите, есть ли универсальный способ сделать social login не привязываясь к конкретным библиотекам от Google, Facebook?

auth0 может подойти

вы можете реализовать его самостоятельно

Использовать Auth0 как единую точку входа для всех провайдеров?
А Вы с ним работали? Там нужнл настроить только аккаунт на Auth0 или предоставлять ему ещё и ключи к каждому сервису?

почти везде это OAuth2, просто реализовываете его спецификацию

Конечно ему нужны ключи к каждому сервису

у меня "почти" social login на страничке оплаты - люди заходят через GitLab, авторизовываются на Patreon чтобы получить скидку - всё на чистом http

Работал и зная сколько с ним проблем, лучше бы не работал)) вообще Илья правильно говорит, себе же лучше реализовать самому. Но если вдруг вам слишком лень или по другой причине, можно использовать такое вот готовое решение. Ключи конечно нужно устанавливать везде, как и с любым другим API

честно говоря, я тоже спотыкался о грабли auth0, но они были у меня в хардкорных сценариях )

Я с social login не работал, поэтому дальше могут быть глупые вопросы.
То есть, Google и Facebook, например, реализуют OAuth2 и общение с ними не должно отличаться?

да