Можно, но не нужно. Технологически у них такие-же сертификаты, но срок действия у них короткий, и это не просто так, а специально). Постоянно бегать и получать новые сертификаты, заливать файлики и т.п. - геморно. Раз в год тоже не очень, тоже можно забыть, проморгать, и т.п. Что регулярно бывает у разных сайтов. Но вот когда пару месяцев всего, то еще нуднее. Тогда зачем? За тем, что этот процесс автомазитируется. Один раз нажал кнопочку "получить сертификат", и всё. Пока хостинг не меняешь, сервер уже сам будет обновляться когда надо. В этом вся суть. А то что сертификаты с более коротким сроком жизни меньше подвержены компрометации (в том плане что если увели то быстрее устареет), и прочие моменты, так это уже попутно. Бонусом. Создать сложные условия для ручной работы, и легкие для автоматической, чтобы стимулировать автоматический вариант. Поэтому и советую решать на уровне хостера. Ну или сервера, если свой сервер.
Не то чтобы прям совсем плохо, но есть ограничения. Плюс сегодня бесплатно, завтра платно. Плюс я честно плохо помню, с Wosign это они аффилированы или нет? Даже если и нет, то их статус явно менее надежен чем LE.
У них чуть другая идеология. Очень желательно брать хостинг умеющий их сертификаты (есть плагины для всех популярных контрольных панелей).
Я всегда в таких дискуссиях привожу один пример. Он очень упрощенный, но смысл уловить можно. Израиль экспортирует черную икру. Израиль. Черную икру. Которая некошер. Но это не мешает иметь свои рыбзаводы. Так вот, почему я про икру всегда начинаю? Один из успешных израильских стартапов (про стартап-инкубаторы слышали? Так Израиль по всем рейтингам, и в относительных и в абсолютных величинах аккурат второй после силиконовой долины) - рыбка у них растет не 15 лет как обычно, а "всего" 12 лет. Новая метода и всё такое.
А вот теперь вопрос - есть у тебя идея на миллион. И есть знакомый олигарх который верит в идею и готов вложить в нее миллион. Не рублей.
Одно но - прибыль будет через 12 лет. Хорошая. Достаточная чтобы стоило 12 лет подождать. бизнесплан подразумевает что на зарплату тебе денег хватать будет, т.е. 12 лет голодать не нужно будет. Ну и вопрос, да. Что нужно сделать в стране чтобы и ты и олигарх твой рискнули?)
И да, все 12 лет ты будешь работать, налоги платить, проверки терпеть, з/п платить, кадры растить... Чувствуешь?)
низя
Можно.
Всё.
Да, разницы между сертификатами вы не увидите если вы не какой-то ПейПел и т.п. Платные нужны или для сложных технических случаев (вилдкард, много сертефикатов на хосте и т.п.), или для более сильной идентификации и т.п.
Когда в зеленой полоске пишут что это именно та фирма и т.п. Всё.
Кто знаком с работой органов...
Здрасьте приехали.
Радость то какая.
Вот прям спасибо что сроки затянул на пару месяцев, и так и не сел за супер-пупер-проект на базе запросов. Сочувствую тем у кого всё давно написано. Не первое обрезание АПИ на нашей жизни. И не последнее.
А вам уже сто раз сказали, что для простенькой витрины у которой нет 90% вещей которые есть у большинства, и есть уверенность что проект простеньким и останется - ваше решение допустимо. Но вы ведь свой самокат как икону пытаетесь пропихнуть как универсальное решение (см. название темы).
У меня отсутствие повторных покупок это или редкая специфика ниши (единичный товар типа машины или там дизельгенератор, без расходников, без схожих товаров типа как купил телефон потом планшет и т.п.) или неудовлетворенность покупкой. Все остальные - десятки раз обращаюсь. Бывает да, что обращаюсь в несколько и беру в одном, если товар ходовой (бытовая техника, супермаркеты), но это отдельный случай.
Да, я делаю витрины как у вас. С урезанным функционалом. Часто делаю. Но они у меня лежат рядом с визитками. Эдакая продвинутая визитка. Магазин же как правило проектируется индивидуально его функционал никак в статику не запихнуть.
Вы постоянно несете эту чушь, и всё никак не расплескаете.
Давайте на этом месте остановимся. Обоснуйте свою мысль.
Откуда у вас берутся такие задержки? Ну не у вас, а у сферического движка.
Приведите пример.
Типичные страницы магазина:
а) Главная. SELECT from 'page' как везде, индекс все дела, в общем веса нет. Менюшки различные - из кеша, но из без кеша это один, ну два селекта, т.е. десяток милисекунд в очень редком случае пересчета. Всякие тосейлы и т.п. - по одному запросу на каждый вид промоушена, кеш, индекс. Всякие недавние отзывы, анонсы новостей/статей, недавнопросмотренноедругими и т.п. - индекс, кеш, но да, обновляются часто, на нагрузке так и по несколько раз в минуту, так что десяток милисекунд дать могут. Каталог категорий/подкатегорий - может до десятка селектов потянуть, но жестоко закешированно. Если без превью товаров из категории, то оно и не меняется месяцами, с превью - ну если гоняемся за ачивками, то можем инвалидировать кеш не по изменению товаров (что более кошерно), а по TTL + удалению/скрытию товара. Да, в примерах товаров не будет более подходящих новых, скажем час не будет или два, но зато нанооптимизм :) Вроде всё. Самая тяжелая страница. В экзотическом случае может даже 500мс рендерится, но в реальной жизни такое не случается, и как правило вся страница в кеше целиком.
б) Метакатегория. Самая тяжелая страница в принципе. Если у нас у категорий верхнего уровня есть превью товаров, то у нас может быть целая пачка запросов. селект на список всех категорий сабкатегории - индекс, кеш, По одному селекту на каждую категорию чтобы получить N товаров для превью из каждой. (сразу вопрос, как это оптимизировать кто-то предложит изящное решение? Лимит отрезает по всем, а значит у кого-то будет 2N у другого ноль, трехэтажные запросы некошер, ради нанооптимизации выползать из активрекорд не хочется, придумал только денормализация с отдельным булевым параметром у товара topInCategory по которому уже можем делать один селект, а обновлять его в модели при апдейтах/инсертах). После этой пачки запросов у нас уже есть все товары, так что даже если у нас атрибуты и т.п. живут в EAV, то where product_id IN (1,2,3,4,5) и индекс - достаточно быстро отработает. В общем если лень нормальную структуру делать, и всё по дефолту в ORM стоит, то без кеша можно и 200мс рендерить. Но это со всей обвеской которую вы вообще выкинуть хотели). В реальности метакатегории меняют контент редко, так что всё будет в кеше.
в) Категория. Банальный селект товаров с индексом и кешем, потом where in(..) по айдишникам для всей обвески, всё индексируемое, кешируемое и т.п. В особо нагруженных и динамичных местах можно превьюхи товаров рендерить при изменениях и брать готовое из кеша (да, можно отдельную таблицу под это дело сделать, но это реально масштаб амазона/маркета). Тяжелые тут только фильтра. Если они по EAV-атрибутам, то полноценно всё не переиндексируешь, составные индексы на все случаи жизни не сделать. Впрочем в простых магазинах атрибуты можно сделать все в одной таблице, несуществующие дать как NULL и работать будет нормально, до 100к товаров с парой сотен категорий будет без проблем. А там уже индексы делаются без проблем, и всё летает. Всякие менюшки, списки фильтров и т.п. собираемые кучей select distinct под категорию - в кеше. Циферки count-ов для сложных поисковых запросов да, тяжеловаты, но - поисковик сюда не зайдет, а пользователь который уже зашел в поиск вполне подождет даже секунду (много) пока ему будут считать. Хотя я бы эти счетчики выкинул. Не особо они помогают ИМХО, а жрут дофига. Поисковая страница если это не SEO-префильтр генерится обычно полсекунды, в особо тяжелом случае секунду. Поскольку она обычно каноникалом на главную категории клеится, то пофиг с точки зрения сео. Префильтры же полюбому пререндерены на половину, и не хуже чистой категории живут.
г) Карточка - основной контент можно пререндерить при редактировании, можно и по месту. Селект на основные поля, селект на описания и т.п. Селект на EAV (и то только в тяжелом случае), селект под всякие комментарии и отзывы, пару селектов под связи типа сопутствующих товаров и "также покупают" и т.п. Индекс. Превью товара или пререндерино или собрано через where in(...). Индекс, всё такое. 100-200мс в плохом случае.
д) поиск по всему сайту. Ну да, тяжеловат. Ищутся по разным страницам и т.п. Но - ну их в баню. Я вот лично деградирую до поиска по одной таблице страниц, в которой лежат и категории и товары и страницы. Полнотекстовый по заголовку и тексту. Тяжеловат, но пофиг. Один тяжелый запрос можно позволить. Паук туда не заходит. Так что пофиг вообще.
е) всякие статические страницы, фидбеки, корзины и т.п. - вообще пофигу, там десятки мс без кеширования.
Реальность такова, что на тяжелом сайте 99% хитов это десятки мс на рендеринг или проверку кеша, и 1% 150-500мс, плюс 0.01% до секунды рендерится. При этом передача трафика занимает больше времени, особенно статики вроде картинок. Рендеринг обычно упирается в плохую верстку где в хеадере слишком много зависимостей которым место в футере.---------- Добавлено 01.02.2017 в 13:08 ----------
Черт. Не дочитал до этого места и столько написал).
Попробуйте включить логику.
Если вы тысячу страниц рендерите из базы за 60 секунд и тратите на одну страницу 60/1000=60мс, причем с обработкой картинок, то почему другие должны рендерить по 250-500мс причем без картинок? Работа то та же.
Это прям девиз всего топика))))
Естественно. Велосипед имеет право на жизнь. С этим никто не спорит. Спор с тем, что вы свой самокат проталкиваете как ЛУЧШИЙ принцип, хотя автомобили умеют чуть больше чем самокат.
Еще раз - никто не спорит что вам имел смысл сделать свой самокат, все спорят что ваша идея что все транспортные средства должны обходиться без двигателей - неверна.
Покрытие 0%. Потому что это уже шестая версия АПИ из тех что попали в релиз, и третий десяток из тех что не тегались. Для преАльфы - имею право.)
Стабилизирую АПИ и буду покрывать тестами конечно.
Ну или пару джунов возьму в проект.
А нефиг быть заменимым)))
Обычно люди пишут правду, даже когда могут врать. Так что например следить за клиентом или за сайтом очень просто в этом плане.
Не только мылы. Фидбек конфиденциален? В половине случаев да.
Заказ товара в магазине содержит приватные данные? Конечно - там адреса имена, телефоны.. Так что все формы это вопрос времени.
