Евгений Вольф

Какие есть еще варианты? Какой выбрать?

Ещё есть варианты, типа Redis/Memcached, таблицы в памяти, вариант отключить синхронизацию с файловой системой в БД, использовать MongoDb или другую базу подобного плана и т.д., есть специальный тип таблиц, например, ARCHIVE в MySQL оптимизированные специально на запись... Масса вариантов, в общей сложности.

Шлем запрос на api, который ничего не делает. Потом грепаем логи по крону.

Не уверен, что это быстрее чем база данных.

Шлем запрос на api, там скрипт делает INSERT в базу - инсерт в базу скорее всего будет медленный, нафиг.

Если Вам нужен счётчик, это будет не "INSERT" а скорее "UPSERT" ("INSERT or UPDATE"), а ещё лучше сразу UPDATE (т.е. заводить запись с текущей циферкой счётчика до того, как будет пытаться её UPDATE'ить).

Шлем запрос на api, там простой скрипт делает append в файл. По крону считаем что там записалось - выглядит уже лучше.

А как на счёт конкурентного доступа к файлу?

Есть готовые решения или библиотеки?

Есть готовые API и примеры.

Можно ли получить свидетельство о государственной регистрации программы для ЭВМ с помощью веб программы ?

Что значит "веб программы"? Вы хотите "сайт" зарегистрировать как программу для ЭВМ? Это у Вас вряд ли получиться. Ну, а если речь идёт о программе написанной на каком-нибудь "веб-совместимом" языке, например, на Perl'е и для работы которой нужна некая специфическая среда (например, веб-сервер Apache и интерпретатор Perl'а) - не вижу никаких проблем с регистрацией. Если программу как-то можно распространять - не представляю, почему бы её нельзя было зарегистрировать?

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

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

Ну например выбрать 10 новостей в нужном формате
делаем GET запрос

Обычно делают POST-запрос, и не в формате адресной строки (GET-параметров), а отправляется так же, запрос в формате JSON. Обратите внимание на ключевое слово "обычно", т.е. не всегда.

Применяется такой подход к проектированию?

Это скорее подход к разработке, уровня "клиент-сервер", и/или REST API.

И может есть готовые решения о которых можно почитать.

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

Или есть какие то существенные минусы о которых я не догадываюсь?

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

Насколько я понимаю, Вы хотите обернуть РСУБД (SQL-БД), работающую через (unix-)сокет, в более примитивные API, выдающие ответы в формате JSON? А чем Вас ответ в формате "SQL result resource" не устроил? :) При использовании РСУБД (и не только) Вы так же можете сменить и шаблонизатор, и фреймворк и язык и всё остальное, а необходимый функционал написать на уровне самой БД, в виде хранимых функций/процедур, без дополнительных, ненужных цепочек передачи данных.

Browser Sync работает только при сохранении документа, как сделать чтобы стало как в LiveReload обновление «на лету»?

Вы не совсем корректно ставите вопрос. BrowserSync работает не при "сохранении" документа, а при его физическом изменении, на диске, с которого (диска) он этот документ и читает. Соответственно, что бы BrowserSync отображал изменение после "любого нажатия клавиши", нужно, что бы каждое изменение вызывало сохранение документа. Как это сделать и возможно ли это сделать вообще, в каждом конкретном случае - зависит от редактора, которым Вы пользуетесь, думаю, что ответ на этот вопрос (как автоматически сохранять каждое изменение в редакторе) Вы с лёгкостью найдёте в его документации или в виде какого-то плагина для оного (если конечно, Ваш редактор их поддерживает).

P.S. Не понимаю, какую проблему составляет нажатие CTRL+S и зачем Вам смотреть на документ в неконсистентном состоянии, но... не буду спрашивать :)

P.P.S.

как это реализовано в Brackets LiveReload

Подозреваю, что "LiveReload" про который в данном случае идёт речь - является частью самого Brackets'а, что позволяет ему считывать текущее содержимое файла, а так же отслеживать события "документ был изменен" минуя жесткий диск.

Можете посоветовать фреймворк и плагины (PHP или др.)?

