LINUX.ORG.RU
ФорумTalks

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

 , ,


0

1

Вот интересно, что если сделать так. На серверной стороне — только база данных и веб-сервер со статическим контентом. Клиент получает веб-страницу с JavaScript-кодом. Этот код выполняет все те функции, которые обычно выполняют скрипты на стороне сервера (за исключением ограничений доступа, чем занимается база данных). Он делает запросы непосредственно к базе данных и на основе результатов генерирует HTML-код. Если пользователь хочет запостить что-то, то скрипт делает insert-запрос. Все ограничения (на размер сообщений и т.п.) ложатся на базу данных.

Интересно, есть ли у такого подхода хотя бы гипотетические плюсы? Гипотетически снижает нагрузку на сервер, перенося её на клиента, что может уменьшить вероятность ЛОР-эффекта и части DDoS-атак, уменьшить вероятность взлома. Минусов, конечно же, полно: высокая нагрузка на клиента, невозможность на текущий момент индексации поисковиками, недостаточная гибкость средств ограничения доступа в СУБД.

☆☆☆☆☆

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

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

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

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

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

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

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

Pentium02 ★★ ()

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

Eddy_Em ☆☆☆☆☆ ()

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

ya-betmen ★★★★★ ()

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

ioway ()
Ответ на: комментарий от Eddy_Em

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

system-root ★★★★ ()
Ответ на: комментарий от ioway

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

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

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

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

ioway ()
Ответ на: комментарий от Ttt

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

Глянь MeteorJS.

theNamelessOne ★★★★★ ()

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

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

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

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

ya-betmen ★★★★★ ()

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

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

Deleted ()
Ответ на: комментарий от ioway

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

Deleted ()
Ответ на: комментарий от ioway

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

Deleted ()

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от Ttt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

note173 ★★★★★ ()

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

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

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

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

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

drull ★☆☆☆ ()
Последнее исправление: drull (всего исправлений: 2)
Ответ на: комментарий от drull

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

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

Ttt ☆☆☆☆☆ ()

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

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

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

drull ★☆☆☆ ()
Последнее исправление: drull (всего исправлений: 2)
Ответ на: комментарий от drull

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

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

Ttt ☆☆☆☆☆ ()
Ответ на: комментарий от drull

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

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

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

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

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

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

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

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

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