motomac

Если нужна полноценная современная замена WP, то ghost.org (либо hosted, либо self-host).

Если это именно поломка таблиц (а не просто их очистка кем-то), то должен помогать REPAIR. Если так, то у вас скорее всего движком MySQL выступает допотопный MyISAM. Он очень подвержен повреждениям. Смените его на InnoDB, и повреждений не будет.

После подключения JS SDK, который вы упомянули, вы можете получить информацию о юзере из Javascript, просто прочитав значение переменной `window.Telegram.WebApp`. Вернется вот такой объект. Если этот объект распарсить, в поле `user` будет объект юзера со всеми необходимыми полями.

Имейте ввиду, что юзер теоретически может подделать эти данные, т.к. они приходят из его браузера. Потому Телега подписывает все, что вам передает полем `hash`. Вам надо будет его проверить: https://core.telegram.org/bots/webapps#validating-...

По всей видимости, нет подключения к БД. Какую БД используете? Если MySQL, проверьте, запущен ли сервер MySQL, можно ли к нему подключиться, а главное правильный ли тип БД, адрес и пароли указаны в `.env`. Дока Лары очень подробно описывает процесс установки.

А насколько большая команда разработчиков? Это я к тому, имеет ли смысл разделение на фронт+бэк? Если и фронт отдельно, и бэк отдельно очень сложные, и работать над ними будут две разные команды, либо будет несколько клиентов (фронт, мобилка, например), то да, определенно стоит разделить. Если же разработчиков немного, а фронт это только веб, я бы смотрел в сторону монолита на Laravel. Благо у него сегодня есть прекрасные инструменты для фронта (Livewire, тот же Vue из коробки). Просто затраты на согласование API, его расширение, апдейты, да и просто коммуникацию между фронтендерами и бэкендерами это довольно сильный тормозящий фактор и значительное усложнение всего. Выкатка одного мелкого изменения начинает затрагивать сразу несколько человек и кодовых баз. Иногда оно просто не стоит того.

warp.dev - альтернативный терминал на Rust
https://panic.com/transmit/ - лучший для SFTP

voice.google.com раньше позволял зарегистрировать номер. Правда, не уверен, что сейчас этот аттракцион неслыханной щедрости еще работает.

Если прямо обязательно без промежуточного хранилища, то Resilio (бывший BitTorrent Sync).

По второму вопросу я бы не парился с поднятием собственного брокера и использовал какой-нибудь публичный. Например, www.mqtt-dashboard.com. Устройства подключаются к брокеру и пишут в один топик, ваш сайт/страничка подключается к тому же брокеру и подписывается на этот топик (MQTT over WebSocket). Для реализации этого можно использовать JS библиотеку https://www.npmjs.com/package/mqtt

В обратную сторону аналогично. Устройства подписываются на другой топик и слушают команды, отправленные в него с вашего сайта/страницы.

Самый минимальный набор знаний и технологий это Node.JS на бэкенде и любой JS фронтенд (хоть jQuery, хоть ванильный JS), работающие по WebSocket. Самый простой вариант реализации вебсокетов библиотека socket.io. Примеров тьма. Запилить минимальный чатик на этом можно за пару вечеров при условии знания JS.

Далее можно уже пилить хранение истории, регистрацию, например, добавив к бэкенду MongoDB или MySQL.

Если используете OAuth 2.0, можно ошибки возвращать в том же формате, дополнив своими кастомными секциями:

{
  "error": "spaceshuttle_crash",
  "error_description": "Houston, we have problems",
  "error_uri": "https://nasa.com/error.html",
  "my_custom_error_code": 42
}

Перепробовал много всяких эверноутов и прочих симплноутов с куипами и остановился на https://paper.dropbox.com. По-моему, самый приятный, и markdown поддерживает.

Пока нашел только https://browsec.com. Их расширение для Chrome позволяет настроить сайты и страны (в бесплатном тарифе только один).

Есть схожий и уже работающий проект Iridium. Для него уже есть в продаже готовые модули за 250 баксов:



Думаю, SpaceX откроет все спецификации и позволит сторонним производителям делать такие трансиверы, что сделает их очень дешевыми. Платить скорее всего придется за пользование самой сетью. В Iridium так.

Делаем два метода аутентификации: Resource Owner Password Credentials Grant и Refresh token grant.

SPA отправляет логин/пароль юзера на первый endpoint. В ответ получаем access_token (например, JWT), refresh_token и expires_in. Сохраняем все это добро куда-нибудь, например, в Local Storage. Время жизни JWT-токена лучше ставить небольшое (например, 1 час), потому что отозвать его нельзя. Далее SPA при каждом запросе к API проверяет время жизни токена expires_in из Local Storage, и когда оно истекает, отправляет запрос на обновление токена (refresh_token). Все это прозрачно для юзера.

Stateless, по-моему, и проще, и универсальнее. Если потом делать, например, мобильное приложение, API переписывать не придется.

Вся фишка JWT по сути только в том, что не нужно дергать БД при каждом запросе к API. Делать это придется, например, только раз в час при refresh'е токена. Больше никаких существенных преимуществ перед традиционными токенами, хранящимися в БД, нет.

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

Тоже использую develop ветку для подобного, но в последнее время все больше склоняюсь к мысли, что это не нужно.

1. Пушить незаконченный код не хочется
   
2. Придумывать этому незаконченному коду описание при каждодневной работе утомляет
   
3. На историю коммитов потом смотреть больно
   

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

В спецификации OAuth 2.0 (если вы его используете) явно указывается формат:

Authorization: Bearer <token>

https://tools.ietf.org/html/rfc6749#section-7.1

Думаю, не лишним будет следовать ему.