Последние сообщения

Кстати интересно, а если у меня например очень сложный функционал который нужно дописать, например разработать свою биллинговую систему для маркетплейса? Как тут происходит процесс? 

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Игорь Симонян

Спасибо за ответ, очень подробно расписали, но мне интересно как проходят сами процессы, не обязательно в ДСТ, а вообще как это обычно бывает в целом у всех, для общего так сказать развития и понимания 

Виталий Науменко

Такое дело, тогда уже зависит от команды и выстроенных процессов.

Прототип желателен, чтобы видеть итоговую картину, что должно получиться на выходе, например, ты из ТЗ понял, что какая-то форма будет сохраняться целиком по кнопке сохранить, а на самом деле заказчик имел в виду, что форма будет сохраняться автоматически по одному полю при его изменении. От этого будет разный код, разное апи, поэтому прототип желателен.

Про сами процессы:
Если пишет один человек, проще сначала сделать бекенд, потом писать фронт под готовое апи.
Если пишут два человека, можно создать апи-пустышку с захардкоженными данными, тогда одновременно работать могут начать и фронт и бек специалисты. Ставят такую заглушку, если бекенд делается долго, надо данные откуда-то еще перекачать или еще какие сложности, обычно быстрее сразу просто апи сделать.
В некоторых командах контракт согласовывают бек и фронт вместе (или кто-то главный над ними, который раздает потом задачи).
Иногда на фронте процесс выстроен таким способом, что пишутся тесы (не шутка). Там делаются моки запросов к апи и фронт пилится в отрыве от бекенда. Контракты, разумеется, должны так же совпадать

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

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Игорь Симонян

Спасибо за ответ, очень подробно расписали, но мне интересно как проходят сами процессы, не обязательно в ДСТ, а вообще как это обычно бывает в целом у всех, для общего так сказать развития и понимания 

И тут я не совсем понимаю, есть макет и исходя из этого макета backend и придумывает структуру хранения данных в БД, или как оно работает?

Виталий Науменко

Эти вещи довольно слабо связаны. Обычно как и ответили выше, читают ТЗ и из него уже примерно понимают, что нужно системе. Дизайн может повлиять на пару таблиц, из которых можно будет получить даные и то не факт.

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Я обычно поднимаю ещё один контейнер с nginx, который слушает порты 80 и 443 на хосте и раскидывает запросы в разные контейнеры по доменам или по локейшенам.

Чтобы не прописывать вручную в hosts домены, когда сервисов много, использую nip.io

Такие же домены назначаю как hostname контейнерам, для единообразия.

А чтобы не писать однотипные конфиги nginx — hub.docker.com/r/jwilder/nginx-proxy/

Для управления самоподписанными сертификатами для разработки есть github.com/FiloSottile/mkcert

Используемые практики:

1. внутренняя зона DNS и внутренний CA для выпуска wildcard сертификатов.
Внешняя DNS зона и Let's encrypt или купленный wildcard сертификат для нее.

>> Frontend работает на localhost:3000.

>> API доступен по адресу localhost:3001.

Эти адреса действуют вне Docker. Внутри контейнера они используют формат «service_name:port». Это позволяет приложениям взаимодействовать друг с другом без обращения к внешним сервисам. Для упрощения можно использовать алиасы в файле docker-compose.yml.

Обратите внимание на этот важный мануал: docs.docker.com/compose/how-tos/networking/.

Если SPA не подходит из-за требований к SEO, можно рассмотреть гибридный подход. Например, использовать SSR (Server-Side Rendering) или статическую генерацию страниц через современные инструменты вроде Next.js или Nuxt.js. Они позволяют рендерить HTML на сервере, сохраняя SEO-дружественность, но при этом дают гибкость в разработке интерфейсов на React/Vue.

В вашем случае, если DST Platform генерирует HTML на бэкенде, можно вынести фронтенд-логику в отдельные модули. Например, оставить базовую разметку в шаблонах DST, а интерактивные элементы (формы, фильтры) реализовать через изолированные JS-компоненты, подгружаемые асинхронно. Это сохранит SEO и упростит поддержку.

Для полного разделения фронтенда и бэкенда можно разработать API на DST Platform (если его нет) и подключить к нему фронтенд на любом фреймворке. Но тогда SSR становится обязательным — иначе поисковики не увидят контент.

DST Global

Отличное решение оптимизации без потери SEO, но я бы посоветовал еще практичный компромисс: 

Полный переход на JS-сборку шаблонов без потери SEO возможен только с SSR или статической генерацией, но это потребует серьезных изменений архитектуры. Если задача — минимизировать риски, лучше оставить генерацию HTML на DST Platform, а фронтенд-логику вынести в микросервисы.

Например, можно разделить код :

