Сергей Протько

https://github.com/angular/angular/issues/5467

require_once - влияет ли на скорость работы сайт если этих подключений много?

Влияет, но если у вас включен opcache то можно этим принебречь. Да и в целом это мелочи. Работа с базой данных занимает намного больше времени чем подобные штуки. Ну и ваша архитектура может убить производительность любого языка, было бы желание.

Не занимайтесь микрооптимизациями.

это примерно то же самое что научиться абсолютно точно предсказывать погоду на месяцы вперед.

Есть хорошая мантра:

таски на 4 часа мы делаем за 4 часа, таски на 8 часов мы делаем за 12, таски на 16 часов мы делаем за 24, таски на 40 часов мы не делаем никогда.

Просто старайтесь делать декомпозицию задачи на как можно меньшие кусочки. И домножайте на коэффициенты рисков (в вашем случае - 4). Со временем этот коэффициент будет уменьшаться и вы будете точнее предсказывать сроки.

храним все важные документы в облаке, а серсы у нас и так в GIT.

composer

Как при этом вынести настройки под конкретный сайт?

Просто вынесите настройки, они же в git не хранятся. Если планируете автодеплой налаживать - то все различия в ENV переменные и разруливать все на уровне CI-сервера (у меня например так разруливается, по джобе на сервер, что бы все секьюрные штуки спрятать и не хранить при этом в GIT-е)

официальная документация, википедия в отношении HTTP.

А именно как именно происходит потеря контекста?

Достаточно вызвать функцию в другом контексте:

var foo = {
    bar: function () {
        console.log(this);
    }
};
var bar = { bar: foo.bar };
foo.bar(); // вызываем функцию в контексте foo.
bar.bar(); // вызываем функцию но уже в контексте bar

В вашем случае вам нужно явно передать контекст во вложенную анонимную функцию.

RTFM

https://developers.google.com/maps/documentation/i...

В идеале второй вариант, если это возможно.

Скажем я на своих проектах пытаюсь делать так насколько это возможно. Перед началом разработки какой-то фичи разработчики просто договариваются между собой как будет организовано взаимодействие с сервером (по сути пишется описание API на каком api blueprint, сейчас будем переходить на raml).

После чего из этого описания разработчик серверной части может спокойно генерить себе тесты, json схемы респонсов и т.д. что бы быть уверенным что он делает так как договаривались, а мобильщики могут поднять себе из описания mock сервер.

Таким образом какие-то проблемы с серверным взаимодействием можно отловить задолго до того как разработчики в принципе реализуют эту часть api. Хотя если разработчики не используют какие-то средства для валидации реализации на предмет соответствию описанию, то в итоге на интеграцию может уйти больше времени.

p.s. этот подход я форсирую еще и потому, что при таком варианте можно легко наладить кодогенерацию как для клиента так и для бэкэнда. Скажем валидация запросов, маршрутизация, мэппинги и т.д. - все можно сгенерировать. RAML в этом плане дает из всех форматов максимальную гибкость, и поэтому я и планирую на него переходить. В очень простых случаях можно сгенерировать код хоть всего бэкэнда, но и так в целом скорость разработки неслабо увеличивается.

Используйте openssl. Там все есть, правда предлагаю вам актуальную версию: https://rt.openssl.org/Ticket/Display.html?id=3311...

Могут ли в PHP сокеты работать асинхронно?

Да. Это называется non blocking sockets а не "асинхронно".

но не понятно как дальше с этим работать.

socket_select.

Все знают, что parse.com скоро закроется.

Да, и они выложили все в опенсурс. Можете развернуть себе свой parse.

Firebase? Я правильно понимаю, что у него нет серверных скриптов?

Можно через app engine.

За остальное говорить не берусь.

Используется для загрузки XMLHttpRequest.

XmlHTTPRequest это часть API брауера, PHP ничего о нем не знает и не отличает от остальных HTTP запросов (заголовок который по дефолту ставится можно убрать). То есть уберите в своем представлении разницу между ajax и обычными запросами.

Как это происходит вся эта взаимосвязь?

nginx проксирует HTTP запрос на php-fpm. Вот и все. Он с ним больше ничего не делает и настройки ограничивающие что можно орабатывать у него свои.

То есть мы грузим файл в 1 гиг, тело запроса буферизуется (по умолчанию, можно отключить директивой fastcgi_request_buffering но тогда свои ограничения, хотя думаю вам оно не особо важно) и потом прокидывается в пых, где тот смотрим что тело запроса слишком большое (больше сотни мегабайт) и грустит.

Я давно уже хочу опробовать MVC

не пробуйте если не разобрались что это такое и какие проблемы решает. И будьте осторожно, за 40 лет существования этого паттерна накопилось много "искаженно" информации. Так что... просто забейте...

Запомните, смысл этих аббривиатур (MVC, MVVM, MVP, HMVC) не в самих буквах (компонентах которые они предлагают) а в отношениях между ними. Например в оригинальном MVC вьюшка это не шаблончики, а полноценный кусок кода который сам отвечает за себя. На бэкэнде же вьюшка это обычно пассивна, ее формируют контроллеры. Они же обрабатывают пользовательский ввод. Так что это уже явно не MVC. Ищим другие паттерны и они подойдут. Но отсутствие понимания зачем это все делать обычно приводит к непониманию и плохим решениям.

Скажем то что вы подразумеваете под MVC на самом деле завется Model2 (насколько я понимаю то что вы хотите сделать) и это абсолютно разные вещи.

единственный вопрос, который мешает это сделать - это написание самого роутера.

Возьмите готовый.

Я искал решение, и единственное что нашел это подключить модуль от Symfony.

Плохо искали. Вот где нужно искать: packagist.org

https://github.com/nikic/FastRoute