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

это не бэм.

Первый способ, как я понял, заворачивать в Элемент

Не совсем "заворачивать", просто только элементы отвечают за позиционирование, а блоки - задают базовые стили.

<!-- у элемента в принципе не обязательно должен быть блок, но желательно -->
<div class="page__wrapper block"> 
    <div class="block__header header"></div>
</div>

Ну то есть идея примерно такая.

а второй добавлять вспомогательные классы как-то так

Это вообще не БЭМ, это... ну как через атрибут style только меньше проблем, но куча дублирования.

Вообще рекомендую вам посмотреть вот это: WSD в Новосибирске // БЭМ — норм, Вадим Макеев

2-ой вариант.

если вы можете ваши данные так раскидать - значит сможете потом шардинг настроить когда место закончится. А к шардингу стоит прибегать когда память не хватает (например у меня сейчас есть миленький сервачек с 256 гигов оперативки, есть ребята и покруче).

Решил сделать простую игру.

MVC для приложений, для игр оно не применимо так как у вас UI и предметная область слишком уж сильно связаны друг с другом, а MVC ставит перед собой цель именно "развязать" их. Конфликт идет уже в фразе:

Модель хранит в себе спрайт.

Модель должна хранить данные, то есть это симуляции каких-то процессов, ИИ, физика и т.д. Ну а спрайты - это по сути представление данных. И как вы могли заметить игра без графики - не игра и не имеет смысла. А вот сменить UI у приложения можно, на бизнес логику оно не влияет.

Короче для игрушек обычно применяют чуть другой паттерн, под названием ECS (Entity-Component-system), которы позволяет разделить обязанности чуть-чуть подругому.

p.s. но если вернуться к MVC - то третий вариант. А что до

Но за хранение состояний должна отвечать модель.

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

Гуглите Entity-Attribute-Value.

А еще есть другой координальный ход - откажитесь от mysql и используйте mongodb для хранения каталога товаров.

Создавать по модели на каждое представление?

Модель в контексте MVC это не модель отдельных сущностей, а модель части системы (или всей системы), которая нужна для этой конкретной view. То есть представьте себе "модель" системы как нейкий объект, внутри которого есть другие объекты, которые работают с третьими и так далее. Такая вот иерархия. Так вот вьюшки выходит коннектятся каждая к своему кусочку этой иерархии, и по сути кроме этой точки соприкосновения ничего более о системе не знают. У них весьма ограниченное представление о системе и много знать им не надо.

Так вот. В REST "вьюшка" у вас - репрезентация ресурса. И они не должны (хоть и могут) быть проекцией таблиц в базе данных.

Получается на каждую сущность по 20 моделей?

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

Так же есть подход, описанный в стандарте jsonapi.org, где у вас есть дополнительные параметры в query string, которые позволяют "включать" определенные группы связанных ресурсов и т.д. Это дает нам определенную гибкость в плане работы с API но в случае например мобильных приложений есть свои нюансы.

появилась какая-то боязнь ошибиться.

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

1) продолжаем учить "ванильный JS", паралельно почитывая про babel, es2015 и т.д.
2) когда мы ищем информацию в интернетах - учитываем что сейчас актуальная версия ангуляра - 1.5, второй ангуляр в бете, так что 90% информации устарело. Я даже больше скажу - даже официальная документация устарела, обновленный вариант сможете найти на github проекта в пул реквестах.
3) https://github.com/gdi2290/ngExam - рекомендую этот список тем того, что вам надо знать про ангуляр (ну и не только).
4) https://github.com/AngularClass/NG6-todomvc-starter - тут я попытался собрать полезные статьи на тему что надо учить и как + пример маленького современного приложения. Так же в ишусах к NG6-starter обсуждается как лучше его готовить.
5) https://habrahabr.ru/post/277087/ - про angular 1.5 и то как я готовлю ангуляр.

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

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

возьмите uiRouter, там есть возможность делать иерархию вьюшек. Ну или component router если вы всеравно будете брать angular 1.5.

Если вы еще не начали - рекомендую взять вот этот стартер (на правах рекламы).