Спасибо. Скажите пожалуйста, а вот операции по типу обновления токена аутентификации тоже должны через WorkManager выполняться? То есть допустим телефон "спит", в фоне определить, что срок токена истекает и незаметно для пользователя его обновить, чтобы он оставался залогиненым. Или это не так делается?
Иван Шумов, не нужно в деталях, просто либо вы совсем о другом говорите, либо я не улавливаю. Если есть какой-то сторонний сервис атворизации, то в чем смысл сотен серверов у компании N, если будет узкое место в виде стороннего сервиса авторизации? Или сторонние сервисы выдерживают любые нагрузки? получается они платные, раз могут выделять такое количество мощностей?
Сергей Горностаев, спасибо. Ознакомился, появилось больше понимания. Вот только прочитал, что например мобильные приложения не используют такой способ, потому что быстро истекает токен. Может Вам известно какой способ предпочтителен в случае с мобильными приложениями?
Спасибо за наводки, я уже читал и если честно каша в голове. Насколько я понимаю везде говорится что это сторонние "сервисы" и у меня ассоциация что это когда "Войти через фейсбук", например. Но вот если я регистрируюсь например в том же инстаграм через обычную почту и пароль, в этом случае кем выдается токен? или там не токен а что-то другое? в общем хочется понять, как в современных проектах реализован вход без сторонних сервисов
Ключ, о котором идет речь, это какой-то ключ "из коробки", раз о нем все знают? Или этот ключ генерируется, а потом рассылается всем остальным серверам?
l4m3r, highload - понятие растяжимое, где-то большое количество операций чтения, где-то записи/удаления, как в вашем случае.
Я озвучил бы такие мысли для таблицы лайков:
Про много insert/delete возможно имеется в виду что индексы постоянно будут перестраиваться, блокировки там всякие. Чтобы смягчить это, можно например не удалять данные сразу, а помечать их как удаленные, а потом отложено удалять большими кусками все данные, помеченные как удаленные.
Убрать это
foreign key (`post_id`) references `users`(`id`) on delete cascade,
foreign key (`user_id`) references `posts`(`id`) on delete cascade,
PK скорее всего не нужен тут, скорее надо повесить неуникальные индексы на user_id и post_id.
Возможно нужно прибегнуть к партиционированию, но опять же, зависит от конкретной задачи и нагрузки, это нужно детальнее смотреть.
Если будет возможность получить обратную связь и узнать что именно хотели от вас услышать, то буду благодарен если напишете, самому интересно.
peacemakerv, я правда понимаю вашу "боль", но тут нет золотых пилюль, рынок такой что вместо того чтобы просто программировать нам нужно пытаться идти на уступки/компромиссы/переработки, чтобы заполучить клиента. Самый правильный способ - пытаться объяснить клиенту за 5-10 минут что к чему и для чего нужен сервер. Если он не способен понять такой элементарной штуки - может оно и к лучшему, сбережете много нервов. Ну и поймите одно - вы не один ему скажете про необходимость содержать сервер, скажут и все остальные фрилансеры, так что вы будете в равных условиях. Объясните на примере сайта: если человек заказывает сайт ему же как-то объясняют что за хостинг надо платить, за домен надо платить и тд, так и тут ситуация аналогичная - это необходимые расходы, которые целиком лежат на клиенте, ведь у мобильных приложений тоже есть свой "хостинг", как-то так.