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

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

по авторизации мы можем использовать JWT и уменьшить нагрузку на базу (для верификации токена не нужна база и не нужно этот токен нигде хранить, очень удобно).

Для всего остального и mysql справится если индексы расставить и возможно партицирование таблиц в далеком будущем (не ближайший год).

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

А зачем им то подключаться? вы ж микросервисы ваяете, вам zeromq надо а не давать доступы к key-value хранилищам которые использует сервис авторизации. Так вы создательно усложняете последующее масштабирование этой части системы.

хоть петабайты данных

Петабайты данных в реляционках никто не хранит, как минимум потому что такие объемы нет смысла хранить. У вас только логи могут быть такими, весь хлам потом можно будет скидывать в какую-нибудь кассандру (эпл в ней 4 петабайта инфы хранит).

В целом... мне кажется что вы слишком много-го ждете от своего проекта. С учетом характера вопроса и того где вы его задаете вам хватит и mysql. Все остальное решит ваша команда разработчиков.

https://github.com/PyFilesystem/pyfilesystem - что-то типа такого. ну или https://github.com/jpvanhal/siilo

лучше всего организовать автоматическую сборку исходников на сервере?

Лучше всего исходники собирать не на сервере. Разве что на CI-сервере. Делаем билд, и деплоим только артефакты билда.

Да и какие задачи вы делали когда только начинали?

Мне дали помниться в зубы ангуляр (1.0 еще), 2 недели на изучение оного и проект который надо сделать... и пришлось делать... было весело)

В целом помимо "подтянуть перед этим JS", сейчас я бы еще рекомендовал babel.js, без него уже не представляю как можно писать поддерживаемый JS код (можно конечно но его банально больше). Так же вам нужна удобная система сборки - рекомендую webpack, так как с ним проще стартовать и он форсит вас использовать модули. Рекомендую вот этот скелет проекта. Ну и приятный побочный эффект, у вас ваши сервисы не будут напрямую знать что они используются в контексте ангуляра.

Что до ангуляра - для начала я бы рекомендовал таки почитать документацию, angular styleguide и т.д. Хотя бы недельку. Так же рекомендую с ним использовать TDD (именно юнит тесты с моками всех зависимостей, если тесты писать тяжко - надо придумать как сделать так что бы было попроще, например мокать не http а сервис и т.д.), при обучении особенно хорошо. Очень упрощает поиск слабых мест вашей архитектуры приложения а так же позволяет проще его менять.

Если вы примите для себя пару простых правил, аля "стараться реже использовать все со знаком доллара напрямую", типа $scope в контроллеры не пихать, вообще поменьше зависимостей от ангуляра для ваших сервисов, стараться не юзать link у директив (ну или делать там только то для чего он нужен - для связывания директивы и DOM, мониторинг атрибутов и вызов контроллера директивы и т.д.), то жить станет чуть проще. Тогда ангуляр сам по себе станет чуточку проще. Ну и да, вообще не использовать независимые контроллеры (ни ng-controller ни контроллеры для маршрутов ngRoute ни для uiRouter, вообще посмотрите в сторону angular/router)

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

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

А потом реализовать какую-нибудь апу. А лучше вместе, пописали директивки, попробовали их заюзать. Неудобно - пилим дальше.

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

Как вы написали, контроллеры должны обрабатывать HTTP запросы, вот пусть они этим и занимаются. Берут запрос, забирают и обрабатывают данные, просят сервисы что-то сделать (а не делают сами) и потом выплевывают результат работы этих сервисов наружу.

API инстаграма это хранилище данных и только. Для работы с хранилищами существует шаблон "репозиторий". То есть мы делаем маленький сервис, который будет работать с API, а всему остальному коду и дела нет откуда эти данные берутся. Если вам надо будет добавить кеширование ответов API -можно завести сервис-декоратор, ну и т.д. Ну и для взаимодействия с самим API есть море готовых решений вплодь до готовых клиентов к инстаграму. Ваша задача все это дело закрыть фасадом, красивым интерфейсом через который ваши задачи решаются просто. Таким образом мы сокроем для приложения все сложность доставания картинок и т.д.

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

А еще было бы неплохо попрактиковать TDD но это если вам позволяет время. Вообще настоятельно рекомендую перейти на практику TDD (почитайте Кента Бэка на эту тему).

И еще говорят, что считается правка composer библиотеки напрямую изменяя код в vendor не хорошим, как дополнять либы новым функционалом?

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

Заводите переменную server_id например и для каждого хоста в инвентори файле определяете эту переменную.

https://github.com/puli/demo-application - реальный пример.

По поводу проблем с шиндовс - без указания на проблемы помочь тяжело.

php.net/manual/en/class.recursiveiteratoriterator.php и тогда один форич.

либо рекурсивная функция на основе array_search.

https://packagist.org/search/?q=rsa

для начала вам надо разобраться что такое куки. Как куки передаются на клиент. Что такое заголовки и тело HTTP запросов и ответов. И тогда все встанет на свои места. Ну а что бы небыло проблем - почитать про управление буферизацией вывода в PHP.

Чем куки отличаются от сессии в PHP?