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