В
Всем привет! Скиньте плз в ЛС чат где по hml, css сидят ребята, нужен верстальщик для микро шабашки (можно нуб). Спасибо!
Size: a a a
2021 March 23
VT
я про твой последний вопрос и да это спа для бекендеров, можно быстро написать современное приложение и не еб@ться с накстом или независимым фронтом, для CRMок самое то
Про SPA - согласен, а для CRM не уверен: просто не вижу смысла. Но если это будет хорошо реализовано, то почему бы и нет, согласен
VS
По-моему, "зачем?" вполне резонный вопрос.
Ты сбросил новость в чат, я её с тобой обсуждаю.
Интересно, просто, в чём профит перед стандартным REST API.
Ты сбросил новость в чат, я её с тобой обсуждаю.
Интересно, просто, в чём профит перед стандартным REST API.
Минимум JavaScript на клиенте,(клиента ты не можешь масштабировать) а сервак спокойно, дешевле на некоторых проектах в любом случае, при той же почти эффективности на мелких проектах - тебе нужен всего команда нормальных laravel разрабов, без знаний react, redux, apollo - не надо за ssr париться, но все работает как всегда до "особых" случаев, figma ты не запилишь такими инструментами, но хороший вообще инструмент для своей задачи
VS
Своей задаче - свои инструменты
AB
Всем привет! Скиньте плз в ЛС чат где по hml, css сидят ребята, нужен верстальщик для микро шабашки (можно нуб). Спасибо!
VT
Минимум JavaScript на клиенте,(клиента ты не можешь масштабировать) а сервак спокойно, дешевле на некоторых проектах в любом случае, при той же почти эффективности на мелких проектах - тебе нужен всего команда нормальных laravel разрабов, без знаний react, redux, apollo - не надо за ssr париться, но все работает как всегда до "особых" случаев, figma ты не запилишь такими инструментами, но хороший вообще инструмент для своей задачи
Вот про масштабируемость аргумент хорошо звучит.
Только я вот о чём думаю: если, получается, клиентскую часть отдаёт PHP по запросу, не будет проблем с тем, что клиент будет ждать свободный воркер, чтобы получить отрисовку?
Только я вот о чём думаю: если, получается, клиентскую часть отдаёт PHP по запросу, не будет проблем с тем, что клиент будет ждать свободный воркер, чтобы получить отрисовку?
VT
Ну и типа в целом, клиент будет вынужден ждать, пока мы ходим куда-то в базу. Я, вполне вероятно, чего-то не понимаю, потому и спрашиваю)
В
спасибо!
ВШ
По-моему, "зачем?" вполне резонный вопрос.
Ты сбросил новость в чат, я её с тобой обсуждаю.
Интересно, просто, в чём профит перед стандартным REST API.
Ты сбросил новость в чат, я её с тобой обсуждаю.
Интересно, просто, в чём профит перед стандартным REST API.
Ускорение процессов, нет необходимости поддерживать документацию для фронта по API,
VT
Ускорение процессов, нет необходимости поддерживать документацию для фронта по API,
Каких именно процессов?
Второй аргумент применим и к шаблонизатором. Да и так себе аргумент, если честно: документация не бремя, а полезная вещь.
Второй аргумент применим и к шаблонизатором. Да и так себе аргумент, если честно: документация не бремя, а полезная вещь.
ВШ
Каких именно процессов?
Второй аргумент применим и к шаблонизатором. Да и так себе аргумент, если честно: документация не бремя, а полезная вещь.
Второй аргумент применим и к шаблонизатором. Да и так себе аргумент, если честно: документация не бремя, а полезная вещь.
Процессов разработки конечно.
VT
Процессов разработки конечно.
Каким образом?
ВШ
Делаю еще и генератор CRUD, разворачивать будем не за час, а за пять минут
VT
Сомневаюсь, что есть смысл обсуждать такое серьезное изменения в подходе к разработке в контексте CRUD.
ВШ
Каким образом?
Бекендер запускает генератор, который создает контроллер, модельки, миграции, плюс сразу создаются вьюшки.
VT
Бекендер запускает генератор, который создает контроллер, модельки, миграции, плюс сразу создаются вьюшки.
Как это ускоряет разработку?
ВШ
Как это ускоряет разработку?
В разы )))
VT
Не "во сколько раз", а каким образом)
ВШ
Ну прочитайте выше - документации нет по REST
ВШ
Так как это обычно тупое перечисление одинаковых роутов