Комментарии

Мы пришли к такому взгляду на DWH как на продукт, у которого есть два типа пользователей:

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

Те, кто используют данные. Менеджеры продукта и аналитики, которые ищут данные, проверяют гипотезы и отвечают на вопросы бизнеса.

Сейчас мы собираем данные в DWH более чем из сотни внутренних и внешних источников. Наше хранилище выросло до 1 Pb, мы по-прежнему используем Vertica, к которой добавился ClickHouse, куда мы вынесли весь ClickStream. Для визуализации используем Tableau, сейчас в нём порядка 3300 отчётов. У нас 300 внутренних пользователей и около 50 сервисов, которые получают и используют данные из хранилища автоматически.

То, куда мы хотим двигаться дальше, можно описать в двух словах: демократизация аналитики. Мы хотим, сделать так, чтобы работа с данными и принятие решений на данных было как можно проще для высокоуровневых пользователей. Для этого мы будем продолжать развивать и продвигать концепцию self-service и доведём ETL и систему пересчётов до того уровня, чтобы все пользователи могли сделать простую задачу самостоятельно.

Другая важная проблема связана с доверием к данным. Мы хотим сделать понятный и прозрачный критерий доверия, который будет иметь численное отражение в системе. Третье направление, куда мы идём, связано с realtime-аналитикой. Мы уже очень хорошо умеем строить аналитику T-1, но этого недостаточно. Мы сняли технические блокеры с этой задачи, внедрив ClickHouse, но дальше предстоит внедрение продуктового применения наших решений.

Мы планируем развивать аналитику под ключ, ведь Авито ещё больше растёт, и у нас появляются всё более крупные бизнес-юниты. У них могут отличаться SLA и они могут требовать своей инфраструктуры. Также хотим развивать внутреннюю IDE для работы с данными, написания запросов и скриптов. А чтобы бороться с проблемами, которые вызывают рост и масштабирование, а также поддерживать отказоустойчивость инфраструктуры, планируем рассмотреть разные облачные решения и работу с холодными данными из других систем.

Хочется поблагодарить компанию ДСТ за разработку потрясающего сайта! Великолепный сервис, вся команда очень ответственная и дружелюбная! Работа была выполнена на все 100%! Все сделали в сроки, были внимательны к пожеланиям! Отдельно хочется сказать спасибо Алексею Гуржиеву, с которым мы были на связи. Очень вежливый, грамотный и ответственный! Мы очень довольны и будем дальше сотрудничать!

Благодарим компанию DST Global, которая помогала нам как в продвижении, так в адаптации и доработках сайта. Положительное впечатление о команде и о проделанной работе. Оперативная реакция, лояльный и гибкий подход, внимание к пожеланиям и особенностям заказчика. Планируем продолжать сотрудничество и совместно открывать новые направления.

Благодарим компанию DST Global, которая помогала нам как в продвижении, так в адаптации и доработках сайта. Положительное впечатление о команде и о проделанной работе. Оперативная реакция, лояльный и гибкий подход, внимание к пожеланиям и особенностям заказчика. Планируем продолжать сотрудничество и совместно открывать новые направления.

Прямой зависимости между хостингом и результатом продвижения ИМХО быть не должно. Но, в целом для сайта, конечно, лучше, если он будет расположен на российском сервере — меньше задержки, выше скорость загрзуки страниц… А там и до влияния поведенческих факторов на результат в выдаче недалеко, хотя пока еще далеко все-таки;)

Похоже мы просто друг друга не понимаем.
АПИ, по факту — это просто способ дёрнуть нужный функционал в бэкэнде(вот по такой вот ссылке находится такая функция, она принимает такие запросы с такими параметрами и возвращает такой ответ), это не конкретный модуль, это всего лишь способ получить нужный функционал. Теперь, вместо того что бы дёрнуть функционал напрямую — мы перенаправляем(на сервере, не на клиенте) все вызовы либо в общий модуль, занимающийся КОНКРЕТНО валидацией поступивших данных, либо в кусок кода на JS, который отвалидирует данные и отправит дальше, в «настоящий» back-end. Валидация этого плана — чисто формальная фича, типа «вот это поле — должно быть телефоном, вот это — мылом, а вон то — обязательно к заполнению». Если эта валидация проходит — дальше на такую фигню данные валидировать не нужно. При этом напрямую, в обход валидации на JS — до бэкэнда не достучатся.

Для чего такие сложности? Для того что бы реализовать фронт, провалидировать форму до отправки, а потом, на доверенном участке — провалидировать форму после отправки. Код един для фронт- и бэк-, просто бэку мы доверяем, а фронту — не очень. Код не пишется в итоге, он копипаститься с недоверенного на доверенное место.

