darksladen

В общем случае, берете все данные, которые необходимо показывать при загрузке, и вставляете в страницу при начальной загрузке. Затем подгружаете другие данные через API по мере надобности.

Например, в указанном вами примере, уверена, там нет загрузки все ста тыщ данных, да никто и не будет сразу столько смотреть. Загружают какое-то количество, ну допустим, 30, и то не сами песни, а только их заголовки + какую-то дополнительную информацию. Когда вы кликаете на заголовке, уже идет подгруз самой песни. А можно еще сделать так, что песни загружаются сами по мере прослушивания, но тогда, правда, будет усиленный трафик.

Именно так. Вход - пишем в базу сессию. Выход - стираем в БД сессию. Если сессия есть - второго не пускаем. Есть недостаток что юзер не вышел, а просто оставил вкладку открытой и ушёл но не работает, а другого в этот момент не пустит. Тогда можно при отсутствии каких-то действий в системе убивать сессию каждый 10 минут например.
Ещё можно принудительно выкидывать первого юзера, так например на pastebin сделано, с другого ПК логинишься - всё нормально, но стоит сесть за первый - оттуда выкинуло уже.

Bower помер. Используйте npm или yarn. Также крайне рекомендую освоить webpack. Он как раз и позволяет указать только единственный файл - точку входа, все остальное он подтянет автоматически и создаст два минифицированных файла - в одном скрипты, в другом стили. Само собой, можно настроить так, чтобы сторонние либы выносились в отдельный файл, а собственный код - в другой файл. Например, при использовании webpack, можно подключить jquery так:

import $ from 'jquery'

Можно сделать еще круче, чтобы не импортить jquery в каждом файле, можно заюзать вебпаковский плагин ProvidePlugin:

new webpack.ProvidePlugin({
  $: 'jquery',
})

После чего jquery будет доступен в любом js-файле.

Там же даже поиск есть

Чот плоховато искали: Appearance & Behavior → System Settings → Startup/Shutdown

По умолчанию используйте openserver.
Если вам понадобится что-то больше (сфинкс, эластик, рэббитMQ), то берите вагрант

Здесь плохо всё, к сожалению.

Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

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

$result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

?

Вы вызываете connect() в методах. То есть, каждый вызов этого метода будет приводить к установке нового соединения с базой данных, даже если оно уже было установлено. Соединение с базой данных это достаточно дорогостоящая операция.

Зачем вы используете свойства, если можно обойтись обычными локальными переменными:

$this->orderID = (int) strip_tags($orderID);
$this->column = (string) strip_tags($column);
$this->value = (string) strip_tags($value);

?

Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
strip_tags($orderID);
?

Если вы не используете php 7 и, как следствие, скалярный тайпхинтинг, то должны делать проверки на тип входящего аргумента. Если что-то не так с типом, бросаем исключение (А не приводим его к нужному)! Например:

if (!is_string($arg)) {
    throw new InvalidArgumentTypeException('string', $arg);
}

Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

Вам пока рано писать такие велосипеды. Судя по всему, у вас нет опыта вообще. Посмотрите готовые решения: фреймворки, ORM, изучите их, хотя бы поверхностно разберитесь, как оно работает и уже потом пробуйте что-то сделать, исходя из полученных знаний.

Желаю успехов!

Android

Evernote, в том числе преимущественно для тех целей, что у вас Покет - то есть для "почитать позже". А точнее - собираю свою собственную Wikipedia по интересующим меня темам. Правда добавлять можно только с большого компьютера, а на телефоне можно только читать. Время от времени просит денег, но возможностей бесплатной версии более чем достаточно.
Telegram/Whatsapp
Mail (две разные фирменные: под ящик mail.ru программа Mail.Ru и под ящик GMail программа Google Inbox, 2 разные потому что исхожу из того, что у них может быть какое-то свое API, более интеллектуальное, чем универсальный IMAP, судя по торможению нефирменных программ, которые работают с Mail.ru и GMail через IMAP)
DuoLingua
LinguaLeo, платно
CashOrganizer, платно. Есть бесплатная версия новая. Но я привык к старой версии, там другой интерфейс. Пришлось купить.
Браузер встроенный Samsung Browser. На старом телефоне юзал Firefox и Chrome. Но встроенный у Samsung достаточно хорош, его достаточно.
Taxi-Maxim, работает не для всех регионов.
VKontakte
Клиент-банк моего банка
JuiceSSH, купил. Есть бесплатный довольно крутой аналог, то в том аналоге нет поддержки mosh
Endomondo, купил. Есть бесплатные аналоги. Например, Nike Running кажется.
AnkiDroid
Orfox/Orbot
Дубль-Гис, есть не везде. Но где есть - очень удобная штука.
Skype
Slack
OsmAnd+ для путешествий за пределами городов, в диких горах, купил. Бесплатно можно использовать, кажется карты 3-х регионов. А мне было нужно чуть-чуть больше регионов.
Apox Proxmox, купил
bVNC
Key2Lay, купил. Только для ввода паролей, которые пишутся кириллицей, но в латинской раскладке.
Apple Music, платно
Google Analytics
Google Cloud

