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

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

Главным аргументом в пользу криптопроцессингового сервиса MEEG будет автоматизация всех процессов платформы. Любой покупатель сможет выбрать удобную ему криптовалюту из предложенных и оплатить желаемый товар. Деньги будут защищены от резких скачков и останутся в безопасности.

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

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

Кстати в Клубе есть подробная статья "Как принимать платежи в криптовалюте в маркетплейсе или в Интернет-магазине на базе DST Platform" думаю там есть все ответы на Ваши вопросы.

Есть еще 2-уровень технологии типа лайтинг, тут чтобы удостовериться что оплата прошла, нужно будет маркетплейсу вставать прямым узлом посредником (требование такое выкатить), в принципе это не плохо (но не гибко), заодно через это посредничество можно и комиссии собирать за использование маркетплейса но лично я считаю в принципе маркетплейс лишним, это должно быть что то децентрализованное, с публикацией товаров/услуг в какой-нибудь dht сети (или той же лайтинг, так как сама сеть может использоваться для передачи сообщений, даже чат/форум такой есть).

Совершенно 'не понимаю' зачем маркетплейсу участвовать в финансовой жизни своих участников, если используется криптовалюта… рекламная площадка?

Сами участники пусть переводят друг другу монеты со своих кошельков, а чтобы маркетплейс понимал, когда оплата произведена, пусть участники (те кто ждет приема монет) сообщают маркетплейсу какие у них адреса, он смотрит в блокчейн и если появились транзакции на нужную сумму (в этом случае получатель должен заводить специально адрес для этого, что нормально для bitcoin но неудобно для erc20 так как там 1 адрес = 1 человек, и если хочешь больше — везде нужно для комиссии эфир складывать). Можно попросить отправителя сообщить id транзакции, тогда все будет универсально, проверяем у этой транзакции получателя и сумму и если совпадает с ожидаемой — считаем что оплата прошла.

Handless CMS это любая CMS, которая имеет админку и только API для доступа к данным, она не занимается отображением сайта в классическом понимании. API такой CMS обычно REST. Все остальное это уже приплел маркетинг.

На самом деле изначально этот подход очень хороший, но DST Platform захотели быть в тренде и решили что они теперь тоже будут Handless CMS, т.к. у них тоже есть API. С технической точки зрения вроде даже верно, но идея Handless CMS исходила из того, чтобы сделать DST Platform более легковесными и чтобы они не становились центром всей архитектуры, а были лишь небольшим сервисом.

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

Я не совсем про конкретику, а про общее поле. Сайты стали перегруженные, и все новые подходы не дают простоты ни для разраба ни для клиента. Редко когда встретишь чистый html + сss. Чаще всего я вижу пару десяток обращений для всяких скриптов и хранение контента в JSON и сбор его на клиенте это уже считается нормой, но серверу легче, да, он не делает 1 запрос к БД для получения кешированной статической страницы в чистом html.

Касательно вуе/ангуляра/реакта и статики на них — все равно у нас остается тонна JS + CSS, которые будут слеплены в один пельмень лежавший в холодильнике в +10. Без них сейчас ни одна страница не обходится. Туда-же можно закинуть jekyll — мы избавились от обращения к БД, но добавили лишнего рендеринга клиенту.

PS: Можете рассматривать как скрип старого кодера делающего в своей жизни только простенькие сайты.

В моём понимании это не про статику. На статичном сайте может быть хоть десяток счетчиков, при желании можно ее и на react/vue/angular написать. Статичный он в первую очередь потому, что данные необходимые для отображения основного контента страницы находятся в файлах, а не запрашиваются через 17 рест запросов у трех разных бэкендов. Возможно мы про разное, я в первую очередь подразумеваю подходы типа hygo/jekyll

ИМХО: Нормально написанные статичные сайты кончились когда к любой страничке клиенту стало модно тащить сотню-другую килобайт яваскрипта, слепленный для всех систем/хуков/разрешений css, а потом все это рендерить через кучи вложенных элементов с десятками классов каждому. Ах да, еще нужно слушать каждое нажатие клавиши и движение мыши…

Вот и получаем ФБ, хабр или любой из сайтов майкрософта где можно повесится от обилия «упрощений» где сначала страдает сервер, потом сеть, а потом и сам клиент.

А ресурсы, потребляемые такой системой, не минимизируются?

Вот везде, везде говорят про оптимизацию трудозатрат разработчика и очень редко про оптимизацию результирующего кода.

Алексей Девятов

Мне кажется тут можно долго приводить полярные примеры, но в среднем, нормально написанный статичный сайт как минимум проще отдавать серверу. Со стороны клиента, когда нужно открыть одну-две страницы, нагрузка также будет меньше, чем при загрузке монолитной spa.

А ресурсы, потребляемые такой системой, не минимизируются?

Вот везде, везде говорят про оптимизацию трудозатрат разработчика и очень редко про оптимизацию результирующего кода.

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

