Павел Волынцев

RESTful API в основном

Почитал все вопросы ответы по теме.
По моему в целом проблема высосана из пальца, но сейчас не об этом.

1. Не понятно для кого это делается. Просто для себя или будут пользователи у вашего решения.
Если наберется с N пользователей, то не померет ли ваш белый сервер от постоянной перезагрузки страниц (DDos).

2. аналогично первому только касаемо базы и прочих ресурсов на сервере. Хостинг провайдер не пошлет за постоянной превышение нагрузки?

3 Черный ящик php. Я не могу посоветовать решения не зная, как урезан php на белом хостинге.

4. Ближе к телу. Думаю на ваших серверах все реализована так:
Запрос -> веб сервер (apache, nginx) -> php ( fpm, cgi)

Все они созданы, чтобы сдохнуть ( т.е как у веб сервера так и php есть настройки времени жизни для запроса) и соответственно бесконечных одиночных запросов в этом контексте ( для http) быть не может.

Люди уже давно придумали как это обойти : long pooling, web sockets. Даже придумали php, который не умирает (Reactphp).

Но возможны ли эти решения для вас, зависит от п.п 3 ( см. выше)

5.

Может ли php получать и обрабатывать часть информации? (Так как один ответ сервера длится бесконечно и его, естественно надо обрабатывать частями).
Может ли php отправлять информацию частями? (Поподробнее про буферизацию, пожалуйста).

Извините, ерунда. см п.п.4
Правильным решением будет 100 разных POST отправить с серого к белому серверу. На белом все собрать в кучу.

6. В целом, если вам необходима только выдача данных от серого сервера. То самым простым будет реализация своего static http proxy.
Т.е. серый генерирует уже готовые страницы отдает их белому. А тот их сохраняет и выдает. Если пользователь запросит, то что серый еще не обработал слать его на ... (404)

Например вот
Можно гуглить с ключевыми словами wordpress medium theme и всё найдется

Дизайнер конечно же не прав, это дураку понятно. Это всё-равно что рисовать для каждого экрана разные типы кнопок (квадратные, закруглённые, градиент и прочие извращения) или использовать каждый раз новый шрифт для нового экрана.

Вы не пробовали попросить дизайнера аргументировать его решение рисовать каждый раз новый дизайн и привести пример :) Если получите ответ: "Я дизайнер, мне лучше знать!", то всё понятно - перед Вами очередной говно-дизайнер, коих в России великое множество. Все себя называют UX/UI, хотя работы говорят об обратном.

Соболезную вашей ситуации на работе.

P.s. Я Product designer, с отличным знанием вёрстки. Полностью понимаю, о чём Вы.

Удачи :)

Скорее всего он решает много разных задач. Делить класс на части: 1 класс 1 задача
https://refactoring.guru/ru/smells/large-class

PS
Работает не трогай :)

Теоретически можно, ведь можно указывать mergetool, если хочется. Другой вопрос - как из этого построить что-то работающее. Текст - это такая удобно нормализованная штука - есть строчки, в нормальном тексте они короткие, делятся переводом строки - удобный элемент для квантования целого ресурса. С бинарниками так просто уже не поступишь: во-первых, для каждого формата свой подход (а для текста совершенно разного назначения вполне можно использовать одну и ту же тулзу), а во-вторых - нужно уметь собственно совмещать то, что в картинках различается. Некоторые форматы, например PSD, вполне можно было бы смержить в ситуациях, когда разные люди добавили разные слои и работали каждый в своих.
Я думаю все дело в соотношении простота/спрос. Написать тулзу еще нужно суметь, ведь это в тексте достаточно просто вставить строки друг за другом, а в PSD нужно полностью всю служебную инфу обновить и вообще правильно записать весь формат, плюс нужно продумать естественное поведение в каждой конфликтной ситуации, а в сложных форматах их намного больше, чем в тексте - один дизайнер слой переименовал, а другой - нет, и оба чтото поменяли, нужно определить - мержить изменения в один слой или оставлять два разных. И еще миллион таких ситуаций со всем, что может храниться в PSD. А спрос-то не сильно велик - тут и программистам-то не всем нравится ветвление (и часто бывает оно и правда только усложняет процесс), а дизайнерам поди разжуй. Так что идея ваша вполне заслуживает внимания, просто при реализации она превращается во вполне конкретные частные решения, которые подаются вместе с основным инструментом, и не предназначены для работы с VCS общего назначения (Git, Mercurial).
Вот под рукой отличный пример: команда Dr. Explain - тулзы для создания документации - недавно запустили сервис совместной работы. И фишка вся в том, что это более чем хорошая новость для пользователей этого продукта, т.к. их формат хранения практически не подлежит мержу средствами обычных VCS (это xml-ка, которая хранит внутри себя ВСЕ, в том числе картинки). Вот они и выкатили свой велосипед. Мы кстати пытались использовать это дело, сделали штук 6 коммитов в свой репозиторий, быстро поняли, что работать надо по-очереди, т.к. смержить просто нереально, а потом, пока еще не поздно, съехали на DocBook (с компиляцией в XSL-FO).

P.S. Не так уж и не нужно - в перфорс есть оказывается такие приложения для мержа: www.perforce.com/helix-apps

У DevDocs есть расширения для Chrome и Firefox, позволяющие читать доки без подключения к интернету. Там много всего, не только фронтенд.

sass-scss.ru- перевод официальной документации

Используйте Vagrant.