Philipp

Для начала смотреть в tr.
Еще можно попробовать $scope.applyAsync()

Deepstream использует uws, который работает через WebSocket'ы.

Правильное решение - использовать информацию из заголовков об используемом языке.
Если же не удается определить язык по данным из браузера, следует опираться на определение через Ip-адрес. Просто опирайтесь на код страны. Если не найдена, то всегда открывайте версию на английском языке.

Получается, что в картинках есть доступ программному коду, что не безопасно.

В картинках нет доступ к программному коду. Это абсолютный бред.

Что же на самом деле происходит?
Для этого нужно понимать, как работает современная архитектура.

Когда вы запрашиваете картинку, то ваш запрос отправляется на балансировщики (да, их может быть несколько), для выбора ближайшего используется протокол anycast.
Далее балансировщик выбирает ближайший наименее загруженный веб-сервер.
Веб-сервер принимает запрос и разбирает его на компоненты.

Например в вышеприведенном примере, можно увидеть, что запрос выглядит примерно так
"scontent-lga3-1.xx.fbcdn.net/v/t1.0-9/283048_103813746439563_31482813_n.jpg?oh=63f4724d166e6e322316283885f15ddc&oe=58D3C4F4"

scontent-lga3-1 - имя хоста, на котором может храниться изображение. Этот хост является частью сети доставки контента.
v/t1.0-9 - понятно, что это версия, скорее всего версия варианта хранения. Facebook непрерывно развивается, поэтому наверняка имеется процедура миграции между различными версиями хранения данных.

283048_103813746439563_31482813 - уникальный идентификатор изображения, три части которого являются разного рода идентификаторами.
oh - скорее всего object hash - некая цифровая подпись объекта.
oe - object expiration - фейсбучный аналог e-tag, специальный параметр указывающий на устаревание объекта.

Если интересно, как работает хранилище фоток в Фейсбук можете почитать в их блоге https://code.facebook.com/posts/685565858139515/ne...

Насколько я понимаю, Facebook не вычисляет доступ к объекту на лету, т.к. зная точный адрес изображения, его какое-то время можно открыть на другой машине.

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

Итак, с точки зрения производительности, самое напряжное - скорость чтения данных с диска, т.е. обычное I/O, поэтому если вам нужна именно скорость, то надо сфокусироваться на быстром хранилище, т.е. SSD просто обязательно.

Далее нужны соображения по поводу надежности, балансировки, обеспечения безопасности доступа.
Вам нужно понять, что мир не заканчивается на уровне Apache и PHP. Например может быть свой особый модуль для nginx, который будет ходить в базу и проверять доступность объекта и лишь затем считывать его с диска. Т.е. то, что вы видите в адресной строке может не иметь ничего общего с тем, как эти данные фактически хранятся на диске, например они могут лежать в HDFS или GridFS.

В вашем случае с учетом вашего уровня знаний лучше всего воспользоваться проверенными решениями вроде хранения картинок в S3 и отдачи их через Cloudflare c кэшированием, например так
https://habrahabr.ru/post/245165/
или так https://habrahabr.ru/company/io/blog/257533/

Здесь всегда выбор, который зависит от фактора доступности серверов Google.
Например, если вы делаете публичный веб-сайт, к которому всегда будут обращаться только люди с неограниченным доступом к Интернет, то вопросов никаких нет - используете сервера Гугла. Очень высока вероятность, если шрифт часто используемый, то он уже будет в кэше браузера и не произойдет повторной загрузки. В скорости и надежности серверов Гугла можете не сомневаться.
Но бывают ситуации, когда с сайтом работают из локальной сети и доступ к другим ресурсам жестко ограничен. Обычно в таком случае делают белый список, в который вносят сайт. Обычно в таком случае другие сайты попадают редко. В таком случае, весь контент, включая скрипты, шрифты и картинки должен находиться у себя на хостинге.
Есть еще один, исключительно российский момент, называется Роскомнадзор. Если этим желтая вода ударит в голову, они могут прикрыть доступ и к гуглу. И сделано это будет под благовидным предлогом.

Apache Cordova.

Нет. Вы путаете клиентскую сторону и серверную.
node.js предназначена для работы на сервере. WebAssembly - запуск ресурсоемких приложений на клиенте.

Откройте для себя https://moodle.org/
Практически полноценная система для обучения.
В США на ней многие колледжи работают.

Вот этот курс https://www.youtube.com/watch?v=tKTZoB2Vjuk самый лучший.

Шаг 1, изучаем https://jwt.io/ - на настоящий момент стандарт для аутентификации.
Шаг 2. Каждое устройство должно иметь уникальный токен. Пользователь должен иметь возможность деавторизовать любое устройство. При смене пароля все токены автоматически стираются.

Организация хранения токена должна выглядеть примерно так:

tokens
- user_id
- device_id  - при авторизации через браузер можно подставить md5(User-Agent)
- device_name  - человеко-понятное имя девайса или название браузера
- token
- last_used
- expires_at

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

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

То, что нужно вам mirfazilov.uz/chto-takoe-tas-ix выберите подходящий хостинг под себя.

Из моего опыта - хостить видео нужно через стриминговые платформы, иначе все получается медленно и ненадежно. Вы самостоятельно не сможете настроить сервер правильно, а здесь это важно. Наймите профессионала.

Не надо ничего ограничивать. Это так называемый реферальный спам или входы поисковых роботов. Здесь нет ничего страшного.
В крайнем случае можете исключить трафик из результатов Google Analytics, там это легко делается через фильтры.

Запрещать нужно только в крайнем случае! Например, когда вас DDoSят трафиком в миллион юзеров в час. Что на практике редко бывает, да и то, только на несколько дней.

ruhighload.com/post/%D0%90%D1%81%D0%B8%D0%BD%D1%85...

Напишите свой API, цена ему копеечная. Можно хотя бы этим воспользоваться:
ruhighload.com/index.php/2009/04/22/%D0%BE%D1%82%D...

Я бы разделил бакеты по размерам, тогда можно было бы легко управлять ресайзами и удалять неиспользуемые размеры.

Идеального пути определения качества соединения нет.
Есть ограниченная поддержка NetworkInformation. Это наилучший подход, но он пока в ранней стадии разработки.

Классический способ определения скорости описан тут.

Разумный вариант - использовать легковесную посадочную страницу и расширенную версию с тяжелым контентом.
Слушать про onload секунду, если за секунду оно не наступает останавливаться на легковесном варианте, в противном случае грузить все остальное.
Вы также можете рассмотреть использование критического пути (минимально необходимого CSS), который включен в тело страницы изначально. Как только страница загружена, можно включать загрузку остального содержимого.
Еще можете замерять время загрузки страницы в браузере используя Navigation Timing API. Если оно больше определенного порога, то загружать тяжелый контент, например видео.

В целом путей решения поставленной задачи немного, но достаточно.
Сфокусируйтесь все же на оптимизации сайта или страницы. Поставьте себе планку, например 200кб и оптимизируйте сайт для нее. От этого выиграют все: и ваши пользователи, и серверная часть тоже.

А чем вас обычный OpenCart не устраивает?

Покопайтесь на newyork.craigslist.org
Порассылайте резюме, там иногда попадаются стартапы, которые готовы платить цену ниже рыночной, но дают некоторую свободу в плане посещения офиса и т.д.
Один важный момент - ваша виза должна разрешать работу в США, если у вас туристическая, то никто вас никуда не возьмет.

Некоторые используют гомоморфное шифрование.