Динамический cайт без кода на стороне сервера

делает запросы непосредственно к базе данных

уменьшить вероятность взлома

/0
Имхо, клиента сломать проще, чем сервер.

Все ограничения (на размер сообщений и т.п.) ложатся на базу данных.

Это будет оправдано только если твой веб-сервер — это админка этой самой БД.

Переизобретаем client side applications? Всё уже есть, причем давно.

http://angularjs.org/

Или даже http://www.sencha.com/products/extjs/

Или http://dojotoolkit.org

BAAS, смертный!

qooxdoo, только вот, мне эта хренота не понравилась

В целях безопасности жабоскрипт сильно огорожен. Не взлетит.

Погуглите "толстый клиент", можете почитать про все плюсы и минусы. К минусам следует добавить минусы жаваскрипта.

О! Да ты изобрел single page application.  Все придумано до тебя. Правда пока не получило распространения из-за гребанных SEO-шников, не желающих признавать, что их «профессия» сдохла.

js + localstorage с одной стороны, с другой только сервер с api.
как уже сказали ниже - это называется single page application

Так я ничего не придумывал. Просто интересно, взлетело бы это в плане обычного веб-сайта, а не корпоративного портала (где «все свои» и конфигурация клиентов известна)? А также в описанном мной случае серверное API будет простой лёгкой обёрткой над SQL. Ну а если бы взлетело, то можно было бы сделать стандартное API для доступа к удалённой SQL-базе данных из браузерного JavaScript.

Просто интересно, взлетело бы это в плане обычного веб-сайта

Оно уже давно летает. А стандартное API - http+json. Вот только с аутентификацией пока не все ясно. Кто-то пользует куки и сессии, кто-то токены в хедере. Есть еще интересная приблуда - модуль для nginx подключающийся прямо к постгресу - вот тебе и апи.

Ну а если бы взлетело, то можно было бы сделать стандартное API для доступа к удалённой SQL-базе данных из браузерного JavaScript.

Глянь MeteorJS.

Плюс только если тебе от этого меньше писать кода :)

Просто интересно, взлетело бы это в плане обычного веб-сайта, а не корпоративного портала

Вот как раз в случае сайта сомнений в лётных качествах на порядок (точнее 2 порядка) меньше, чем в случае портала.

Если обеспечение безопасности сервера ложится на клиентскую часть, то это гарантированный провал: либо клиент очень легко взломать (обычно именно этот случай, если, конечно, не применялась очень суровая обфускация), либо можно написать альтернативный клиент.

Индексация поисковиками таких сайтов, кстати, давно возможна. Google умеет. И активно пропихивает свой AngularJS, в котором всё связанное с представлением (шаблоны и пр.) перекладывается на клиента (Javascript), а взаимодействие с сервером осуществляется обычно через JSON API.

Не кривые SPA нормально индексируются поисковиками. Что это меняет для SEO-шников?

И еще есть некоторый процент хейтеров типа эдди, ненавидящих JS всей душой.

angularjs
Только зависит от ресурса. А то вот я написал движок для борды и в тяжёлых тредах памяти кушается раза в два больше обычного.

Если обеспечение безопасности сервера ложится на клиентскую часть, то это гарантированный провал: либо клиент очень легко взломать (обычно именно этот случай, если, конечно, не применялась очень суровая обфускация), либо можно написать альтернативный клиент.

Я предлагал возложить это на СУБД.

Не KISS. Ты предлагаешь возложить на СУБД всю ту логику, которую реализовывает бэкенд в Single-Page Application.

Я предлагал возложить это на СУБД.

Это как? Каждому пользователю сайта - отдельного юзера в мускуле? Это ж п*здец. Ну и ясен пень что такой вариант возможен только в случае __самой__ простой логики.

некоторый процент хейтеров типа эдди, ненавидящих JS всей душой.

JS скорее презирают, чем ненавидят.

Каждому пользователю сайта - отдельного юзера в мускуле? Это ж п*здец.

А чем это плохо?

Ну и ясен пень что такой вариант возможен только в случае __самой__ простой логики.

Можно хранимые процедуры использовать.

А чем это плохо?

Это дырища в безопасности. Во-первых, пользователь, имея права на таблицу, сможет получить доступ не только к своим, но и к чужим данным. Во-вторых, sql-инъекции еще никто не отменял.

Можно хранимые процедуры использовать.

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

Можно хранимые процедуры использовать.

Тогда это не без кода на стороне сервера. Да и вообще, БД — это уже код. Без кода — статические HTML. Они, в свою очередь, могут обращаться к любому другому источнику данных (если это разрешено источником).

Если что-то существует без кода на стороне сервера, то для чего тогда сервер? Тс приходит к кастрированному p2p.

А чем это плохо?

Ну и да, представь себе что у тебя есть 1КК пользователей в мускуле :DDD Как быстро, думаешь, будет выполняться простейший логин + select * from dbname.tablename limit 1; ?

ПС. Кстати прикольная идея, надо будет проверить :)

Во-вторых, sql-инъекции еще никто не отменял.

Как раз же наоборот. SQL-инъекция основана на том, что серверный скрипт коннектится к БД от пользователя, имеющего полный доступ ко всей БД. И задача взломщика — заставить скрипт выполнить произвольный запрос. А тут инъекций никаких не нужно, т.к. клиент будет иметь прямой доступ к БД, но от пользователя с урезанными полномочиями.

Сколько часов проработает андроидофон при хождении по таким сайтам?

Ок. А как ты хочешь ограничить права пользователя к части таблицы? Например свою почту читать можно, чужую нельзя. Под каждого пользователя отдельную таблицу создавать? Это раз. Два: каждому пользователю в информейнш_схеме придется давать права на каждую таблицу, к которой он имеет доступ. 1КК ползователей*(десяток таблиц+десяток-другой вьюшек+десяток-другой-третий процедур) = под 100КК записей для какой-нибудь гостевой книги. Да у тебя сервак загнется от того что кто-то просто залогинится.

http://www.opennet.ru/tips/info/1420.shtml

Или тоже повиснет? А вообще вроде собирались в postgres сделать row security, но никак. А в некоторых банальных СУБД давно есть. Абыдна, да?

Данных по сути хранить столько же, просто криво написанные бд так не умеют.

Какое столько же? Одних данных о правах выходит в 100 раз больше, чем полезных данных. Не умеют? Дык и не должны уметь. БД - это _база_ _данных_, а не комбайн данные+логика. Может ты еще удивишься почему мускуль не умеет письма отправлять и на днс-запросы отвечать?

Тем более повиснет. Так еще больше данных о правах выходит.

Одних данных о правах выходит в 100 раз больше, чем полезных данных.

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