• Часть 1: Nuxt as fullstack server: frontend + backend API Server
• Часть 2: Additional SSR performance with Nuxt fullstack server

В Части 1 я рассказал как легко организовать API Server в Nuxt. В Части 2 я хочу рассказать какие дополнительные преимущества можно извлечь из Nuxt fullstack server.

• Часть 1: Nuxt as fullstack server: frontend + backend API Server
• Часть 2: Additional SSR performance with Nuxt fullstack server

Разработчики Nuxt предлагают 3 метода доступа к API:

1. Встроенный в Nuxt сервер Connect и использование serverMiddleware
2. Интегрированные фреймворки (Express, Koa, Hapi и т.д.)
3. Внешние API сервера

Я покажу на простом примере как организовать API сервер с использованием serverMiddleware на том же инстансе Nuxt, который у нас отвечает за frontend.

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

Почему на триггерах? Потому что нет доступа к бинарному логу. Реализация с бинарным логом потенциально более производительная, хотя и более сложная в разработке, т.к. требуется парсить лог.

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

В целом же решение является законченным и комплексным. Может быть внедрено «как есть» и прекрасно справляться со своей задачей.

Привет Хабр! Хочу рассказать в статье мой опыт реализации бизнес логики (БЛ) в MySQL.

Есть разные мнения насчёт вопроса стоит ли хранить БЛ в базе. Я много лет работаю с Oracle и философия Oracle подразумевает, что БЛ в БД это Best Practices. Приведу пару цитат Тома Кайта:

Tom Kyte. Effective Oracle by Design
If the database does something, odds are that it does it better, faster and cheaper, that you could do it yourself

Том Кайт. Oracle для профессионалов.
Прежде чем начать, хотелось бы объяснить вам мой подход к разработке. Я предпочитаю решать большинство проблем на уровне СУБД. Если что-то можно сделать в СУБД, я так и сделаю. [...] Мой подход состоит в том, чтобы делать в СУБД все, что возможно. [...]
При разработке приложений баз данных я использую очень простую мантру:

• если можно, сделай это с помощью одного оператора SQL;
• если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;
• если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;
• если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке C;
• если это нельзя реализовать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать...

В то же время в среде web-разработчиков приходится слышать мнения, что БЛ в БД это чуть ли не антипаттерн. Но я не буду останавливаться на вопросе стоит ли реализовывать БЛ в БД. Пусть каждый решает сам. Тем, кто хочет посмотреть, что у меня получилось в свете не столь обширного (по сравнению с Oracle) инструментария MySQL, добро пожаловать под кат.

Привет Хабр! Мне довелось реализовать бизнес-процесс, который предполагал безопасность на уровне строк (Row Level Security) на mysql и php.



Row Level Security или безопасность на уровне строк — механизм разграничения доступа к информации к БД, позволяющий ограничить доступ пользователей к отдельным строкам в таблицах.