Я не использую Laravel для разработки. Мне после Zend и Symfony он не зашел (написали несколько проектов на Laravel). Но если абстрагироваться, то взял бы Symfony + EasyAdmin или Symfony + Sonata. Если есть время, то лучше %ВАШ_ФРЕЙМВОРК% + фронтенд на React, Vue, Angular2+, Ember.
Если про решение на Laravel, то наверно взял етот grid, хотя бы потому, что тянуть два фреймворка ето лишнее.
Лично для меня server-side рендеринг уже прошлое.Надо отделять мух от котлет. Чисто мое мнение.
Не знаю, как на счет вашего примера, но вот если бы эта штука автоматически открывала двери (именно открывала, не только замок) то било б огонь. Идешь такой с сумками, а тебе дверь раз и открылась когда подошел. Не надо ставить их на пол, доставать ключи из сумки/кармана.
VolCh я вот не соглашусь. Почему лучше Angular2? С ним проще писать следуя SOLID и DDD. Вот есть у тебя entity post. Написал модель, написал репозиторий, дал интерфейс. В реализации уже подтянул любимую либу для запроса на сервер (будь то RxJS или хоть чистый xhr). Отделно поставиш обработчики на actions, отдельно поставишь темплейт.
Похожая ситуация с Ember. Меня больше заботит то, как данные взаимодействуют. Отрисовать малая часть проблемы в SPA как по мне (если заботиться чисто о view то React подойдет лучше).
bjornd у Ember есть недостаток с тем что у него довольно высокий порог вхождения (как по мне). Наш первый проект был болью но последующие, мне сложно представить как бы мы изошрялись без Ember.
Думаю в каждом из фреймворков есть как + так и — , кому то что то пойдет сложно кому то легче. И еще, по одному проекту судить сложно, думаю для объективной оценки нужно сделать 2-3 проекта.
есть отличие между Amazon EC2 и Amazon ECS. По простому: Amazon EC2 ака твой VPS, ака ваш пример с Azure, где тебе надо будет ставить докер и тд для его запуска. Для Amazon ECS же достаточно указать (в теории) просто откуда взять твой Docker образ и указать условия запуска. Ето 2 разных сервиса.
А почему и нет? Если речь о локальной разработке, то вполне можна взять docker image с Ubuntu(как пример) установить локально ssh и необходимие зависимости (php/python/java/nginx/apache/mysql ....) прокинуть порт и потом через volume залинковать проект в контейнер. Сумарно он будет быстрей Vagrant (но далеко не везде, на том же маке Vagrant иногда шустрей)
P.S: Vagrant может под капотом работать с докером: https://www.vagrantup.com/docs/docker/
А почему и нет? Если речь о локальной разработке, то вполне можна взять docker image с Ubuntu(как пример) установить локально ssh и необходимие зависимости (php/python/java/nginx/apache/mysql ....) прокинуть порт и потом через volume залинковать проект в контейнер. Сумарно он будет быстрей Vagrant (но далеко не везде, на том же маке Vagrant иногда шустрей)
P.S: Vagrant может под капотом работать с докером: https://www.vagrantup.com/docs/docker/
Я вам точно не скажу сейчас, просто не на моем проекте сейчас но с packer'ом и terraform тоже можна похожие вещи делать. У нас есть проект где packer создает image для google compute engine с уже готовым к работе проектом. В google compute инстансы создаються из последнего собраного image (не надо вам парится тогда и о том где rpm а где deb).
Terraform`мом можна описать как всю инфраструктуру поднять ( какие прокинуть порты, настроить load balancer и тд) Довольно акуратно и просто, плюс видиш сходу изменения с эволюцией проекта со временем (Infrastructure as a Code)
На проекте которым я сейчас занимаюсь, описано 3 инстанса в связке packer и terraform на aws. Кстати подход к деплою у нас — immutable server (у ребят с google compute тоже). Суть immutable deploy в том, что на сервере ничего не менять, а когда доступная новая версия, убирать инстанс со старой кодовой базой на новую. (Хотя я вполне подозреваю что вы знакомы с этим подходом) Как плюс можна довольно легко поднять зеркально новую групу серверов и потестировать самому все а потом переключить Load balancer на новую групу, и если что то не так переключить обратно (blue/green deployment кажеться). Можна сохранять версии images которые создал packer и опять же пересобирать как хочеш.
Кстати packer спокойно собирает и пресловутым Docker так что, как билдить решать вам самим =)
Я, лично, только начал с ними работать, перенимаю опыт у ребят с другой команды но перспективы радуют.
Потом все это можна и под СІ подогнать.
Думаю потом если все пойдет ок то можно будет и статейку оформить, хехе :)
Так опять никто и не говорит о бекенде на javascript. У нас несколько проектов где фронт на EmberJS а бекенд на Symfony. Здесь ember server только для разработки фронта (под капотом ember server поднимает livereload что позволяет сразу видеть проводимые изменения). Подозреваю что вы не просто не так меня поняли =)
JavaScript 2016, а можно попроще?
Ответ: Можна. EmberJs.
How to:
1) npm install -g ember-cli
2) ember new my-new-app
3) ember server
Под катом уже RestAdapter, JsonAdaper. Удобная EmberData (ActiveRecord) для моделей, Controller, Router и тд. Минимум усилий для нормального старта + документация на уровне
Я не использую Laravel для разработки. Мне после Zend и Symfony он не зашел (написали несколько проектов на Laravel). Но если абстрагироваться, то взял бы Symfony + EasyAdmin или Symfony + Sonata. Если есть время, то лучше %ВАШ_ФРЕЙМВОРК% + фронтенд на React, Vue, Angular2+, Ember.
Если про решение на Laravel, то наверно взял етот grid, хотя бы потому, что тянуть два фреймворка ето лишнее.
Лично для меня server-side рендеринг уже прошлое.Надо отделять мух от котлет. Чисто мое мнение.
Вы не пробовали использовать их движок? Интересно было бы увидеть и его в сравнении.
Похожая ситуация с Ember. Меня больше заботит то, как данные взаимодействуют. Отрисовать малая часть проблемы в SPA как по мне (если заботиться чисто о view то React подойдет лучше).
bjornd у Ember есть недостаток с тем что у него довольно высокий порог вхождения (как по мне). Наш первый проект был болью но последующие, мне сложно представить как бы мы изошрялись без Ember.
Думаю в каждом из фреймворков есть как + так и — , кому то что то пойдет сложно кому то легче. И еще, по одному проекту судить сложно, думаю для объективной оценки нужно сделать 2-3 проекта.
hlogeon прав:
не так просто как взять установить самому докер на vps и прогнать
P.S: Vagrant может под капотом работать с докером: https://www.vagrantup.com/docs/docker/
P.S: Vagrant может под капотом работать с докером: https://www.vagrantup.com/docs/docker/
Я вам точно не скажу сейчас, просто не на моем проекте сейчас но с packer'ом и terraform тоже можна похожие вещи делать. У нас есть проект где packer создает image для google compute engine с уже готовым к работе проектом. В google compute инстансы создаються из последнего собраного image (не надо вам парится тогда и о том где rpm а где deb).
Terraform`мом можна описать как всю инфраструктуру поднять ( какие прокинуть порты, настроить load balancer и тд) Довольно акуратно и просто, плюс видиш сходу изменения с эволюцией проекта со временем (Infrastructure as a Code)
На проекте которым я сейчас занимаюсь, описано 3 инстанса в связке packer и terraform на aws. Кстати подход к деплою у нас — immutable server (у ребят с google compute тоже). Суть immutable deploy в том, что на сервере ничего не менять, а когда доступная новая версия, убирать инстанс со старой кодовой базой на новую. (Хотя я вполне подозреваю что вы знакомы с этим подходом) Как плюс можна довольно легко поднять зеркально новую групу серверов и потестировать самому все а потом переключить Load balancer на новую групу, и если что то не так переключить обратно (blue/green deployment кажеться). Можна сохранять версии images которые создал packer и опять же пересобирать как хочеш.
Кстати packer спокойно собирает и пресловутым Docker так что, как билдить решать вам самим =)
Я, лично, только начал с ними работать, перенимаю опыт у ребят с другой команды но перспективы радуют.
Потом все это можна и под СІ подогнать.
Думаю потом если все пойдет ок то можно будет и статейку оформить, хехе :)
P.S: простите за плохой руский :(
Посмотрите еще в сторону packer.io и terraform. Как по мне интересный подход к деплою :)
Ответ: Можна. EmberJs.
How to:
1) npm install -g ember-cli
2) ember new my-new-app
3) ember server
Под катом уже RestAdapter, JsonAdaper. Удобная EmberData (ActiveRecord) для моделей, Controller, Router и тд. Минимум усилий для нормального старта + документация на уровне