По факту — это и становится «новым» апи, потому что все запросы проходят через него, и дальше — в быстрый и надёжный бэкенд.
В итоге схема остаётся прежней — фронт -> апи -> бэкэнд, всё методы остаются прежними и по такой ссылке остаётся необходимый функционал, просто данные проходят через призму валидации.
В итоге в схеме функционирования ничего не меняется, кроме того что появляется прослойка на JS, созданная для того что бы ускорить разработку бэкэнда.

Похоже что Вы просто рассматриваете АПИ как отдельный модуль, через который «ходят» запросы. В этом проекте АПИ(по крайней мере со взгляда фронт-энд разработчика, я не лезу в бэкенд вообще и для меня он просто чёрный ящик с доками) — просто ссылки по которым доступен определённый функционал, он выполняет только одну какую то свою функцию и функционирует независимо от других модулей, расположенных по другим ссылкам(на сколько мне известно). Т.е теоретически может отвалиться одна половина сайта, но исправно работать другая.
PS даже хз как ещё более подробно написать, дальше уже наверное нужно статью с примерами накатать.

Дык о чём я и говорю! Во фронт-енде по понятным причинам нужны валидации. В публичном API по тем же самым причинам — тоже нужны те же самые валидации. А затем, возможно, и на бекенде. Но заодно в API мы предусматриваем случай «бекенд недоступен», а во фронт-енде: «API недоступен». Всё это влечёт за собой дополнительный код, который я и назвал усложнение\удорожание процесса разработки.

Ну да. Можно посылать запросы к /api/название_апи, и чисто теоретически — написать свой фронт-энд, с преферансом и поэтессами.
Но в случае с прокси-прослойкой до «реального» бэкэнда не достучаться напрямую, только через проксю.

А API от бэкенда торчит наружу (в Интернет) в вашем проекте?

Не путаете понятие «упрощение архитектуры» с «упрощением разработки»? Архитектура, понятное дело, слегка усложнится, т.к появляется дополнительный слой. Но по факту этот самый слой не видно(в идеальной ситуации, когда никаких задержек и ошибок этот слой не несёт) т.к вся его суть — провалидировать данные и пустить дальше, в ответе вернуть ответ от «настоящего бэкэнда».

Хз, возможно это чисто субьективно, но в текущем проекте я работаю на пару с бэкэнд-прогером и у нас веб приложение -> апи -> чёрный ящик бэкэнда(с моей стороны). Так вот, этот самый бэкэнд-прогер вместо того что бы заниматься своими обработчиками и бизнес-логикой, плюс чисто бэкэндовыми вещами(оптимизация нагрузки, стабильность и т.д) пишет всякую муть вроде валидации поступающих данных и корректными ответами на неправильные данные. Кроме того, всё это я уже написал на своей стороне, что бы обычный клиент не пропихнул левые данные. Правда на текущий момент мы всё же не ввели этот слой, т.к сроки поджимают, а изначально не задумывались. Но чисто как мыслительный эксперимент — решает текущие проблемы, с которыми мы сталкиваемся.

PS и трудозатраты не увеличиваются. По факту эта фича внедряется в любой бэкэнд, просто вместо запросов на index.php(к примеру) запрос пойдёт на урл, за который отвечает node.js, а после — в зависимости от реферера — пойдёт на нужное апи в «настоящий» бэкэнд. Одна функция, по факту.

Действительно ли это будет упрощение разработки? Мы и понятие API вводим, и отдельный сервер-прокси на JS, код по сборке все этого счастья на клиенте. На первый взгляд кажется, что кол-во кода ощутимо увеличится, в довесок к введению новых сущностей. Не очень понятен профит, который мы получим, пойдя на такие трудозатраты.

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

Ещё интересный вариант в плане упрощения разработки — javascript(front) -> javascript-api(back), он же — прокси с валидацией в настоящий бэкэнд -> бэкэнд.

Собственно фронтэнд и бэкэнд полностью разделены, при этом использование JS в качестве прокси позволяет существенно снизить затраты на валидацию полей(собственно, объёмная часть АПИ и составляет корректная валидация и нормальные ошибки), т.к код для валидации един. Ну и там всякие разные бонусы, типа можно клиенту отдавать сразу готовый html(в совершенно идиотском случае если JS у человека не работает), что в случае с graceful degradation не должно особо отразиться на функциональности.

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

Многие нам тоже советовали использовать натив или гибрид но на текущий момент многие компании используют кроссплатформенные решения, кто-то уже всерьез подумывает перейти на них в ближайшем будущем. Это не только вендоры самих решений, как, например, Facebook со своим React Native, на котором работают приложения Facebook и Instagram, но и другие крупные игроки рынка, у которых имеются продукты, например, на Flutter – Alibaba, Philips Hue, Hamilton, Tencent, Grab, Groupon и другие. Так что мы за — кроссплатформенное решение которое позволяет охватить сразу две операционные системы, iOS и Android, одним кодом. Она не предполагает написания кода на родном языке программирования, однако обеспечивает почти нативный опыт благодаря интерфейсу визуализации с использованием собственных элементов управления.

