A
И каким боком он к процитированному куску?
Mistap, sorry
Size: a a a
2020 March 15
A
Константин Lukinov
Я так понял, вы говорите про разные масштабы приложений. Руслан смотрит с точки зрения масштабирования и high load, а Andre с точки зрения небольшого, до 10к пользователей приложения
А причём тут хайлоад?
КL
А причём тут хайлоад?
Я использовал не те термины. Я пытался сказать, что Руслан делает хорошую архитектуру, чтобы не переделывать её слишком часто, а Andre больше смотрит в сторону простых решений.
Мне больше нравится подход Руслана
Мне больше нравится подход Руслана
A
Константин Lukinov
Я использовал не те термины. Я пытался сказать, что Руслан делает хорошую архитектуру, чтобы не переделывать её слишком часто, а Andre больше смотрит в сторону простых решений.
Мне больше нравится подход Руслана
Мне больше нравится подход Руслана
Хорошая архитектура базируется на простых решениях.
RY
А что значит "Andre" смотрит в сторону простых решений? Как давно решение "сходи в БД, распарси и обработай всё что можно было взять одним запросом из БД" стало проще чем просто "сходи в БД"
RY
через Nested Sets одним запросом могу взять категорию и всех её потомков вот вообще без проблем
A
Это будет медленнее чем прочитать одино поле одной таблицы
A
Тоесть сложнее
A
Но как выяснилось, это два разных решения для разных потребностей
RY
Andre
Это будет медленнее чем прочитать одино поле одной таблицы
Это микросекунды и экономия на спичках в запросе к БД. Во всех остальных случаях есть много НО, начиная от того кто будет разгребать эти тонны говен (например если это API которое возвращает ВСЁ и фронт будет разгребать - это вообще можно будет сдохнуть пока отработает), продолжая временем разработки хотя бы минимума, заканчивая временем потраченным на сопровождение и расширение
КL
Хорошая архитектура базируется на простых решениях.
Это общая фраза, которая все равно поддерживает подход Руслана. "Простые" в данном случае надо понимать как "дешёвые". То есть решения, которые дают быстрый эффект сейчас, но сопровождать/масштабировать/развивать которые неприятно. Решения, которые заведомо потребуют переделки архитектуры.
КL
Andre
Но как выяснилось, это два разных решения для разных потребностей
Вот. Я пытался это сформулировать
A
Что значит фронт будет разгребать, можно сразу хранить в виде который фронтмпонимает
A
Твой скл тоже надо будет перевести в вид который фронт понимает
A
Константин Lukinov
Это общая фраза, которая все равно поддерживает подход Руслана. "Простые" в данном случае надо понимать как "дешёвые". То есть решения, которые дают быстрый эффект сейчас, но сопровождать/масштабировать/развивать которые неприятно. Решения, которые заведомо потребуют переделки архитектуры.
Стоимость решения к его качеству мало отношения имеет
КL
Ваше решение явно отлично ложится в определенные потребности. Но я не часто сталкивался с ними. Чаще это было через базу.
RY
Andre
Что значит фронт будет разгребать, можно сразу хранить в виде который фронтмпонимает
фронт понимает JSON, ага... только пока на фронт прилетит 100мб ненужного говна, кто-то поймает пару микроинсультов
A
фронт понимает JSON, ага... только пока на фронт прилетит 100мб ненужного говна, кто-то поймает пару микроинсультов
Знакомая картина, кстати.
A
Видел я один проект, где CSV на фронте генерировали. По всей истории аккаунта. На активных аккаунтах это, разумеется, не работает никак
A
Почему не нужного, если меню 100мб и то после скл надо будет его перевести в тот же джсон 100мб