Pull to refresh
12
0
Данила Поярков @dannote

Пользователь

Send message
Ладно, если ваша аргументация уже скатилась до намеков, что, мол, я не понимаю разницы между Java и JavaScript, пора поставить точку.

К вашему сведению, я читал спецификацию ECMAScript 6 целиком и в свое время правил и писал байткод для JVM руками и ооочень хорошо чувствую разницу между этими двумя языками и их средами исполнения.

Ну а насчет вас я для себя уже все выяснил.
Если что, пример с PhantomJS был просто как наглядная демонстрация безумного нагромождения абстракций, сопоставимого с вашим «одной строчкой на Java».
Я вас только что процитировал, вы первоначально писали про де-/сериализацию JSON в Java. А вот о Document Object Model вообще ни слова не было и к сериализации данных ни в Java, ни в JavaScript-е это не имеет никакого отношения.

Что значит — какая связь?
Вы знаете разницу между Java и JavaScript'ом? Какой Reflection API?

А в чем проблема? Скажем в Java сериализация/десериализация json в java объекты делается буквально одной строчкой, причем никто не мешает добавить этим java объектам теги JPA и сразу напрямую сохранять их в ORM.


А вот DOM здесь вообще при чем?
В Javascript например ничего не происходит

А вот и нет, происходит. Только на этапе трансляции, а не интерпретации. А при десериализации в Plain Old Java Object либо дергается небыстрый Reflection API, либо на лету осуществляется кодогенирация, что не лучше. Нравится блуждать в мире абстракций — пожалуйста. Вот тут, например, люди запускают три интерпретатора JS (JavaScriptCore, JavaScriptCore и V8) и шлют данные между ними alert-ом через pipe в этом самом JSON и ничего, 1500 звезд на GitHub-е.
Если вы готовы дать кому-то возможность делать прямые SQL запросы в вашу базу данных,

Нет.

Я не говорил о том, что запросы должны идти без какой-либо авторизации.

SQL база данных всегда будет хуже эмулировать noSQL.

Нет.

ACID.

Модуль memcached к MySQL видели?

Просто посмотрите примеры и предстаьте себе нативную реализацию прямо в БД. Это не NoSQL в обычном понимании. Все тоже самое что с SQL, только другой язык запросов, который можно передавать в БД как есть, без лишних промежуточных представлений и строить на его основе execution plan.

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

Имя таблицы и так уже есть в путях во многих фреймворках.
Я тщетно пытаюсь донести мысль, что URL в REST теряет свое первоначальное значение становится и не идентификатором, а языком запросов, в чем-то подобным SQL (работающим в рамках реляционной модели), а значит, пора уменьшать прослойку кода. Особенно это актуально для single-page-applications, которые большую часть данных тянут на лету с сервера в том виде, в котором они представлены в базе данных и не стремятся выбраться за границы CRUD.

Пример скинул выше.
Практически в любом API, где имеется какая-то связность между объектами («сообщения пользователя», «комментарии к новости»), выстраиваются отношения один-к-одному и один-ко-многим. Пример — GitHub API, да и практически любой другой API в стиле Sinatra. Ссылки между объектами — это не хранение состояния. Под хранением состояния, например, подразумевается привязка результатов и контекста выполения к текущей сессии. От этого отказываются, поскольку при масштабировании проще всего, удобнее и надежнее создавать одинаковые ноды и не задумываться о переносе контекста. JSON — это не объект, это синтаксическая конструкция, описывающая объект, причем далеко не самым лаконичным способом. И если вы не понимаете, например, что именно происходит при сериализации/десериализации JSON в POJO, не понимаете смысл идеи RESTful, и, наконец, не понимаете, что я хотел донести, не нужно, пожалуйста, заводить спор.
Я упомянул HTSQL как отличную концепцию, а не как конкретную реализацию. Правильно было бы, на мой взгляд, сделать парсер путя с параметрами в URI в самой БД как отдельный модуль и для ряда запросов вообще обходить парсер SQL, просто поставив БД в upstream на кеширующий сервер. Это не всегда хорошее и не всегда универсальное решение, но практика показывает, что SQL нередко бывает bottleneck-ом. Если что, я сейчас потихоньку пишу такой модуль для MySQL, работая напрямую с InnoDB и со многими потенциальными проблемами знаком.
REST во многих его реализациях — это как раз и есть попытка сделать HTTP реляционным, я написал об этом в первом комментарии.
В триггерах — да, но кое-какие вещи сделать как view можно себе позволить.
Вопрос не в том, насколько легко это делается и тем более, не в том, на какой платформе. Вопрос в том, насколько много лишних действий происходит под этой кучей красивых оберток. В предложенном вами варианте вообще безумная цепочка: автоматическая десериализация JSON в POJO, потом автоматическая сериализация из POJO в подстроку SQL-запроса и наконец автоматическое построение SQL-запроса. Я первоначально хотел обратить внимание, что с учетом проблем object-to-relational городить relational-to-object-to-relational для простых задач просто абсурдно.
P.S., небольшая опечатка, имел ввиду /users/1/messages
В приведенной вами цитате я не настаиваю на какой-то конкретной парадигме, а всего лишь константирую факт и привожу примеры. С приципом CQRS я знаком и понимаю, что не так может быть с API, представленном в виде исключительно CRUD-операций.
Во-первых, OData хоть и открытый стандарт, все его нормальные серверные реализации написаны под .NET.
Во-вторых, он довольно монструозный и имеет легкий Microsoft-овский налет.
Пример запроса
services.odata.org/v4(S(34wtn2c0hkuk5ekg0pjr513b))/TripPinServiceRW/People('lewisblack')/Trips/$ref HTTP/1.1