PHP
1. Фреймворк - Laravel, Symfony - два лидера бекенд-разработки на ПХП в данный момент, в мире
2. Плагины, тысячи плагинов (пакетов) для Ваших PHP-приложений, найти можно что угодно, от редакторов DOCX и пр. подобных форматов, до WebSocket-серверов
3. Обязательно ознакомиться с тем, что такое Composer и как его использовать

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

P.S. CMS рекомендовать не буду, по морально-этическим и религиозным причинам.

1. Как объяснить это вебшторму? Что теперь нужно, во-первых, обновить все файлы из новой ветки и во-вторых, что изменения тоже надо пушить в новую ветку.

Есть два способа:
1. Влить в нужную ветку (которую обновляем) ветку (из которой берём файлы для обновления
2. Взять все файлы из нужно ветки (скопировать их куда-то), переключиться на ветку которую нужно обновить, перезаписать в ней все файлы (ранее скопированные)

2. Как при этом время от времени забирать изменения из ветки first? И потом обратно возвращаться в свою?

Время от времени вливать в нужную ветку - ветку first.

3. И как ничего нигде не испортить?

Не использовать "force" и прочие подобные варианты "насилия". В таком случае, "испортить" что-то будет довольно проблематично.

P.S. Про слияние ветвей в интернете довольно много информации, по этому ссылки не привожу.

Мне как back-end - щику трудно ужиться с этим БЭМ - ом.

Вам это совершенно не обязательно делать.

Зачем БЭМ когда есть SASS/SCSS/LESS.

Что-то из серии "Зачем мне холодильник, если я не курю", ну вы понимаете... :)

Шесть классов для простого button в регистрации.

Такого эффекта можно добиться и без БЭМ.

У меня код в IDE от JetBrains уходит далеко за белую полосу.

Обычно это решается с помощью комбинации Ctrl+Alt+L в IDE от JetBrains.

"Это бэм, я использую один стиль несколько раз и т.д".

БЭМ придумали не для того, что бы "использовать один стиль несколько раз", если почитать историю, то БЭМ был создан для решения вполне конкретных задач, о них Вы в принципе можете прочесть на оф. сайте БЭМа (не рискну перечислять самостоятельно, дабы не исковеркать смысл).

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

Не знаю :)

Так по мне БЭМ это вообще огромный костыль а не методология.

Отчасти Вы правы, но лишь от части. От "насколько большой части" - сказать трудно. Всё зависит от Вашего восприятия и субъективной реальности происходящего. Колоть монитором орехи - "большой костыль", но не от того, что монитор плохой, монитор хороший, но он создан для решения несколько других задач. Так же и БЭМ создавался для решения задач, с которыми он более ли менее успешно справляется. Проблема тут не в самом БЭМе, а в том, что толпы верстальщиков (сомнительного качества) кинулись "за новомодной соской"... как в басне Крылова - "Мартышка и очки", применять этот самый БЭМ там где надо и не надо. Препроцессор, например, SASS - это круто. Но это не значит, что для стиля "в 3 селектора" нужно за собой тащить целый препроцессор, нужно понимать, когда он действительно нужен, а когда CSS < 1Кб и можно обойтись "руками" (без препроцессоров).

БЭМ - это не только методология, но и ряд других инструментов, без которых он как по мне (*исключительно личное умозаключение, на истину не претендует), примерно настолько же полезен, насколько полезен SASS без своего "компилятора". Есть масса способов написать код лучше не хуже чем с применением БЭМ, которые вполне себе успешно работают в своём контексте.

P.S. Я не однократно встречал т.н. "БЭМ" код в проектах, где он вообще ни в какую не упёрся, но этом обусловлено не тем, что "БЭМ плохой", а тем, что верстальщик не может принимать оптимальных решений. Это выглядело как если бы, человек научился пользоваться пассатижами и побежал бы ими делать "всё", и колоть орехи и забивать гвозди и снимать кастрюлю с плиты, что бы не обжечься.

Что делать если при переходе на ссылку к существующей ссылке прибавляется ссылка?

Добавлять / в начале ссылок, что бы не было такой проблемы.

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

Я бы начал с того, что бы научился принимать платежи, для начала. Как только разберётесь со всеми документами и API платёжных систем, 90% вопросов на тему "как?" и 99% желания - отпадает обычно сразу.

Из моего личного опыта, PHP-код в этой цепочке - наименьшая из проблем.