Новостей для этого блога не много. Новости сайта пишутся в другом блоге, а анонсов я особо не делаю. Потому подумал, может стоит переименовать этот блог и сменить его направленность? Буду писать тут всякие технические статьи. В основном о том, что освоил. Возможно кому-то эти статьи помогут освоить это чуть быстрее (да и вообще, возможно такие статьи кого-то привлекут).
Пока просто поделюсь мыслями и планами.
Статья на Пикабу:
Я периодически сижу на Пикабу. Есть там традиция - по пятницам публиковать статьи про какие-то свои дела. Хобби, поделки или работу... Это называется "Пятничное Моё". Задумался о том, что мог бы такую статью про сайт написать. Не техническую, а именно как оно шло, как развивалось, какие проблемы были и как они решались. С подачей в духе "как практически без навыков программирования создать мини соцсеть". Возможно статья привлечет к сайту внимание. Если решусь эту статью писать - опубликую её сначала тут, чтобы критику послушать.
Старый сайт:
Старый сайт всё ещё выполняет одну функцию - он рассылает "напоминалки" тем, кто не был на сайте несколько дней. Не переношу я эту функцию на новый движок только потому, что хочу её переделать.
Сейчас в качестве напоминалки рассылается письмо "Вам задали вопрос" в котором указывается ссылка на какой-то вопрос, заданный за последние сутки. Хочу сделать генерацию некоего дайджеста. Раз в неделю генерируются персональные дайджесты для каждого, попавшего в список пользователя (кто не отключил уведомления, не удалился, не забанен и не был на сайте более недели) и рассылаются как новостная рассылка.
Что-то типа такого
На скрине представлены все блоки, которые на данный момент я сделал. В письме же должно быть какое-то определённое их количество - например 3, выбираемых по приоритету (например сначала друзья, потом ответы на Ваши вопросы, посты в блогах, на которые Вы подписаны, подарки, потом просто "самый интересный вопрос" или "самый интересный блог")
Как только эта работа будет завершена - я займусь подготовкой конфигурации серверов без старого сайта, и как только закончу это - объявлю о его отключении.
Отвечай мини:
Тут пока ничего особо интересного нет. Ранее я делал авторизацию для этого сервиса. Авторизация делалась через токен. То есть клиент получает определенный токен и с каждым запросом передает его в заголовке. Обычно на сайте используются куки (для авторизации), но для приложений принято использовать именно токены (расцениваю мини именно как приложение). Уж не знаю почему, возможно потому, что приложения могут куки не поддерживать (мини, по задумке должна будет запускаться не только на сайте vk и ok, но и в их приложениях).
Ранее делался токен средствами, встроенными в DRF. Этот токен ни когда не менялся и не нёс в себе ни какую информацию. Просто ключ, с которым можно пользователя идентифицировать (посмотрев в базе).
Недавно переделал приложение для использование JWT (JSON Web Token). Это уже штука по интересней. Если коротко - то этот токен содержит в себе определённую информацию (в зашифрованном виде), например время его жизни и id пользователя, который авторизуется с его помощью. Кроме того, токен содержит подпись, с помощью которой можно убедиться, что информация верна (не модифицировалась) и токен выдан сервером, которому можно доверять.
Иными словами может быть отдельный сервер авторизации. При выдачи токенов он пользуется асинхронным шифрованием. То есть шифруются данные одним ключом (в данном случае приватным), а расшифровываются другим (публичным). У сервера, который принимает данный токен есть публичный ключ, он используется при проверки подписи, и если проверка пройдена, значит токен валидный, был выдан доверенным сервером авторизации и информация, содержащаяся в нём достоверна. Токен ограничен по времени, по истечению времени его нужно обновлять на сервере авторизации с помощью другого токена (в эти подробности вдаваться не буду).
Такой токен во первых более надежный (живет он обычно мало, если у вас его украдут - он быстро "протухнет", а перевыпустить злоумышленник его не сможет) во вторых он позволяет авторизовываться не обращаясь к базе данных (информация о пользователе уже содержится в нём). А следовательно можно авторизовывать сервисы, которые ни как не связаны с базой, где хранятся пользователи...
Мои эксперименты:
Примерно так, как описал выше, работает авторизация в микросервисной архитектуре. Когда есть отдельный сервер авторизации и есть несколько сервисов, которые принимают токены, выданные им.
Например есть отдельный сервис для блогов, отдельный для вопросов и отдельный для лички. Сейчас я завязан на определенном стеке - Django с плагинами Django Rest Framework (для создания API), Django channels (для создания приложения реального времени - вы получили уведомление и сразу же его увидели на сайте) и Postgress (база данных). И если мне захочется попробовать что-то другое - мне придётся переписывать всё приложение. В случае с микросервисами - можно просто переписать конкретный функционал и потом подружить его с основным приложением.
Не так давно я переделал встраивание видео с youtube, а также добавил встраивания с tiktok, instagram и soundcloud. Суть переделки - использование функционала oembed (который предоставляют эти сервисы). Найдя ссылку на ютуб (например) клиент отправляет её на адрес, где у ютуба находится oembed сервис, а в ответ получает код для встраивания (с картинкой и названием) (я понимаю, что это не при выводе поста надо делать, а при добавлении, но пока сделано так). Но тут вышла проблема. Если делать "поделиться" из мобильного приложения (tiktok и soundcloud) или копировать ссылку на YouTube-shorts (это такие короткие видео) - oembed не отрабатывает. Всё потому, что ссылки сокращены. Сделать из короткой ссылки длинную легко - достаточно обратиться по короткой ссылке и посмотреть, куда тебя перенаправляют. Вот только сделать это клиент не может - ему это запрещают политики CORS (это штука реализуется браузером, для безопасности. Чтобы сторонние скрипты Ваши пароли отправить куда-то не туда не могли). Если сервер не разрешает запроса с нашего адреса (или с любого адреса), то такой запрос будет заблокирован браузером. Для решения этой проблемы я сделал свой сервис, на который такие адреса отправлялись. Сервис уже делал по ним запросы и возвращал ответ с длинным адресом. Изначально такой сервис был сделан на движке сайта, и это привело к проблемам - запрос к стороннему сервису занимает какое-то время (1-2 секунды запросто могут пройти) и если таких запросов будет много - сайт просто перестанет отвечать на другие запросы, пока эти не обработает. Итого - сайт тормозит. Написал этот запрос отдельно, на том же питоне (Flask, так как Django слишком громоздкий для такого простого сервиса). После этого запросы перестали оказывать влияние на сайт, но всё равно отрабатывали медленно (потому что отрабатывали последовательно - сервис ждал ответа и только после него брался за следующий запрос). Попытки заставить Flask работать асинхронно (обрабатывать сразу несколько запросов и возвращать ответы по мере их получения) ни к чему хорошему не привели. Потом попробовал написать сервис на Node js (серверный Javascript) - и он заработал так как надо (этот сервис собственно и работает сейчас).
После этого я захотел поизучать написание сайта на Node Js, но снова переделывать движок нет ни какого желания... Микросервисы как раз позволили бы мне это сделать...
Например сейчас я пытаюсь написать чат на стеке Node JS, Mongo (база данных) и Graphql (это реализация API) на стороне сервера. На стороне клиента же используется клиент Graphql (Apollo), что позволяет упростить управление стейтом (как мне кажется на данный момент).
Показывать тут пока нечего, но если в итоге результат меня будет устраивать - буду думать, как подружить это дело с основным сайтом, и тогда это приложение придет на замену личкам (и возможно у нас появятся групповые чаты - делаю его как раз с этим функционалом)
Рейтинги и звания:
Посетила мысль, ввести здесь такую штуку. Эксперимент с монетами показал, что подобные вещи стимулируют активность. Надо бы ещё простимулировать :)
Что думаю на данный момент про рейтинги - рейтинг будет даваться за активность. Как именно - ещё нужно проработать. Например за вопрос попадающий в приоритетный список (3 вопроса в сутки) +x рейтинга, за ответ +y рейтинга. Для борьбы с накрутками можно не давать рейтинг за ответы на свои вопросы и ответ на вопрос, на который уже отвечал. Лайки на рейтинг влиять не должны, дизлайки у нас не планируются, так что кармадрочерства возникнуть не должно.
Сделать таблицы лидеров. Например 100 лидеров за всё время и 10 лидеров за сутки. Лидерам в профиле медальку рисовать :) Также сделать покупку рейтинга за монеты (а то у некоторых этих монет скопилось уже много).
Также думаю о том, чтоб обнулять монеты (и рейтинг, если он будет) тем, кто удаляет профиль... Чтобы удаление профиля стало более серьёзным шагом...
Звания - как раньше на форумах были. Сделать звания за активность, наградные звания и звания покупные, за монеты (в том числе "очень дорогие", так сказать лакшери, для вые6онов :) ). Пользователь может выбрать одно из доступных ему званий (заработанных или купленных) и оно будет отображаться везде рядом с его именем.
Ну вот как-то так.
Пока просто поделюсь мыслями и планами.
Статья на Пикабу:
Я периодически сижу на Пикабу. Есть там традиция - по пятницам публиковать статьи про какие-то свои дела. Хобби, поделки или работу... Это называется "Пятничное Моё". Задумался о том, что мог бы такую статью про сайт написать. Не техническую, а именно как оно шло, как развивалось, какие проблемы были и как они решались. С подачей в духе "как практически без навыков программирования создать мини соцсеть". Возможно статья привлечет к сайту внимание. Если решусь эту статью писать - опубликую её сначала тут, чтобы критику послушать.
Старый сайт:
Старый сайт всё ещё выполняет одну функцию - он рассылает "напоминалки" тем, кто не был на сайте несколько дней. Не переношу я эту функцию на новый движок только потому, что хочу её переделать.
Сейчас в качестве напоминалки рассылается письмо "Вам задали вопрос" в котором указывается ссылка на какой-то вопрос, заданный за последние сутки. Хочу сделать генерацию некоего дайджеста. Раз в неделю генерируются персональные дайджесты для каждого, попавшего в список пользователя (кто не отключил уведомления, не удалился, не забанен и не был на сайте более недели) и рассылаются как новостная рассылка.
Что-то типа такого
На скрине представлены все блоки, которые на данный момент я сделал. В письме же должно быть какое-то определённое их количество - например 3, выбираемых по приоритету (например сначала друзья, потом ответы на Ваши вопросы, посты в блогах, на которые Вы подписаны, подарки, потом просто "самый интересный вопрос" или "самый интересный блог")
Как только эта работа будет завершена - я займусь подготовкой конфигурации серверов без старого сайта, и как только закончу это - объявлю о его отключении.
Отвечай мини:
Тут пока ничего особо интересного нет. Ранее я делал авторизацию для этого сервиса. Авторизация делалась через токен. То есть клиент получает определенный токен и с каждым запросом передает его в заголовке. Обычно на сайте используются куки (для авторизации), но для приложений принято использовать именно токены (расцениваю мини именно как приложение). Уж не знаю почему, возможно потому, что приложения могут куки не поддерживать (мини, по задумке должна будет запускаться не только на сайте vk и ok, но и в их приложениях).
Ранее делался токен средствами, встроенными в DRF. Этот токен ни когда не менялся и не нёс в себе ни какую информацию. Просто ключ, с которым можно пользователя идентифицировать (посмотрев в базе).
Недавно переделал приложение для использование JWT (JSON Web Token). Это уже штука по интересней. Если коротко - то этот токен содержит в себе определённую информацию (в зашифрованном виде), например время его жизни и id пользователя, который авторизуется с его помощью. Кроме того, токен содержит подпись, с помощью которой можно убедиться, что информация верна (не модифицировалась) и токен выдан сервером, которому можно доверять.
Иными словами может быть отдельный сервер авторизации. При выдачи токенов он пользуется асинхронным шифрованием. То есть шифруются данные одним ключом (в данном случае приватным), а расшифровываются другим (публичным). У сервера, который принимает данный токен есть публичный ключ, он используется при проверки подписи, и если проверка пройдена, значит токен валидный, был выдан доверенным сервером авторизации и информация, содержащаяся в нём достоверна. Токен ограничен по времени, по истечению времени его нужно обновлять на сервере авторизации с помощью другого токена (в эти подробности вдаваться не буду).
Такой токен во первых более надежный (живет он обычно мало, если у вас его украдут - он быстро "протухнет", а перевыпустить злоумышленник его не сможет) во вторых он позволяет авторизовываться не обращаясь к базе данных (информация о пользователе уже содержится в нём). А следовательно можно авторизовывать сервисы, которые ни как не связаны с базой, где хранятся пользователи...
Мои эксперименты:
Примерно так, как описал выше, работает авторизация в микросервисной архитектуре. Когда есть отдельный сервер авторизации и есть несколько сервисов, которые принимают токены, выданные им.
Например есть отдельный сервис для блогов, отдельный для вопросов и отдельный для лички. Сейчас я завязан на определенном стеке - Django с плагинами Django Rest Framework (для создания API), Django channels (для создания приложения реального времени - вы получили уведомление и сразу же его увидели на сайте) и Postgress (база данных). И если мне захочется попробовать что-то другое - мне придётся переписывать всё приложение. В случае с микросервисами - можно просто переписать конкретный функционал и потом подружить его с основным приложением.
Не так давно я переделал встраивание видео с youtube, а также добавил встраивания с tiktok, instagram и soundcloud. Суть переделки - использование функционала oembed (который предоставляют эти сервисы). Найдя ссылку на ютуб (например) клиент отправляет её на адрес, где у ютуба находится oembed сервис, а в ответ получает код для встраивания (с картинкой и названием) (я понимаю, что это не при выводе поста надо делать, а при добавлении, но пока сделано так). Но тут вышла проблема. Если делать "поделиться" из мобильного приложения (tiktok и soundcloud) или копировать ссылку на YouTube-shorts (это такие короткие видео) - oembed не отрабатывает. Всё потому, что ссылки сокращены. Сделать из короткой ссылки длинную легко - достаточно обратиться по короткой ссылке и посмотреть, куда тебя перенаправляют. Вот только сделать это клиент не может - ему это запрещают политики CORS (это штука реализуется браузером, для безопасности. Чтобы сторонние скрипты Ваши пароли отправить куда-то не туда не могли). Если сервер не разрешает запроса с нашего адреса (или с любого адреса), то такой запрос будет заблокирован браузером. Для решения этой проблемы я сделал свой сервис, на который такие адреса отправлялись. Сервис уже делал по ним запросы и возвращал ответ с длинным адресом. Изначально такой сервис был сделан на движке сайта, и это привело к проблемам - запрос к стороннему сервису занимает какое-то время (1-2 секунды запросто могут пройти) и если таких запросов будет много - сайт просто перестанет отвечать на другие запросы, пока эти не обработает. Итого - сайт тормозит. Написал этот запрос отдельно, на том же питоне (Flask, так как Django слишком громоздкий для такого простого сервиса). После этого запросы перестали оказывать влияние на сайт, но всё равно отрабатывали медленно (потому что отрабатывали последовательно - сервис ждал ответа и только после него брался за следующий запрос). Попытки заставить Flask работать асинхронно (обрабатывать сразу несколько запросов и возвращать ответы по мере их получения) ни к чему хорошему не привели. Потом попробовал написать сервис на Node js (серверный Javascript) - и он заработал так как надо (этот сервис собственно и работает сейчас).
После этого я захотел поизучать написание сайта на Node Js, но снова переделывать движок нет ни какого желания... Микросервисы как раз позволили бы мне это сделать...
Например сейчас я пытаюсь написать чат на стеке Node JS, Mongo (база данных) и Graphql (это реализация API) на стороне сервера. На стороне клиента же используется клиент Graphql (Apollo), что позволяет упростить управление стейтом (как мне кажется на данный момент).
Показывать тут пока нечего, но если в итоге результат меня будет устраивать - буду думать, как подружить это дело с основным сайтом, и тогда это приложение придет на замену личкам (и возможно у нас появятся групповые чаты - делаю его как раз с этим функционалом)
Рейтинги и звания:
Посетила мысль, ввести здесь такую штуку. Эксперимент с монетами показал, что подобные вещи стимулируют активность. Надо бы ещё простимулировать :)
Что думаю на данный момент про рейтинги - рейтинг будет даваться за активность. Как именно - ещё нужно проработать. Например за вопрос попадающий в приоритетный список (3 вопроса в сутки) +x рейтинга, за ответ +y рейтинга. Для борьбы с накрутками можно не давать рейтинг за ответы на свои вопросы и ответ на вопрос, на который уже отвечал. Лайки на рейтинг влиять не должны, дизлайки у нас не планируются, так что кармадрочерства возникнуть не должно.
Сделать таблицы лидеров. Например 100 лидеров за всё время и 10 лидеров за сутки. Лидерам в профиле медальку рисовать :) Также сделать покупку рейтинга за монеты (а то у некоторых этих монет скопилось уже много).
Также думаю о том, чтоб обнулять монеты (и рейтинг, если он будет) тем, кто удаляет профиль... Чтобы удаление профиля стало более серьёзным шагом...
Звания - как раньше на форумах были. Сделать звания за активность, наградные звания и звания покупные, за монеты (в том числе "очень дорогие", так сказать лакшери, для вые6онов :) ). Пользователь может выбрать одно из доступных ему званий (заработанных или купленных) и оно будет отображаться везде рядом с его именем.
Ну вот как-то так.
ндекс