И в-третьих, увы, многие попытки стандартизовать что-то в мире REST (и JSON API в частности) провалились.
Это не протокол поверх HTTP, почитайте повнимательнее. Это просто модуль, делающий запросы к MySQL (или Drizzle, для которого он изначально писался) асинхронно и выдающий данные в формате RDS, которые следующим модулем по цепочке (например, rds_json или rds_csv) уже непосредственно преобразуются в ответ. Этот модуль написан человеком из CloudFlare и вполне себе production-ready. Читать данные из POST-запроса можно, например, с помощь модуля form-input-nginx. Есть еще большой список того, что нужно для идеального полноценного API, но база для этого уже готова.
Основная проблема RESTful в том, что каждый раз при создании нового API фактически заново создается транслятор HTTP-to-SQL. Зачастую выходит так, что сам API имеет реляционный характер (/users/1, /users/messages), в коде приложения используется ORM, а потом снова используется реляционная модель. Особенно нелепо это выглядит в приложениях, которые делают только самые примитивные CRUD операции.

Есть, например, проект HTSQL, в котором на базе HTTP строится мощный язык запросов практически со всеми часто используемыми возможностями SQL, который напрямую транслируется в весьма оптимальный запрос на SQL. Для nginx (openresty) есть модуль ngx_drizzle, который умеет асинхронно отправлять запросы в MySQL и модуль rds_json, который в потоковом режиме строит из результатов JSON. Т. е. самое простое API можно создавать прямо в config-ах nginx как-то так:

location ~ /(?<resources>cities|rockets) {
  rds_json on;

  location ~ /(?<id>\d+) {
     postgres_pass   database;
     postgres_query  "SELECT * FROM $resources WHERE id=$id";
  }

  location ~ / {
    postgres_pass   database;
    postgres_query  "SELECT * FROM $resources";
  }
}


Конечно, помимо таких простых запросов часто нужна дополнительная бизнес-логика, но часть задач можно уже сейчас переложить на БД. Например, для небольших проектов на уровне БД можно делать авторизацию с помощью недавно появившегося в PostgreSQL row-level security.

В общем, нужно переосмыслять идею REST, а не плодить одинаковые решения с одинаковыми архитектурными ошибками.
Данные в БД можно каждый раз забивать при помощи db/seeds.rb, добавив в deploy.rb для роли demo строчку execute :rake, 'db:seed'. Asset-ы проще собирать локально один раз и синхронизировать rsync-ом. Для этого есть готовый gem.

А Sidekiq и Resque для чего-то кроме отправки электронной почты используете?
Я просто оставлю это здесь.

Скрытый текст
image

Аранов Сергей Андреевич

Новый прокурор Черноярского района Сергей Аранов в органах прокуратуры работает с 1998 года. В разное время он замещал должности старшего следователя отдела по расследованию ОВД прокуратуры Астраханской области, следователя по ОВД того же отдела, заместителя прокурора района, в 2003–2007 годы — прокурора Черноярского района, с августа 2007 года — прокурора Икрянинского района.

Телефон: (85149) 2-17-86

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity