Это перевод блогозаписи "Can Laravel Be Used for Big Enterprise Apps?"
Вчера я слушал новый эпизод Laravel Podcast с Тейлором Отвелом (Taylor Otwell), Джеффри Веем (Jeffrey Way) и Мэттом Стаффером (Matt Stauffer) – и они (наконец-то!) поговорили про создание больших приложений на Laravel, в последнее время этот вопрос очень часто задают.
Так как ребята из подкаста не предоставили стенограмму, и прослушивание 50 минут может быть излишним, я решил написать краткое содержание и разбить ответы в более удобном формате Вопрос-Ответ, с ссылками по теме. Поехали!
Мэтт: Прежде чем погружаться в тему, давайте определимся, что такое Enterprise приложение? Это о количестве строчек кода, о зависимостях, или безопасности, или о нагрузке?
Джеффри: у меня тот же вопрос. Какие функции/возможности имеют фреймворки, которые делают их энтерпрайзными, а Laravel нет? Имеет ли значение, что Zend имеет за собой большую компанию, тогда как про Laravel все спрашивают «что будет, когда Тейлор умрет?»
Тэйлор: я думаю, что большинство людей имеет ввиду множество классов, и, я полагаю, большое количество кода.
Тэйлор: очевидно, я собираюсь сказать да, он может быть использован для больших приложений, потому что:
Так что он не только может использоваться для больших приложений, он однозначно лучше подходит для больших приложений, чем прочие альтернативы на PHP.
Я понимаю, что это вводит в заблуждение, потому что Laravel имеет низкий порог входа. Но в тоже время он масштабируется в соответствие с вашими потребностями.
Тэйлор: Между прочим, люди не выбирают фрейморк рационально. Много субъективных вещей. Может, им не нравится маркетинг, может они не любят дружелюбный стиль Laravel, так что они выбирают что-то более строгое, вроде Zend. Иногда им просто не нравлюсь лично я!
Мэтт: говоря об энтерпрайзе, есть различия между большим и корпоративным проектом. У нас есть люди, постоянно говорящие «Генеральный директор, или совет директоров, или финансовый директор, или юристы, или кто-то еще из нашей многомиллиардной компании, очень обеспокоены тем, что мы собираемся вложить целую кучу времени и денег в Х», поэтому многие разработчики получают входные данные, не относящиеся к разработке, поэтому мне интересно, существуют ли какие-то ограничения, например, не использовать Laravel.
Мэтт: давайте отойдем в сторону от энтерпрайза и поговорим о больших приложениях.
Я знаю, что мы не можем назвать много сайтов на Laravel. Я знаю несколько, потому что я под NDA с многими из них, и там тысячи миллионов посещений, из Alexa 500, много компаний из списка Fortune 500. Можем мы рассказать больше?
Тэйлор: различные сайты компьютерных игр, например, Fallout 4, используют Laravel на своих лендингах. Но основной вопрос – зачем людям нужны доказательства, что это работает? Доказательств всегда мало.
Тейлор: Люди, возможно, хотят узнать: «если я создам свое большое приложение на Laravel, будет ли он вечно поддерживаться и обслуживаться, и … ?». Нет, Laravel не сделает автоматически ваше приложение крутым в поддержке в ближайшие 10 лет.
Фреймворк позволяет сосредоточится на вашем коде. Фреймворк — это маршрутизация, сессии, кеш, обращения к бд, но вы единственный, кто может описать специфику предметной области и знает проблемы бизнеса, которые намного сложнее, чем особенности фреймворка.
Мэтт: Плохой разработчик напишет плохой код на любом фреймворке.
Мэтт: Ну, предположим, люди согласны, что Laravel хорош. Как создать большое приложение, какие нюансы в приложении с миллионами просмотров в неделю?
Тэйлор: Достаточно просто. Убедитесь, что вы используете хороший драйвер для сессий и кеша, вроде Memcached или Redis, на сервере вроде Elasticcache на вашем AWS.
Вероятно, вам нужен балансировщик нагрузки, PHP очень хорошо масштабируется в этом смысле.
На уровне Laravel, убедитесь, что вы используете config:cache, route:cache, что вы сделали composer dump-autoload –optimize.
Джеффри: На Laracsts, который, внезапно, тоже хайлоад-проект, я не делал столько всего! Есть многие базовые вещи, которые люди полностью игнорируют, например, размеры их картинок!
Тэйлор: другая хорошая идея – отделить вашу БД от сервера приложения. Это позволит проще масштабироваться, например, если вам потребуется второй сервер.
И, говоря о кешировании, я много использую Cloudflare в последнее время. Весь официальный сайт Laravel жестко закеширован, только несколько запросов на самом деле достигают сервера, потому что почти все статично, например, документация.
Мэтт: С Cloudflare есть другая проблема: необходимо учитывать срок хранения, чтобы обновлять кеш. Так что это даже не проблема Cloudflare, а ваша – проверяйте Expires в заголовках!
Выслушав их мысли (спасибо, ребята!), я пришел к тому же выводу – что большие приложения это не про фреймворк, здесь есть еще много предметов для обсуждения: DevOps, механизмы кеширования, уникальная бизнес-логика вашего приложения, структура БД и так далее. Так что вопрос «Достаточно ли хорош Laravel?» — это неправильный вопрос. Лучше спросите, «Достаточно ли хорош мой код?», или «Достаточно ли у меня навыков использовать Laravel эффективно в большом приложении?». Если есть что добавить, то автор статьи принимает комментарии в своем блоге, и вот ссылка на сам подкаст.
От себя добавлю: сама суть обсуждения достаточно дискуссионна, и во многом я не согласен с категоричностью Тейлора (каждый поп хвалит свой приход, да), но основная мысль, которая сквозит через подкаст — плохой разработчик напишет плохой код, вне зависимости от фреймворка. Фреймворк лишь дает инструменты для того, чтобы сосредоточится на основном — бизнес-логике.
P.P.S: Об ошибках и неточностях сообщайте, пожалуйста, в личку.
Вчера я слушал новый эпизод Laravel Podcast с Тейлором Отвелом (Taylor Otwell), Джеффри Веем (Jeffrey Way) и Мэттом Стаффером (Matt Stauffer) – и они (наконец-то!) поговорили про создание больших приложений на Laravel, в последнее время этот вопрос очень часто задают.
Подходит ли Laravel, достаточно ли он взрослый, для больших проектов?
Так как ребята из подкаста не предоставили стенограмму, и прослушивание 50 минут может быть излишним, я решил написать краткое содержание и разбить ответы в более удобном формате Вопрос-Ответ, с ссылками по теме. Поехали!
1. Что такое большое приложение?
Мэтт: Прежде чем погружаться в тему, давайте определимся, что такое Enterprise приложение? Это о количестве строчек кода, о зависимостях, или безопасности, или о нагрузке?
Джеффри: у меня тот же вопрос. Какие функции/возможности имеют фреймворки, которые делают их энтерпрайзными, а Laravel нет? Имеет ли значение, что Zend имеет за собой большую компанию, тогда как про Laravel все спрашивают «что будет, когда Тейлор умрет?»
Тэйлор: я думаю, что большинство людей имеет ввиду множество классов, и, я полагаю, большое количество кода.
2. Так можно ли использовать Laravel для больших приложений?
Тэйлор: очевидно, я собираюсь сказать да, он может быть использован для больших приложений, потому что:
- Он уже используется для больших приложений, и мы знаем это.
- Laravel хорошо подходит для любых приложений, для которых подходит PHP. Здесь все зависит от вас – как только дело дошло до Контроллера, вы можете делать всё, что пожелаете.
- И еще я думаю что Laravel имеет уникальные преимущества и лучше подходит для создания больших приложений, чем другие PHP решения на текущий момент, по многим причинам. Главная — есть зависимости, сложность и DI в Laravel действительно хорош. Когда вы говорите о сложных приложениях, вы также имеете ввиду фоновую обработку задач, и Laravel единственный имеет встроенную систему очередей из всех основных PHP фреймворков. И еще, естественно, функции Event Broadcasting и другие, присущие большим приложениям.
Так что он не только может использоваться для больших приложений, он однозначно лучше подходит для больших приложений, чем прочие альтернативы на PHP.
Я понимаю, что это вводит в заблуждение, потому что Laravel имеет низкий порог входа. Но в тоже время он масштабируется в соответствие с вашими потребностями.
3. Люди иррациональны
Тэйлор: Между прочим, люди не выбирают фрейморк рационально. Много субъективных вещей. Может, им не нравится маркетинг, может они не любят дружелюбный стиль Laravel, так что они выбирают что-то более строгое, вроде Zend. Иногда им просто не нравлюсь лично я!
4. Мир энтерпрайза
Мэтт: говоря об энтерпрайзе, есть различия между большим и корпоративным проектом. У нас есть люди, постоянно говорящие «Генеральный директор, или совет директоров, или финансовый директор, или юристы, или кто-то еще из нашей многомиллиардной компании, очень обеспокоены тем, что мы собираемся вложить целую кучу времени и денег в Х», поэтому многие разработчики получают входные данные, не относящиеся к разработке, поэтому мне интересно, существуют ли какие-то ограничения, например, не использовать Laravel.
5. Приведите примеры больших приложений, использующих Laravel
Мэтт: давайте отойдем в сторону от энтерпрайза и поговорим о больших приложениях.
Я знаю, что мы не можем назвать много сайтов на Laravel. Я знаю несколько, потому что я под NDA с многими из них, и там тысячи миллионов посещений, из Alexa 500, много компаний из списка Fortune 500. Можем мы рассказать больше?
Тэйлор: различные сайты компьютерных игр, например, Fallout 4, используют Laravel на своих лендингах. Но основной вопрос – зачем людям нужны доказательства, что это работает? Доказательств всегда мало.
6. Дело не в фреймворке
Тейлор: Люди, возможно, хотят узнать: «если я создам свое большое приложение на Laravel, будет ли он вечно поддерживаться и обслуживаться, и … ?». Нет, Laravel не сделает автоматически ваше приложение крутым в поддержке в ближайшие 10 лет.
Фреймворк позволяет сосредоточится на вашем коде. Фреймворк — это маршрутизация, сессии, кеш, обращения к бд, но вы единственный, кто может описать специфику предметной области и знает проблемы бизнеса, которые намного сложнее, чем особенности фреймворка.
Мэтт: Плохой разработчик напишет плохой код на любом фреймворке.
7. Хорошо, как строить большие приложения?
Мэтт: Ну, предположим, люди согласны, что Laravel хорош. Как создать большое приложение, какие нюансы в приложении с миллионами просмотров в неделю?
Тэйлор: Достаточно просто. Убедитесь, что вы используете хороший драйвер для сессий и кеша, вроде Memcached или Redis, на сервере вроде Elasticcache на вашем AWS.
Вероятно, вам нужен балансировщик нагрузки, PHP очень хорошо масштабируется в этом смысле.
На уровне Laravel, убедитесь, что вы используете config:cache, route:cache, что вы сделали composer dump-autoload –optimize.
Джеффри: На Laracsts, который, внезапно, тоже хайлоад-проект, я не делал столько всего! Есть многие базовые вещи, которые люди полностью игнорируют, например, размеры их картинок!
Тэйлор: другая хорошая идея – отделить вашу БД от сервера приложения. Это позволит проще масштабироваться, например, если вам потребуется второй сервер.
И, говоря о кешировании, я много использую Cloudflare в последнее время. Весь официальный сайт Laravel жестко закеширован, только несколько запросов на самом деле достигают сервера, потому что почти все статично, например, документация.
Мэтт: С Cloudflare есть другая проблема: необходимо учитывать срок хранения, чтобы обновлять кеш. Так что это даже не проблема Cloudflare, а ваша – проверяйте Expires в заголовках!
Вместо заключения
Выслушав их мысли (спасибо, ребята!), я пришел к тому же выводу – что большие приложения это не про фреймворк, здесь есть еще много предметов для обсуждения: DevOps, механизмы кеширования, уникальная бизнес-логика вашего приложения, структура БД и так далее. Так что вопрос «Достаточно ли хорош Laravel?» — это неправильный вопрос. Лучше спросите, «Достаточно ли хорош мой код?», или «Достаточно ли у меня навыков использовать Laravel эффективно в большом приложении?». Если есть что добавить, то автор статьи принимает комментарии в своем блоге, и вот ссылка на сам подкаст.
От себя добавлю: сама суть обсуждения достаточно дискуссионна, и во многом я не согласен с категоричностью Тейлора (каждый поп хвалит свой приход, да), но основная мысль, которая сквозит через подкаст — плохой разработчик напишет плохой код, вне зависимости от фреймворка. Фреймворк лишь дает инструменты для того, чтобы сосредоточится на основном — бизнес-логике.
P.P.S: Об ошибках и неточностях сообщайте, пожалуйста, в личку.