В этой статье мы сделаем небольшой экскурс в эволюцию архитектурных подходов – от классического шаблона MVC, популярного на начальных стадиях разработки, до более современных решений, таких как SOA, DDD, Modular Monolith и микросервисы.
Наша цель – показать, как переход от одной архитектуры к другой может решить проблемы поддержки, тестирования и масштабируемости. А также дать рекомендации по выбору оптимального решения в зависимости от требований проекта.
Расскажу о признаках неизбежности «перезапуска» проекта и разработки новой версии сайта с «чистого листа». Рассмотрим причины, по которым сайт оказывается в такой запущенной стадии. Найдем позитивные моменты в данной, казалось бы, наглухо негативной истории. Немного углубимся в технику процесса. В конце — чек‑лист для проверки своего проекта!
Мы — команда студентов из ИТМО, которая прошла путь от хакатонов до продуктовой разработки. На собственном опыте расскажем, как выстроили инфраструктуру, способную масштабироваться, переживать сбои и не стоить, как полкоманды в найме.
Когда вы только начинаете делать стартап, инфраструктура кажется чем-то второстепенным. Важнее MVP, фичи, дизайн, пичдек. Но в какой-то момент всё внезапно перестаёт помещаться на одном сервере, руками деплоить становится больно, SSL не обновляется, а продакшн падает из-за перегрузки или забытого docker-compose up.
Kubernetes? Слишком сложно, долго и дорого. Монолит? Неудобно масштабировать. Мы искали третий путь — и нашли его.
На вашем сайте, внутреннем портале, в интернет-магазине кто-то что-то сделал, а потом всё сломалось: сайт открывается криво (или не открывается вообще?), перестали работать фоновые задачи в планировщике, установились неправильные скидки всем пользователям на все товары... Предположим, что с безопасностью у вас всё хорошо: Joomla свежая, актуальная, расширения - тоже. Да и в логах сервера и логах Joomla тоже чисто... Тогда остаётся ещё один источник информации - Лог действий пользователей Joomla. Основная его задача - помочь быстро найти кому настучать по рогам причину и устранить её.
Всё, что связано с действиями в админке - может логироваться: от обновления системы и компонентов, изменения настроек до редактирования и сохранения конкретных элементов (статьи, товары, категории и т.д.) и загрузки файлов в медиа менеджере. Лично мне нередко этот функционал помогал найти тех контент-менеджеров, кто дублирует названия товаров, создавая дубли и тем самым негативно влияя на SEO. Или же вдруг обнаруживается недозаполненная, но опубликованная карточка товара, которой не должно было быть, но она появилась. И ладно если б это был единичный случай...
👋 Привет, Habr!
Вы когда-нибудь пытались найти качественный open-source клон Pinterest — с real-time функционалом, полноценной архитектурой, удобным UI и современной технологической основой? Я — да. И не нашёл. Поэтому решил создать свой.
Представляю вам Pinterest Clone — мой pet-проект, над которым я работал в одиночку 4 месяца, чтобы воссоздать не просто копию, а полнофункциональную платформу с реальным пользовательским опытом, максимально приближённым к оригиналу.
Всем привет! Меня зовут Никита Рыженков, и я хочу поделиться опытом разработки библиотеки FastOpenAPI. Это инструмент, который приносит удобный стиль маршрутизации FastAPI и автоматическую документацию OpenAPI в целый ряд Python-фреймворков. Идея родилась из личной боли: в одном проекте приходилось поддерживать OpenAPI-документацию сразу в нескольких фреймворках, и я устал дублировать решения под каждый из них. Вдохновившись лаконичностью FastAPI, я решил создать унифицированный подход для Flask, AioHttp, Sanic, Falcon, Starlette, Quart, Tornado – назвал его FastOpenAPI. В этой статье расскажу, какие проблемы решает FastOpenAPI, как он устроен внутри и как им пользоваться с примерами кода под каждый поддерживаемый фреймворк.
Но это не простые разработчики, а те, кто будет выступать завтра с докладами на нашем ежегодном бесплатном митапе Frontend Mix. 😎 Ребята расскажут про рефакторинг приложений за 10 секунд, стандарты тестирования во фронтенде, анимацию и уязвимости в финтехе. Ссылка на страницу конференции и регистрацию будет ниже, а пока оценим ответы на вопросы ИИ. 👇
Пытаясь подражать слогу классика, можно сказать, что "все чаты в целом одинаковы, но каждый реализует что-то свое".
так ли это? посмотрим.
TL, DR: далее рассказываю, что мы делаем свой UI набор компонентов для чата, даю ссылки и приглашаю присоединяться к проекту.
Привет, Хабр!
Сегодня я хочу поделиться с вами руководством, как реализовать Static Site Generation (SSG) в React без использования сторонних фреймворков, таких как Next.js, TanStack Start, React Router и им подобных. Сразу оговорюсь: я не считаю их чем-то «плохим» и не агитирую против их применения. Всё гораздо проще: иногда по тем или иным причинам нет возможности использовать эти инструменты, или самостоятельная реализация оказывается предпочтительнее из-за количества изменений в кодовой базе.
Если вам интересна тема стратегий рендеринга веб-приложений, то прошу под кат.
С каждым днем все больше продуктов создается и запускается с помощью ИИ.
К сожалению, с безопасностью у них пока не очень.
Переиндексация URL в Google — важный инструмент в руках SEO-специалиста и маркетолога. Если вы внесли изменения на сайте, добавили новые страницы или изменили структуру — сообщить об этом Google можно руками в интерфейсе. Примерно вот так:
И это решит 95% проблем типичного стартапа. Как-то так повелось, что по всему СНГ и его окрестностям на работу набирают зумеров с колоссальным опытом в три года, и они начинают создавать идеальные архитектуры. Да, каждый из вас, как только получает возможность взять на себя хоть малейшую ответственность, сразу вспоминает все прочитанные и не прочитанные книги и пилит свою уникальную архитектуру, непохожую ни на что.
На работе была поставлена задача: в главное веб-приложение нашей фирмы добавить метод формирования бланка в формате PDF «как вот в том микросервисе».
Форма бланка регулярно изменяется, и копировать её в веб-приложение означало нарушить принцип DRY («Не повторяйся») и обречь себя на постоянную двойную работу. Поэтому я решил оставить генерацию бланка в «том микросервисе».
«Тот микросервис» написан на PHP с использованием фреймворка Laravel, содержит большое число доменных объектов, экземпляры которых хранятся в БД MySQL, и имеет развитую систему API для обращения к своему функционалу.
И можно было добавить в него ещё одну точку доступа API, которая бы получала данные и на их основе формировала и возвращала бланк.
Проблема возникла из-за «неприлично» высокой связанности объектов в «том микросервисе». Так, в шаблоне, на основе которого строился бланк, использовались не просто примитивные типы данных, а объект-форма. И шаблон обращался к методам-геттерам этого объекта. А объект, в свою очередь, использовал другой доменный объект в своём конструкторе для заполнения полей.
В далёком Контуровском царстве, в чудесном Фокусовском государстве жила-была дружная команда разработчиков. Денно и нощно они создавали интерфейсы для поиска надёжных контрагентов, возводя величественные «палаты» функциональности и прокладывая пути обновлений. Но однажды, дабы ускорить доставку фич и снизить нагрузку на фронтендеров, было решено привлечь необычных существ — примитивов...
Хабр, привет! Я стабильно пишу здесь о CSS. Мне радостно, что моя работа вам полезна. Но хочется что-то нового. Вызывающего споры. В общем, я пришёл к формату статей в виде вопрос-ответ. Вопросы будут те, что я спрашиваю на интервью. Так что у вас будет повод сказать: «А зачем это надо?».
При составлении вопросов я хотел проверить понимание базовых моментов, которые есть в вёрстке любого проекта. Ещё будут вопросы на знание более редких аспектов и «новинок» в CSS. В общем, я хочу вас завалить, чтобы казаться супер умным! (здесь ирония).
Пожалуйста, не воспринимайте мои вопросы серьёзно. Давайте просто весело проведём время. Плюс попробуем узнать что-то новое. Ведь у каждого вопроса будет мой ответ. И вы тоже можете оставить свой в комментариях. Я обязательно буду их читать.
Так, вы готовы? Давайте посмотрим, что я вам подготовил.
В моих предыдущих статьях (1, 2) я подробно рассматривал, как работает React.memo, а также делился более эффективными подходами к оптимизации производительности с помощью компоновки. Однако для глубокого понимания работы React необходимо разобраться в основном механизме, лежащем в основе всех этих оптимизаций – алгоритме согласования (reconciliation).
Согласование – это процесс, в результате которого React приводит DOM в соответствие с деревом компонентов. Именно этот механизм позволяет реализовать декларативный подход к программированию на React: вы формулируете свои намерения, а React самостоятельно определяет, как выполнить эти намерения наилучшим образом и с наименьшими затратами.
История Kubernetes
7 июня 2014 года был выпущен первый выпуск Kubernetes
Kubernetes позволяет разработчикам самостоятельно разворачивать приложения, а системным администраторам, автоматически отслеживая
и перемещая эти приложения в случае аварийного сбоя оборудования
Kubernetes на греческом языке означает «кормчий» или «рулевой» (лицо, держащее рулевое колесо корабля).
Kubernetes использует контейнерные технологии Linux, для того чтобы обеспечить изоляцию выполняющихся приложений. Данные технологии позволяют запускать несколько сервисов на одной хост-машине, не только обеспечивая доступ к разным средам, но и изолируя их друг от друга, подобно виртуальным машинам, но с гораздо меньшими затратами.
Процедура развертывания приложений через Kubernetes всегда одинаковая, независимо от того, содержит ли кластер всего несколько узлов или тысячи. Размер кластера не имеет никакого значения. Дополнительные узлы кластера просто представляют собой дополнительный объем ресурсов, доступных для развернутых приложений.
Основные понятия в Kubernetes
Кластер – это несколько серверов, где нужно развернуть наше приложение.
Под (pod) – минимальный элемент развертывания в Kubernetes, который состоит из одного или нескольких контейнеров, работающих на одном компьютере. Контейнеры внутри пода работают по одному IP-адресу
и могут обмениваться информацией через доступную в контейнере директорию (том, volumes).
Сервисы (Service) – соединяет поды, которые объединяются в группы
с постоянным IP-адресом и балансирует нагрузку между ними.
Продолжаем тему, которая вызывает живой интерес у многих разработчиков и энтузиастов ИИ — создание собственного ассистента на базе ChatGPT или DeepSeek с использованием личной базы знаний.
В этой части статьи мы шаг за шагом превращаем консольную заготовку из первой части в полноценный веб-сервис:
— реализуем авторизацию
— создаём веб-чат с выбором нейросети
— интегрируем всё через FastAPI
— готовим к деплою
Если вы хотите, чтобы ваш ИИ-ассистент выглядел и работал как настоящий сервис — поехали!
Уже на этой неделе, 25 апреля в пятницу, в Екатеринбурге пройдет DUMP — одна из самых масштабных ИТ-конференций на Урале. В этом году у нас 11 тематических секций, включая новенькую TechLead, отдельный трек для круглых столов и воркшоп от Андрея Цветциха. Рассказываем детальнее о программе:
Backend — пройдет в двух параллельных треках. Будет больше докладов, Андрей Цветцих проведет воркшоп «Паттерны асинхронного взаимодействия в распределённых системах», Юля Волкова поможет справиться со страхом триггеров, а Максим Стаценко покажет, как сделать максимально дешёвый Statefull процессинг с 1кк RPSа. Также обсудим за круглым столом, кто должен исправлять срочные баги, если работа над проектом уже закончилась...
В этой статье мы рассмотрим:
- Как работают агрегаторы ресторанов?
- Какие перспективы у этой бизнес-модели на рынке foodtech?
- Какой функционал необходимо добавить в приложение для ресторанов?
- Как убедить заведения в преимуществах интеграции с агрегаторами?
- В чем особенности разработки и масштабирования приложений-агрегаторов?
А также поделимся инсайтами из нашего опыта разработки агрегаторов для ресторанов и расскажем, как создать приложение для заказов еды и систему бронирования столов.
