Комментарии 21
Работа по сути проделана колоссальная, но только какой выхлоп с этого, кроме получения опыта? Нет желания развивать и рекламировать проект? Я имеюю ввиду собственно ваш собственный сайт аналог пинтереста, ну и как долго вы будете поддерживать всё это дело на github?
Спасибо за ваш вопрос! Действительно, работа над проектом проделана колоссальная, и для меня это не просто способ получить опыт, а возможность создать полноценный продукт, которым можно гордиться.
Проект задумывался как портфолио, демонстрирующее мои технические навыки — от проектирования архитектуры до реализации масштабируемого API и real-time функционала. Но на этом останавливаться не хочется.
Что касается рекламы — желание, конечно же, есть. Планирую привлекать не только новых пользователей, но и разработчиков, которым интересна идея и которые готовы внести вклад в развитие проекта. Это может стать отличной возможностью для совместной работы и формирования небольшого комьюнити вокруг продукта.
Я продолжу поддерживать и развивать проект, постепенно улучшая его и добавляя новые фичи. В будущем хотелось бы перевести его из разряда pet-проекта в нечто большее — полезное, живое и открытое для всех, кто хочет поучаствовать.
Мда... хотелось бы написать про неприличную иичницу, как я обычно и делаю, когда вижу нейроафторов, но тут слишком позорная статья
С точки зрения отработки технологий - полезно. Теперь настало время посмотреть на архитектуру. У вас вся логика в эндпоинтах и тасках, рекомендую интегрировать в проект https://github.com/reagento/dishka для изоляции инфраструктуры от бизнес логики
Да, вы верно подметили — писал всё на скорую руку, в первую очередь хотел реализовать функциональность и попробовать как можно больше фич. В дальнейшем, конечно же, планирую полностью разбить бэкенд по слоям, отделить бизнес-логику от инфраструктуры. Спасибо за рекомендацию с Dishka — обязательно изучу и попробую внедрить для более чистой архитектуры.
С точки зрения брендинга - так ты слона не продашь.
Безвозмездно придумал тебе имя для проекта - Coplone
Принцип формирования анаграммический, C(l)o(ne)-P(interest)-(C)lone.
Удачи.
Круто! Много вытянутого вверх конечно на главной странице. А так огонь просто!!! Сейчас с большим количеством нейронок, и большого количества контента, будет самый топ! Русского языка бы побольше, а лучше возможность мультиязычности добавить.
Вёрстку и стили тоже сам делал?
Хотел написать отзыв по сути, но увидел в вашем коде поддержку войны, и передумал....
Красивый проект с визуальной точки зрения! Да, работа проделана очень большая, видно, сколько усилий вложено.
Теперь по существу, замечания и предложения.
1) Презентацию Вы сделали хорошо, но это работает, если Вы хотите продемонстрировать проект человеку, далекому от IT. Хабр -- профильное сообщество, то же самое и Github, поэтому...
2) На мой взгляд, надо определиться с целевой аудиторией поста, кому Вы рассказываете и что хотите рассказать. Это пост для разработчиков? Для дизайнеров? Для потенциальных работодателей? Для прославления себя любимого?
Если это пост про разработку, то хочется прочитать именно про разработку, почему выбрали те или иные инструменты и технологии, какие возникли проблемы по мере использования, как их решали.
Если пост для дизайнеров, то будет совсем другой подход и коленкор.
3) Если говорить о Github, то в README прежде всего хочется прочесть о фичах проекта и о том, как проект установить у себя (особенно если Вы хотите, чтобы другие люди в нем поучаствовали).
А вот вся эта простыня со скриншотами там совершенно не нужна и даже вредна! У занятых людей нет времени, чтобы просматривать эту лабуду и они не будут это делать. Одного скриншота в начале README достаточно.
4) Что касается скриншотов и подробного описания возможностей, то их лучше оформить в виде документации к проекту и разместить на отдельной странице, а в README достаточно ссылки на эту документацию, или на пост на Хабре.
5) Собственно по развитию проекта дальше (если планируете его развивать). Вот этот фейерверк технологий, он прекрасен для презентации, но в реальном сопровождении это гемор. Все что может сломаться -- сломается! Зачем 3 базы данных в проекте? Зачем миллион зависимостей в requirements.txt? Лучше использовать меньше технологий и лучше протестировать их связи, тогда больше шансов, что через полгода при каком-нибудь обновлении ничего не сломается. Не говоря уже о том, что меньше зависимостей быстрее устанавливаются, занимают меньше места и жрут меньше ресурсов.
Удачи!
Хорошая работа для демонстрации в портфолио. Не углубляясь, рекомендую обратить внимание на то, что у вас лоадер отображается пока вы не загрузите порядка 12 мб ресурсов, я уверен, что можно отобразить данные гораздо раньше. И попробуйте зайти на сайт с мобильного устройства, адаптивностью надо заниматься.
Спасибо большое за отзыв! Да, вы абсолютно правы — на данный момент основная проблема заключается в отсутствии адаптивности. Я не позиционирую себя как frontend-разработчик, поэтому основной упор делал на проработке backend-части: реализации функциональности и REST API.
На фронтенде получилось довольно много кода, и он писался преимущественно под моё разрешение экрана (1536×864), то есть ориентировался на поведение как у web-app без учёта других экранов. К сожалению, знаний в области responsive design у меня пока нет, и с текущей архитектурой внести такие изменения займёт довольно много времени — ориентировочно около месяца, с учётом необходимости разобраться во всех нюансах адаптивной вёрстки.
Тем не менее, я обязательно постараюсь заняться этим в будущем, чтобы улучшить пользовательский опыт на всех устройствах.
Интересный проект, спасибо, что поделились. Вы используете 3 бд, зачем ? Приложение работает через docker compose ? Не видно ни одной системы мониторинга в проекте/архитектуре. Что с картинками, их много, какое решение выбрали для работы с ними ?
Спасибо большое за интерес к проекту!
Что касается баз данных — основная, конечно, PostgreSQL. MySQL и MongoDB были добавлены преимущественно для практики, изучения разных технологий и моделирования микросервисной архитектуры с различными подходами к хранению данных. Это помогает лучше понимать, как взаимодействуют разные СУБД в рамках одной системы.
На production проект развёрнут с использованием Docker Compose. Приложение разделено на несколько сервисов: frontend на Vue.js (собирается и обслуживается через Nginx), backend на FastAPI (Dockerfile), а Nginx работает как reverse proxy между ними.
На момент написания описания проекта система мониторинга действительно не была реализована, но сейчас она добавлена:
интегрировано логирование с ротацией логов,
подключён Sentry для отслеживания ошибок и запросов,
настроен Prometheus для сбора метрик от FastAPI, Nginx и системных метрик через Node Exporter.
По поводу изображений и видео — на текущем этапе они загружаются асинхронно и сохраняются либо локально, либо в Yandex Object Storage (S3-совместимом хранилище). FastAPI затем отдаёт их обратно через FileResponse, а во frontend (Vue 3) используются обычные запросы через Axios. Понимаю, что это далеко не оптимальное решение, особенно для видео. В будущем планирую:
отдавать изображения через Nginx как статику,
для видео реализовать
StreamingResponse, чтобы пользователь не ждал полной загрузки файла.
Как я создал клон Pinterest с использованием Vue 3 и FastAPI