LINUX.ORG.RU

Вызов SQL из клиента - просветление или рак?


0

1

Хотелось бы услышать мнения по поводу: http://www.breezejs.com/

Это штука, позволяющая из браузера выполнять запросы к БД типа такого:

var query = breeze.EntityQuery
           .from("Customers")
           .where("CompanyName", "startsWith", "A")
           .orderBy("CompanyName");

Пока что она мягко приклеена к .NET, сейчас ее портируют на Ноду, есть рабочие примеры для Жабы/Гиблонейта, попытки портирования на Похапэ/Доктрину и прочие популярные технологии.

Интересно узнать реальных батек, насколько такое использование может считаться «хорошей практикой». Ъ или !Ъ ?

Не приведет ли увлечение подобными технологиями к чуме брешей в защите веб-приложений

То что она полюбилась народным массам - это уже да, некоторые даже делают 10-часовые скринкасты про разработку на Angular+Breeze

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)

Да пусть клиент у себя апп сервер и бд разворачивает, чего уж там. Бекенду меньше хлопот.

Hater ★★
()

страсти то какие ... это ж сколько оверхэду в такой технологии. а можно реальные примеры для применения?

MikeDM ★★★★★
()
Ответ на: комментарий от MikeDM

Ну там же написано:

Breeze is a JavaScript library that helps you manage data in rich client applications. If you store data in a database, query and save those data as complex object graphs, and share these graphs across multiple screens of your JavaScript client, Breeze is for you.

Ну т.е. на очень увесистых клиентских приложениях.

Hater ★★
()
Ответ на: комментарий от MikeDM

ну типа фронтендщику проще делать фронтенд. Не нужно договариваться с бэкендщиком о интерфейсах взаимодействия, т.к. интерфейс взаимодействия генерируется автоматически с помощью этой софтины. Но бэкендщик должен как-то так извернуться, чтобы открыть наружу только публичное. Я сам еще не использовал, только смотрел хипстеров на скринкастах :3

а можно реальные примеры для применения?

для того-то и создан этот топик! Твои идеи?

stevejobs ★★★★☆
() автор топика

Всякое видел, деграданты передавали sql с клиента на сервер, хранили sql в кукисах, но orm на стороне сервера вижу впервые.

Показательно что это как-то ассоциировано с дотнетом, нодой, значит там востребовано, значит там все плохо.

outtaspace ★★★
()

Можно положить базу кучей запросов. Для пользователей я бы не стал такое делать, а для админки можно. Я в одной из админок вообще к Couch Restful API стучусь с фронтенда - удобно.

Проблема взаимодействия фронтенда и бекенда актуальная конечно, но такое ее решение мне не очень нравится :-)

Black_Roland ★★★★
()
Последнее исправление: Black_Roland (всего исправлений: 1)
Ответ на: комментарий от stevejobs

для того-то и создан этот топик! Твои идеи?

накол! =)

наркоманы какие то блин, все в свой JS тянут. ничего святого. =)))))

MikeDM ★★★★★
()

Запросы же наверное не сильно напрямую идут, так что ничего страшного.

slyjoeh ★★★
()
Ответ на: комментарий от MikeDM

страсти то какие ... это ж сколько оверхэду в такой технологии

Если нормально реализуется, то даже на PHP-движке оверхед формирования запроса будет совершенно незаметен на фоне времени отработки запроса базой.

KRoN73 ★★★★★
()

DoS - теперь ещё проще!

anonymous
()

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

vromanov ★★★
()
Ответ на: комментарий от vromanov

Для ынтырпрайза часто пользуют репозитории на стороне сервера: ['имя репозитория', 'имя запроса', 'аргумент1' ... 'аргументN']. В репозитории уже указаны права доступа. Это позволяет полностью забыть о такой сущности как БД - нет sql, есть список аргументов. Если нужно написать что-то более сложное, там где «сахар» не работает, можно через AJAX работать с произвольным сервером приложений.

outtaspace ★★★
()
Ответ на: комментарий от KRoN73

так ведь там и на отработке запроса будет оверхед, ибо его (запрос) надо усиленно проверять на валидность

next_time ★★★★★
()
Ответ на: комментарий от blexey

Сам отвечу на свой вопрос :)
Разве что база будет полностью состоять из вьюшек, тянущих реальные данные откуда-то ещё.

blexey ★★★★★
()
Ответ на: комментарий от next_time

так ведь там и на отработке запроса будет оверхед, ибо его (запрос) надо усиленно проверять на валидность

Фактически (как в сабже сделано — не знаю) можно не запрос слать, а инструкции к запросу. Т.е. JSON с теми же where: limit: order:... А на сервере уже собирать из этого запрос со всей валидностью. Всё равно это какие-то доли миллисекунд будет занимать. На фоне сотых-десятых долей секунды на простейшие запросы и секунды-десятые доли секунд на тяжёлых, всё равно мелочь.

Можно по приколу как-нибудь посмотреть, сколько будет ресурсов жрать одно преобразование JSON -> PDO.

KRoN73 ★★★★★
()

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

amomymous ★★★
()

А как запретить юзеру смотреть чужие ресурсы при такой архитектуре?

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

Legioner ★★★★★
()

портируют на Ноду

А, т.е. вариант на перле (что-угодно), который я делал был по моде: js <> http/json <> my_daemon <> openldap/anywhere. Давно пора, но прироста это не даст, ибо json-сериализация жрет нехило ресурсов и относительно тормозная. Более того, jquery надо патчить, ибо там вложенные структуры сделаны через одно место. Вобщем, посмотрим что получится :)

gh0stwizard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.