e_v_medvedev: Ответ по-моему очевиден. Используют стандартную СУБД, чтобы не накручивать свою. Вы ведь по сути над файловой системой надстроите свою СУБД. Зачем? Не понятно. MySQL вообще-то тоже с файлами работает? Что вы нового придумали? Заменили двоичные файлы данных текстовыми (CSV или XML)?
Нет. Он перенес весь функционал в бекофис, а на фронте только статика.
В целом с комментарием согласен, но вот тут непорядок.
Сейчас не 2010-й год, и на такие вопросы нужно отвечать.
Неофициально мониторить - это пожалуйста. Это и есть и будет еще больше.
Но вот предъявить? Это только для совсем простаков проканает.
Мне лично это как-то пофиг, я за последние лет шесть под колпаком у налоговой милиции бывал чуть ли не постоянно, поэтому как не писал раньше назначения платежа, так и не буду.
А вот то, что выписки конкурентов покупать можно будет дешевле - это да. Это печалька. С новыми налоговыми накладными этот рынок актуален :)
_SP_: Вы правда считаете, что он более уязвим, чем коробочное решение ?
Дело не в самописе а в том что вы не знаете броду.
Самопис норм. Не норм когда не хватает опыта. Хороший программист с нуля может решать прикладные задачи в чужой экосистеме, но архитектурные вещи лучше не трогать.
Так то оно понятно что 2/3 сайтов на вордпрессе (по количеству а не по посещалке конечно) легко вскрываемы по вине того кто ставил/настраивал и никого это не парит.
_SP_: Статика имеет и еще один плюс.
В случае взлома, я просто инициализирую новый инстанц у амазона и перезалью туда статику.
Никакой настройки всё это не требует. Мне пофиг и на версию php и на версию mysql,
мне пофиг на настройки БД, на кеширование, мне вообще на всё пофиг, оно будет работать
в стоковом LAMP без каких-либо модификаций. (хорошоб нгикс настроить, но сразу можно
этого и не делать). Вообще нет никаких нужных нетривиальных сервисов для работы.
И ничего со старой системы мне забирать не надо. Никаких баз, никаких данных.
Всё залью по-новой.
Но все эти сложности есть в бекофисе :) И атаковать будут именно его.
Нет, я понимаю что Security through obscurity на которую вы напираете - имеет место. Но - это пока вы один с одним самописом. А если ваше одноразовое решение пойдет в массы, то такой подход губителен.
Я собственно потому пока и не выкатываю свой фреймворк в опенсорс. Выделить часть функционала в платное а основное отдать в паблик не сложно. Но пока я не провел пару рефакторингов да аудит - Security through obscurity меня немного, но защитит). но повторюсь - это нишевое решение. Для очень узкой ниши.
---------- Добавлено 27.12.2016 в 15:41 ----------
burunduk: т.е. вас может положить любой школьник запустив парсер в 1000 потоков?
Школьник с парсером это проблема сервера а не движка.
fail2ban спокойно вынесет школьника. Студента вынесет более внятный файрвол.
А от взрослого DDoS мне и с кешированием не защититься без спецсредств.
Вы не подумайте. Конечно "усё будет". Но не сразу.
Я буду сильно переписывать ORM. Связи сильно переколбашу, а значит жадность лучше добавить попозже. Кеширование тоже требует большого внимания. Втулить как в ВП сделано не проблема, но хочется чтобы инвалидация была прозрачной и TTL использовался лишь для чистки кеша, а не как основной инструмент.
_SP_: 11 секунд на генерацию страницы не видел, врать не буду, но 300 запросов видел, в теме "из коробки", из них 50 (пятьдесят) на генерацию футера (футера, там всякие адреса магазина из базы выбираются итп). И как с таким феррари победить ?
У меня сейчас сотни полторы запросов на страницу в моем движке.
Ни жадности, ни кеширования. Не парюсь потому что в нормативы по скорости влазит, а на будущее - побеждается просто. Есть кеширование.
Жадные связи сократят колво запросов раза в два, а то и на порядок. Кеширование футера, топменю и сайдбара - оставят в буквально 5-10 запросов, при 100% инвалидации кеша. Это допустимая цена за гибкость.
_SP_: Да как-же так ? Даже если ляжет mysql на легком фронте, даже если кончится место на диске, даже если умрет ВСЁ, то статика будет продолжать отдаваться клиентам, заказы собираться и приходить по email итп. (главное чтобы мейл не лег, собственно это всё, что нужно, способность запускать 1-2 сервер-сайд скрипта для отправки почты)
В этом месте я говорил в контексте "запросы на внешний сервер".
Ваша голая статика будет жить и при ядерной войне, да. Собственно это ее ЕДИНСТВЕННОЕ здравое преимущество. Все остальные незаметны в приципе.
Но эта самая статика имеет ограниченный функционал. Бурундук для одного из таких узких мест предложил дергать бекофис или базу. я и возразил, что в таком случае мы теряем единственное преимущество. Всё.
_SP_: Если вам нужны специфические требования, то разрабатывать 100% придется.
Вы просто вынесли свою сложность в бекофис. Если бы бекофис был бы стоковым, то и с тонким клиентом была бы та же лажа)
_SP_: А если четко понимаешь "как надо", то проще ей богу в вакууме писать, дешевле, быстрее.
Так не бывает. Всегда что-то меняется. И в какой-то момент ты понимаешь, что на переделки ушло больше сил и времени чем на создание. Стоимость переделок часто важнее стоимости старта.
_SP_: И заметьте, я не веб-разработчик,
В этом главный вопрос.
Когда у вас будет по 10 магазинов в месяц. Даже не новых. Старых. На обслуживании, допиливании... тогда будет совсем другое ощущение.
Сначала вас взломают. Ну вот просто возьмут и зальют шел. И то что у вас одна статика - вас не спасет. Писать долго. Но взломают. Обязательно взломают.)
с какого перепуга? Бекофис то у нас утолщается. При этом еще есть точка стыковки двух систем. Это тоже дополнительная сложность.
burunduk: гибкость
Без СУБД?)
burunduk: ну и чисто сеошное - это продвигаемо
Без СУБД? Да 90% сеофишек на связях так или иначе завязано.
Нет, можно по сути витрину использовать чисто как кеш, но... что это даст?
Ваш подход по уносу всего оформления в ЖС, а кто не ЖС, тот или робот или ССЗБ -я знаю, и не оспариваю. Не скажу что согласен, но такие эксперименты я тоже делал, и вижу в них здравое зерно. Только муторно... но мы говорим о фронте без БД и жЫрном бекофисе. В чем бонус? Дешевле хостинг разве что. Всё остальное минусы.
Archi66: В Битриксе - вполне все отключаемо и все что нужно, можно дописать. Не видел задач, которые нельзя бы было реализовать (при чем в адекватные сроки)
При этом еще и АПИ изобретать. Да и кучу всяких неожиданностей ловить...
Взяли себе клудфларе за 10 баксов в месяц и ваша "полустатика" уже бонусом готова.
Нет, я и сам задумывался не раз о тонкой витрине.
Разрастание бекофиса тут не главное.
Важнее их относительная автономность.
Если они синхронизируются асинхронно, заливкой файла, дерганием апи или еще как, но не блокируют друг-друга, АПИ их общения простой (да хоть дамп в json одним файлом кидай по фтп), то тут есть много своих плюсов. Но излишняя связность убивает весь смысл тонкого фронта.
Ответ по-моему очевиден. Используют стандартную СУБД, чтобы не накручивать свою. Вы ведь по сути над файловой системой надстроите свою СУБД. Зачем? Не понятно. MySQL вообще-то тоже с файлами работает? Что вы нового придумали? Заменили двоичные файлы данных текстовыми (CSV или XML)?
Нет. Он перенес весь функционал в бекофис, а на фронте только статика.
А в бекофисе у него уже СУБД и всё такое :)
причем, как я понял, русский адалт
Ну как накрутку счетчиков типа САР лить можно))
и есть формальное основание для запроса
С этим редко когда бывает порядок.
В целом с комментарием согласен, но вот тут непорядок.
Сейчас не 2010-й год, и на такие вопросы нужно отвечать.
Неофициально мониторить - это пожалуйста. Это и есть и будет еще больше.
Но вот предъявить? Это только для совсем простаков проканает.
Мне лично это как-то пофиг, я за последние лет шесть под колпаком у налоговой милиции бывал чуть ли не постоянно, поэтому как не писал раньше назначения платежа, так и не буду.
А вот то, что выписки конкурентов покупать можно будет дешевле - это да. Это печалька. С новыми налоговыми накладными этот рынок актуален :)
Это в добрый путь... понадобится дверь вскрывать полагаю .
Ну это в вашем очень узком кейсе можно сделать связь с сервером очень узкой.
А по 100500 задачам которые озвучили - связь будет более толстой, и тут всё и посыпится.
Я ведь не критикую ваше конкретное решение в вашей конкретной задаче.
Мне вполне себе интересно как оно у вас взлетит.
Я говорю лишь о том, что вопрос в заголовке топика неуместен.
Частный простой случай будет работать хорошо. Но в массе он неприменим.
И возражаем мы в основном к вашему тезису что это универсально, а не частный случай.
Вы правда считаете, что он более уязвим, чем коробочное решение ?
Дело не в самописе а в том что вы не знаете броду.
Самопис норм. Не норм когда не хватает опыта. Хороший программист с нуля может решать прикладные задачи в чужой экосистеме, но архитектурные вещи лучше не трогать.
Так то оно понятно что 2/3 сайтов на вордпрессе (по количеству а не по посещалке конечно) легко вскрываемы по вине того кто ставил/настраивал и никого это не парит.
Статика имеет и еще один плюс.
В случае взлома, я просто инициализирую новый инстанц у амазона и перезалью туда статику.
Никакой настройки всё это не требует. Мне пофиг и на версию php и на версию mysql,
мне пофиг на настройки БД, на кеширование, мне вообще на всё пофиг, оно будет работать
в стоковом LAMP без каких-либо модификаций. (хорошоб нгикс настроить, но сразу можно
этого и не делать). Вообще нет никаких нужных нетривиальных сервисов для работы.
И ничего со старой системы мне забирать не надо. Никаких баз, никаких данных.
Всё залью по-новой.
Но все эти сложности есть в бекофисе :) И атаковать будут именно его.
Нет, я понимаю что Security through obscurity на которую вы напираете - имеет место. Но - это пока вы один с одним самописом. А если ваше одноразовое решение пойдет в массы, то такой подход губителен.
Я собственно потому пока и не выкатываю свой фреймворк в опенсорс. Выделить часть функционала в платное а основное отдать в паблик не сложно. Но пока я не провел пару рефакторингов да аудит - Security through obscurity меня немного, но защитит). но повторюсь - это нишевое решение. Для очень узкой ниши.
---------- Добавлено 27.12.2016 в 15:41 ----------
т.е. вас может положить любой школьник запустив парсер в 1000 потоков?
Школьник с парсером это проблема сервера а не движка.
fail2ban спокойно вынесет школьника. Студента вынесет более внятный файрвол.
А от взрослого DDoS мне и с кешированием не защититься без спецсредств.
Вы не подумайте. Конечно "усё будет". Но не сразу.
Я буду сильно переписывать ORM. Связи сильно переколбашу, а значит жадность лучше добавить попозже. Кеширование тоже требует большого внимания. Втулить как в ВП сделано не проблема, но хочется чтобы инвалидация была прозрачной и TTL использовался лишь для чистки кеша, а не как основной инструмент.
11 секунд на генерацию страницы не видел, врать не буду, но 300 запросов видел, в теме "из коробки", из них 50 (пятьдесят) на генерацию футера (футера, там всякие адреса магазина из базы выбираются итп).
И как с таким феррари победить ?
У меня сейчас сотни полторы запросов на страницу в моем движке.
Ни жадности, ни кеширования. Не парюсь потому что в нормативы по скорости влазит, а на будущее - побеждается просто. Есть кеширование.
Жадные связи сократят колво запросов раза в два, а то и на порядок. Кеширование футера, топменю и сайдбара - оставят в буквально 5-10 запросов, при 100% инвалидации кеша. Это допустимая цена за гибкость.
Да как-же так ?
Даже если ляжет mysql на легком фронте, даже если кончится место на диске,
даже если умрет ВСЁ, то статика будет продолжать отдаваться клиентам,
заказы собираться и приходить по email итп. (главное чтобы мейл не лег,
собственно это всё, что нужно, способность запускать 1-2 сервер-сайд скрипта
для отправки почты)
В этом месте я говорил в контексте "запросы на внешний сервер".
Ваша голая статика будет жить и при ядерной войне, да. Собственно это ее ЕДИНСТВЕННОЕ здравое преимущество. Все остальные незаметны в приципе.
Но эта самая статика имеет ограниченный функционал. Бурундук для одного из таких узких мест предложил дергать бекофис или базу. я и возразил, что в таком случае мы теряем единственное преимущество. Всё.
Если вам нужны специфические требования, то разрабатывать 100% придется.
Вы просто вынесли свою сложность в бекофис. Если бы бекофис был бы стоковым, то и с тонким клиентом была бы та же лажа)
А если четко понимаешь "как надо", то проще ей богу в вакууме писать, дешевле, быстрее.
Так не бывает. Всегда что-то меняется. И в какой-то момент ты понимаешь, что на переделки ушло больше сил и времени чем на создание. Стоимость переделок часто важнее стоимости старта.
И заметьте, я не веб-разработчик,
В этом главный вопрос.
Когда у вас будет по 10 магазинов в месяц. Даже не новых. Старых. На обслуживании, допиливании... тогда будет совсем другое ощущение.
Сначала вас взломают. Ну вот просто возьмут и зальют шел. И то что у вас одна статика - вас не спасет. Писать долго. Но взломают. Обязательно взломают.)
простота в поддержке
Без СУБД?)
лёгкая управляемость проектом
с какого перепуга? Бекофис то у нас утолщается. При этом еще есть точка стыковки двух систем. Это тоже дополнительная сложность.
гибкость
Без СУБД?)
ну и чисто сеошное - это продвигаемо
Без СУБД? Да 90% сеофишек на связях так или иначе завязано.
Нет, можно по сути витрину использовать чисто как кеш, но... что это даст?
Ваш подход по уносу всего оформления в ЖС, а кто не ЖС, тот или робот или ССЗБ -я знаю, и не оспариваю. Не скажу что согласен, но такие эксперименты я тоже делал, и вижу в них здравое зерно. Только муторно... но мы говорим о фронте без БД и жЫрном бекофисе. В чем бонус? Дешевле хостинг разве что. Всё остальное минусы.
но плюсы перевешивают
Какие?)1234567890
В Битриксе - вполне все отключаемо и все что нужно, можно дописать. Не видел задач, которые нельзя бы было реализовать (при чем в адекватные сроки)
толстые. тупые. отвратительные контроллеры. Всё.
А смысл?
Лишняя точка отказа.
Лёг основной сервер, и наш легкий фронт мёртв.
При этом еще и АПИ изобретать. Да и кучу всяких неожиданностей ловить...
Взяли себе клудфларе за 10 баксов в месяц и ваша "полустатика" уже бонусом готова.
Нет, я и сам задумывался не раз о тонкой витрине.
Разрастание бекофиса тут не главное.
Важнее их относительная автономность.
Если они синхронизируются асинхронно, заливкой файла, дерганием апи или еще как, но не блокируют друг-друга, АПИ их общения простой (да хоть дамп в json одним файлом кидай по фтп), то тут есть много своих плюсов. Но излишняя связность убивает весь смысл тонкого фронта.