CodeIgniter *

Привет, Хабр! Все мы знаем золотое правило: никогда не хранить секреты в коде. Но на практике часто оказывается, что за этим строгим запретом скрывается лишь папка с .env-файлами на сервере, доступ к которой есть у половины команды. А потом случаются утечки, скомпрометированные API-ключи и паника.

Хранение секретов — это не про запреты, а про инструменты и процессы. В этой статье мы разберемся, как организовать управление секретами на профессиональном уровне, и посмотрим на два подхода: мощный самодостаточный HashiCorp Vault и элегантный developer-friendly Doppler.

Привет Сообщество! Хочу впервые поделиться тут своим опытом разработки сайта и рассказать про сам процесс разработки. Надеюсь, вам будет очень интересно почитать и поделиться своим мнением.

Продолжим строить подобие JSON-RPC сервера, начатого в части 1 и анализировать его плюсы и минусы. В прошлой статье был описан механизм отделения бизнес логики бэкенда от транспортного протокола (HTTP) через шаблон проектирования "Front Controller", роль которого исполняет в нашем случае JsonRpcController.

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

Для передачи данных по сети есть хорошо зарекомендовавшие себя стандарты - например, SOAP, gRPC, AMQP, REST, GraphQL.

При создании вебсайтов малой, средней и большой сложности с потоками данных к бэкенду и обратно в JSON формате обычно используются последние два с их вариантами. Верней, только варианты, потому что REST и GraphQL - ресурсо-ориентированные стандарты. Это как бы просто перенос элементарной работы с базой данных на клиента (хотя под "ресурсом" может пониматься и абстракция). Обычно таких запросов не больше трети от всего бэкенд API.

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

Благодарю за отклики

Получив разноплановые отклики в виде комментариев и «кармы» на свою первую статью на Хабре «Фреймворк на PHP: CodeIgniter 4. «Лёгкий пример» использования Database Migrations (миграций) и Seeding (посев)», особенно хочется отметить тех членов сообщества, которые разделили точку зрения автора и в своих комментариях нашли нужные слова, чтобы поддержать автора в его намерении поделиться впечатлениями, что CodeIgniter 4 — это актуально.

Познакомиться с PHP фреймворком CodeIgniter 4 достаточно просто.

Нужно потратить вечер, выполняя инструкции из раздела  «Build Your First Application» («Создайте свое первое приложение»). Поскольку документация написана хорошим, технически понятным языком, то в процессе ознакомления с этим и другими разделами возможно получить даже некоторое эстетическое удовольствие.

• Фреймворк выпущен под лицензией MIT
• Обширный рефакторинг драйвера баз данных
• Полная поддержка PDO
• Новая библиотека для работы с сессиями
• Новая библиотека шифрования
• Доработано модульное тестирование, улучшилось покрытие кода
• Рекомендуется PHP 5.4 или новее, но CI-прежнему будет работать на PHP 5.2.4

Добрый день, уважаемые Хабрачитатели.