— Бэкенд (DST + ASP) отвечает за данные, рендеринг базового HTML и API.

— Фронтенд подключается как отдельные JS-бандлы (например, через Webpack) только для интерактива (слайдеры, формы).

Такой подход сохранит SEO (основной контент в HTML) и упростит разработку. Для более глубокой интеграции можно использовать Astro — он позволяет смешивать SSR и статику с островной архитектурой, где JS загружается только для нужных элементов.

Если же хочется современный стек без головной боли с SEO — Next.js с адаптерами под DST API будет лучшим выбором, но потребует переработки шаблонов. 

Если SPA не подходит из-за требований к SEO, можно рассмотреть гибридный подход. Например, использовать SSR (Server-Side Rendering) или статическую генерацию страниц через современные инструменты вроде Next.js или Nuxt.js. Они позволяют рендерить HTML на сервере, сохраняя SEO-дружественность, но при этом дают гибкость в разработке интерфейсов на React/Vue.

В вашем случае, если DST Platform генерирует HTML на бэкенде, можно вынести фронтенд-логику в отдельные модули. Например, оставить базовую разметку в шаблонах DST, а интерактивные элементы (формы, фильтры) реализовать через изолированные JS-компоненты, подгружаемые асинхронно. Это сохранит SEO и упростит поддержку.

Для полного разделения фронтенда и бэкенда можно разработать API на DST Platform (если его нет) и подключить к нему фронтенд на любом фреймворке. Но тогда SSR становится обязательным — иначе поисковики не увидят контент.

Да в общем то нет. Есть более сложный путь. Адаптивная эволюция вашей полной страницы, к которой ява скрипты добавляют интерактив и полностью заменяют серверную логику.

Странное утверждение, учитывая, что SPA-сайты без особых проблем можно рендерить на сервере для первоначальной загрузки. Для поисковых систем такой сайт ничем не будет отличаться от любого другого. Если SPA на React, то все подобные проблемы решает NextJS. Для других фреймворков тоже есть готовые решения для SSR (server side rendering).

SPA + SSR полностью решает Вашу проблему. 

DST Board представляет собой современное и универсальное решение, которое значительно упрощает процесс запуска и управления доской объявлений, позволяя предпринимателям сосредоточиться на стратегических задачах, а не на технических деталях. Благодаря встроенным инструментам и интуитивно понятной панели управления, пользователи могут легко настраивать и расширять функционал платформы без необходимости обращения к специалистам или разработчикам, что существенно сокращает сроки выхода проекта на рынок и снижает издержки. Эта платформа особенно ценна для начинающих бизнесменов, которые ищут быстрый и надежный способ реализовать свои идеи, не тратя время и ресурсы на сложную разработку сайта. В то же время, DST Board отлично подходит для уже действующих торговых площадок, предоставляя расширенные инструменты аналитики и автоматизации, что помогает повысить эффективность работы, улучшить взаимодействие с клиентами и укрепить позиции на рынке. Для крупных сетевых компаний платформа становится мощным инструментом для масштабирования бизнеса, благодаря гибким настройкам, возможностям интеграции и расширения функционала, что делает ее незаменимым помощником в условиях высокой конкуренции. В целом, DST Board — это не просто готовое решение, а полноценная экосистема, которая объединяет все необходимые инструменты для успешного развития и роста бизнеса в сфере объявлений, обеспечивая стабильность, гибкость и возможность адаптации под любые требования.

Определённо могу сказать что использование DST Board в качестве платформы для доски объявлений открывает перед предпринимателями широкие возможности для быстрого и эффективного запуска собственного проекта без необходимости погружения в сложные технические детали. Эта система создана с учетом современных требований рынка, что делает ее особенно привлекательной для тех, кто ценит скорость, надежность и простоту в управлении. Благодаря богатому функционалу и встроенным инструментам аналитики, пользователи могут не только размещать объявления, но и получать ценные данные о поведении аудитории, эффективности рекламных кампаний и предпочтениях клиентов, что позволяет принимать более обоснованные решения и корректировать стратегию в реальном времени. 

Для нас оказалось важной особенностью что DST Board является универсальной: платформа легко адаптируется под нужды как начинающих стартапов, так и крупных торговых сетей, что делает ее универсальным инструментом для бизнеса любого масштаба. Для новых участников рынка это возможность быстро выйти на рынок и начать привлекать клиентов, не тратя время на разработку и настройку сложных систем, а для уже существующих площадок — инструмент для повышения эффективности, автоматизации процессов и расширения клиентской базы. В конечном итоге, DST Board становится не просто платформой, а полноценной платформенной экосистемой, которая помогает бизнесу расти, развиваться и оставаться конкурентоспособным в условиях динамично меняющегося рынка.

Ок спасибо, не знал, посмотрю внимательнее