Новое поколение CMS решает проблему управления контентом с использованием различных платформ. Теперь содержимое создается, хранится и редактируется независимо от технических решений, используемых для его представления на клиентском оборудовании (браузере, смартфоне, умных часах).

Headless CMS — тело без головы

Логика традиционных CMS объединяет бэкенд- и фронтенд-части одной системы. Контент в данном случае оказывается связан с конкретными технологиями, архитектурой и шаблонами клиент-серверного приложения.

Headless CMS — принципиально иная система управления. Как правило, она отвечает только за универсальное содержимое, которое может использоваться на любых платформах. Бэкенд («тело») при таком подходе не связан с фронтендом («головой»).

Логика Headless CMS такова, что к «телу» при необходимости можно приставлять разные «головы». Это позволяет использовать один бэкенд для управления сайтом (или сайтами) и мобильным приложением, а также автоматизировать распространение контента по всем доступным площадкам и устройствам.

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

Как это работает

Как уже было сказано, Headless CMS предполагает управление только контентом независимо от интерфейса, в котором он будет использоваться (представляться конечному пользователю).

Система управления строится с нуля и используется, в первую очередь, как хранилище контента и набора инструментов. Она обеспечивает административный интерфейс для создателей контента, их совместной работы над содержимым. Если предусмотрена возможность оставлять комментарии, заявки, создавать пользовательские анкеты или задавать настройки аккаунтов, эти данные также могут храниться в системе, модерироваться и редактироваться персоналом.

Содержимое системы хранится в поддерживаемой ею базе данных (PostgreSQL, MongoDB, SQLite, MySQL и MariaDB в Strapi). Обмен данными чаще всего происходит в «универсальном» формате JSON, что позволяет подстраиваться под любой новый фронтенд. Передача осуществляется через внешний API: RESTful или GraphQL.

Клиентское приложение отвечает за взаимодействие с пользователем (дизайн, интерактивность, сбор данных). Для манипуляций с данными используется API.

Преимущества Headless CMS

Главная ценность подхода, реализованного в Headless CMS — омниканальная готовность. Контент в универсальном формате можно использовать на сайте, в мобильном приложении, в интерфейсе различных цифровых устройств. Это расширяет возможности бизнеса, позволяет гибко использовать разные решения (интегрируя их по очереди или сразу задействовав все необходимые).

Снижение затрат на разработку — второе важное преимущество. При определенных условиях Headless CMS дешевле в установке и настройке. Разработчикам не требуется осваивать систему управления «от и до», достаточно разбираться в административном интерфейсе и API.

Ускорение реализации новых проектов — тоже немаловажный плюс для бизнеса. Благодаря гибкости использования контента, в Headless CMS процесс запуска сайта или приложения занимает меньше времени. Кроме того, индустриальные стандарты RESTful и GraphQL обеспечивают быстрый старт при развертывании нового проекта: разработчикам не требуется закладывать архитектурные основы и осваивать тулинг вокруг этих технологий.

Для пользователей административной панели важно удобство работы в системе. Централизованное управление облегчает взаимодействие с разными платформами. Можно добавлять и редактировать контент, управлять настройками в одном привычном административном интерфейсе.

Для бизнеса, оперативно реагирующего на изменения, большое значение имеет простая масштабируемость системы управления контентом. Статически сгенерированный контент от CMS легко поддается масштабированию через CDN.

Содержимое легко переносится в новые интерфейсы. Например, для реализации приложения для iOS, при наличии web- и Android-версий, не требуется создавать новый бэкенд — к существующей схеме просто добавляется еще одно клиентское приложение.

При этом разработчики на любом языке программирования (Ruby, PHP, Java, Swift) могут использовать API при манипуляциях с системой, решая таким образом проблему несовместимости разных языков в одном продукте. Это дает возможность задействовать новейшие технологии и креативно подходить к процессу разработки.

Для Headless CMS характерна повышенная безопасность. Поскольку с пользовательской стороны доступны только статически сгенерированные файлы, а обработка запросов значительно упрощена, «сломать» этот процесс сложнее и риски атак сокращаются.

В первую очередь важно то что платформа перейдет на безголовую (headless) архитектуру, что предполагает разделение внешнего интерфейса (пользовательского интерфейса) от серверной части (логика торговли и обработка данных).

Иван Терешенко

Можно по подробнее, что значит безголовая, как это скажется на функционале и возможностях? 

В первую очередь важно то что платформа перейдет на безголовую (headless) архитектуру, что предполагает разделение внешнего интерфейса (пользовательского интерфейса) от серверной части (логика торговли и обработка данных).

Хорошее решение, вот только бы еще было бы еще подешевле 

Алексей Девятов

Чем профессиональнее решение тем он дороже, так что все логично, тем более надо сказать сейчас цена значительно ниже чем была несколько лет назад, по факту DST Маркетплейс сейчас стоит в 2 раза дешевле, раньше по факту в продаже был только Энтерпрайз.