Но всё таки вставлю свои пять копеек
Если задачу возможно решить без флекса то уж лучше обойтись , это на display:inline-block; делается легко и само получается адаптивно
https://codepen.io/simkaUser/pen/EwZPZm?editors=1100 -- display:inline-block
https://codepen.io/simkaUser/pen/NadNWr?editors=1100 -- flexbox хотя наверно я не понял суть

Слухи вас обманывают. Кроме того это задача, а не проблема : )
https://jsfiddle.net/a25z8uy6/1/
ещё вариант по просьбе ТС:
https://jsfiddle.net/9vdes60x/1/

transform: translate как самый быстрый вариант. Позволяет двигать, что угодно и куда угодно.
Если время есть, то можно двигать с помощью внутренних паддингов у нужного блока. В любом случае, заказчик мыслит визуально, а не структурно. ему по фигу на ваши флексбоксы.

Вообще, сомнительная затея, так как у все свои интересы. У меня еще есть RSS на работе, там еще куча всякого, чего вам точно будет неинтересно :)

В основном всё верно. Я бы немного подправил следующие моменты:
>> Пользователь отправляет, это "что-то", полученное при регистрации и в ответ получает страницу
Не пользователь, а клиент (пользователь сидит за компом). Но клиент - не ваша программа, а в основном браузер (curl - тоже клиент) и ваша программа максимум может иметь доступ к некоторым кукам, да и то не ко всем (как настроит куку сервер, см. cookie httponly). Сервер проверяет токен и сопоставляет контекст приложения (php/java) с параметрами пользователя (_GET/_POST/_SESSION), поэтому код backend как правило никак не может влиять на контекст пользователя, только если в нём нет ошибок на выполнение критичных операций. (Естественно, что нужно разбираться в архитектуре сервера, т.к. на уровне фильтров, а в tomcat/IIS они есть, можно сделать много чего нехорошего ещё до обработки запроса под пользователем).

>> Что представляет из себя токен? (случайную строку, которая является по сути идентификатором? Если да - то какой она должна быть длины, нужно ли ее шифровать и где хранить на стороне клиента?
Токен - это уникальный идентификатор сессии в формате именно строки. Можно в него вставить JSON.stringify(), но браузер всё равно будет идентифицировать его как строку. Символы ему без разницы. Выдаётся на сессию на одном клиенте. Т.е. если вы подключитесь/логинитесь разными браузерами под одним логином пользователя, то у них будут разные токены. Однако, если вы технически сможете своровать токен из одного браузера и воткнуть его в другой, то фактически будете работать под одной сессией в разных браузерах и проходить аутентификацию во втором браузере не придётся (Иногда этим можно пользоваться для тестов). Именно по этом причине токены надо зарывать по максимуму, т.е. отправлять их в заголовках и в протоколе HTTPS. Только это не касается протокола Kerberos, там аутентификация производится другим механизмом и завладевание кукой не даст результата (весьма сложный механизм, используется в корпоративных сетях, не в интернете).
где хранить на стороне клиента - Для кук браузер сам их хранит и сам же дописывает в заголовки при выполнении запросов, так что это делается прозрачно. Поставьте fiddler, там всё видно.
нужно ли ее шифровать - Обычно нет.

>> Слышал про OAuth и долго и коротко живущие токены
OAuth используется, когда вы хотите привлечь большое количество пользователей, предполагая, что у них есть аккаунты в соцсетях, т.е. этот протокол упрощает и регистрацию и аутентификацию, но сложнее в настройках, чем form-based. тут есть одна тонкость - аккаунт пользователя в вашей программе надо будет всё равно создавать и связывать его с аккаунтом профиля в соцсети (сейчас подробнее не скажу, давно занимался)
Теперь какая связь между токеном и OAuth - Делаем выход из контекста рассуждения "на уровень выше" и вспоминаем, что OAuth - протокол аутентификации, а после аутентификации нужно (барабанная дробь ...) тадам - установить токен сессии!!! Т.е. с помощью OAuth вы только проверяете валидность пользователя, затем ваша программа выясняет с каким аккаунтом на вашем сайте он связан и устанавливает токен/куку, чтобы не проходить аутентификацию каждого запроса от пользователя аккаунтов с соцсети. Ну, представьте, что даже на CSS и IMG надо будет требовать подтверждение? (если только не настроен NGINX для отдачи статики, как вы указали выше).

>> Если да - то какой она должна быть длины
Посмотрите на форматы и размеры токенов, которые выдают соцсети? Да, взять этот же toster.ru, вот прям сейчас:


Токен сессии придумываете самостоятельно. Хоть sid. Формат строки токена ничем не определён. Главное, чтобы при идентификации пользователя случайно не выдать аналогичный токен другому пользователю, а то получится, что два пользователя идентифицируются сервером как один, кто первый залогинился. Так что одна из проблем сервера - обеспечить уникальность токенов сессий, а это важный раздел безопасности. Вполне можно поискать способы компрометации выдачи "нужных" токенов и тогда безопасность сайта под большой угрозой.

>> Достаточен ли уровень безопасности OAuth или стоит искать что то другое? jwt?
Поскольку OAuth тоже начинается с "вешалки", т.е. с form-based аутентификации в соцсети, то главное обеспечить достаточный уровень секретности - HTTPS и всё будет норм.