Хорошая статья. Но если объективно то рассмотрим плюсы и минусы Flutter как платформы для разработки продукта:

Плюсы

короткий time-to-market;
производительность приложений наравне с нативными решениями;
общая стоимость разработки ниже аналогичного решения с нативными приложениями;
поддержка единой кодовой базы;
снижение затрат на исправление багов и добавление новой функциональности.

Минусы

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

Язык программирования Dart, который Google называет “оптимизированным под клиента”, был представлен в 2011 году. Это адаптивный объектно-ориентированный язык, который считается относительно легким для изучения по двум причинам: во-первых, он использует C/C++ и Java; во-вторых, на официальном сайте Dart можно найти обширную и довольно простую документацию. Также стоит отметить, что Dart поставляется с большим хранилищем Flutter-совместимых программных пакетов, позволяющих сделать ваше приложение еще более сложным.

Кроссплатформенные приложения на Flutter разрабатываются аналогично нативным в общепринятых IDE – Android Studio и XCode. Как дополнение, разработчикам доступен hot-reload кода, что ускоряет запуск приложения во время разработки. Кроме этого, процесс публикации ничем не отличается от нативных – собранные дистрибутивы подписываются и загружаются в магазины приложений.

Хотелось бы добавить что на Битрикс сделать маркетплейс нельзя, они больше запустили рекламу на это, на самом деле на Битриксе нет даже кабинета поставщика, точнее есть модуль на это, но там нет даже самых стандартных, обычных функций, например управления доставкой или устанавливать комиссии с продаж, короче платформ для создания настоящего маркетплейса вообще почти нет

Хотел бы добавить в эту тему также свой комментарий, который уже оставлял тут в сообществе:

В период пандемии бесповоротно решили открыть маркетплейс. Встал вопрос о выборе движка.
Конечно же, пришлось изучить огромное кол-во материалов, опросить знакомых ITишников.
В итоге остановились на DST Platform, оптимальное соотношение цена-качество.
Не скроем, было страшновато, поэтому изначально попробовали поработать с демо-версией.

Спустя месяц приняли окончательное решение запустить сайт на данной платформе.
Что понравилось:
— все просто и понятно
— все подробно описано, бесплатная поддержка если что
— базовую SEO оптимизацию можно провести самостоятельно

Порадовало наличие функции экспорт/импорт, для нас это важно у нас более 300 000 товаров – благодаря ей выгрузка товара на сайт заняла совсем немного времени.
Конечно же, в ходе работы понимаем, что не хватает тех или иных функций, конкретно заточенных под нашу специфику, приходится дорабатывать под себя.
Отсюда вытекает еще один минус-сложно определить бюджет проекта.
В целом выбором довольны. Для нас это оптимально.

Использую DST Platform около года и очень довольна. В коробке имеется весь функционал для быстрого запуска своего маркетплейса. Основным условием при выборе платформы e-commerce для меня была возможность работы без навыков программирования. И с этой задачей DST Platform справился на 100%.

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

Единственным минусом считаю «тяжеловесность» сайта и как следствие довольно высокую стоимость сервера. В целом, качество=стоимости, рекомендую всем данный движок.

В период пандемии бесповоротно решили открыть маркетплейс. Встал вопрос о выборе движка.
Конечно же, пришлось изучить огромное кол-во материалов, опросить знакомых ITишников.
В итоге остановились на DST Platform, оптимальное соотношение цена-качество.
Не скроем, было страшновато, поэтому изначально попробовали поработать с демо-версией.

Спустя месяц приняли окончательное решение запустить сайт на данной платформе.
Что понравилось:
— все просто и понятно
— все подробно описано, бесплатная поддержка если что
— базовую SEO оптимизацию можно провести самостоятельно

Порадовало наличие функции экспорт/импорт, для нас это важно у нас более 300 000 товаров – благодаря ей выгрузка товара на сайт заняла совсем немного времени.
Конечно же, в ходе работы понимаем, что не хватает тех или иных функций, конкретно заточенных под нашу специфику, приходится дорабатывать под себя.
Отсюда вытекает еще один минус-сложно определить бюджет проекта.
В целом выбором довольны. Для нас это оптимально.

Если кратко то — тремя наиболее популярными шаблонами проектирования являются MVC, MVP и MVVM. MVC означает модель, представление и контроллер, MVP означает модель, представление, презентатор, а MVVM означает модель, представление и модель представления.

Хорошо, об MVC уже слышала и даже более того работала. Но что есть кроме MVC?