плюсы и минусы серверной реализации javascript?

https://stackoverflow.com/questions/1476967

16-09-2019
|

Вопрос

Я только начал экспериментировать с Аптана Джаксер серверный движок javascript для моего следующего проекта.И у меня есть несколько вопросов по этому поводу

Используя серверный JS, можем ли мы реализовать все веб-приложение без использования каких-либо серверных языков (таких как C #, Java и т.д.).Или JS на стороне сервера находится между веб-сервером и другим языковым стеком.
Действительно ли это лучший подход ??
каковы преимущества и недостатки?
как это хорошо работает с точки зрения производительности?
существует ли какая-либо реализация в реальном времени (общедоступные веб-сайты) только с использованием JS на стороне сервера (никаких других языков)?
какие альтернативы доступны поверх Aptana jaxer (с открытым исходным кодом)??
насколько хорошо мы можем внедрять и поддерживать транзакции в базе данных?можем ли мы сделать это на стороне сервера JS ..?
возможно ли разработать RESTful и SOAP сервисы на стороне сервера JS ..??

я знаю, что это слишком долго (и наивные вопросы).Я просто надеюсь, что кто-то уже сталкивался со всем этим при внедрении serverfide JS.

Редактировать:

Согласно комментариям Мэтью и Кена, я внес некоторую ясность в вопрос Действительно ли это лучший подход??

это то, о чем я намерен спросить..

Действительно ли это лучший подход, чем использование языков на стороне сервера (предположим, c #), как мы можем сравнить это с реализацией веб-сайта на c # (производительность, языковые возможности)??И какой из них является лучшим подходом, используя только JS на стороне сервера или JS на среднем уровне между другим языковым стеком и веб-сервером??

Решение

Я являюсь разработчиком для Майна (www.mynajs.org), серверная JS-платформа с открытым исходным кодом, основанная на Rhino и Java.Я рассмотрю проблемы, поскольку они относятся к Myna, но многие из этих моментов применимы к серверному JS в целом:

Используя серверный JS, можем ли мы реализовать все веб-приложение без использования каких-либо серверных языков (таких как C #, Java и т.д.).Или JS на стороне сервера находится между веб-сервером и другим языковым стеком.

В Myna можно написать все ваше приложение на JS.Myna уже включает API для доступа к базе данных, объектно-реляционного отображения, crytogrophy, OpenID и т.д.

Действительно ли это лучший подход, чем c # / Java?

С сервером на базе Rhino тривиально переходить на Java всякий раз, когда это необходимо.Вы можете легко установить библиотеки Java с открытым исходным кодом / коммерческие / написанные вручную, а затем написать их из JS.Это означает, что вы получаете быструю разработку JS, но сохраняете преимущества платформы Java

каковы преимущества и недостатки?

плюсы:

Быстрое развитие:В Myna вы просто создаете файлы в webroot с расширением .sjs.Это означает, что вы можете создать цикл редактирования-сохранения-обновления браузера с очень быстрой отладкой / настройкой кода.
Простой JSON:Наличие поддержки JS на стороне сервера означает, что перемещать сложные структуры очень легко
Общий код:Если вам нужно выполнить одну и ту же функцию как на сервере, так и в браузере, вы можете использовать один и тот же код
Динамический ORM:Статически типизированные скомпилированные языки затрудняют изменение объектов во время выполнения.Обычно это означает, что ORM должен быть определен заранее.В Майне построение ORM так же просто, как
```
var manager =new Myna.DataManager("DataSource name").getManager("table name");
```
Вы получаете объект, который может выполнять все основные операции CRUD без какого-либо явного определения таблиц базы данных.В качестве другого примера вы можете вставить строку со всеми соответствующими значениями из записи формы:
```
manager.create($req.data);
```
Функциональное Программирование:Если вы начали играть с расширенными функциями JavaScript, то вы оцените, насколько они полезны на стороне сервера.Благодаря согласованной серверной среде безопасно использовать расширенные функции, такие как Множество Дополнительных функций, генераторы и итераторы, разрушающие назначения, и E4X

минусы:

Инструменты:Статически типизированные языки, такие как C # и Java, имеют отличные IDE и инструменты разработчика.Динамические языки, такие как JS, просто пока не имеют инструментальной поддержки.Лично я считаю, что значительное сокращение шаблонного кода и привередливое приведение типов компенсируют это, но это все еще большой недостаток, если вы много занимались разработкой в IDE.Если вы в данный момент используете IDE, рассмотрите возможность использования джедай для динамических языков
Зрелость /Стандартизация:Серверный JS по-прежнему является новой парадигмой, и в нем много игроков, но нет явных победителей.ECMA не имеет никаких стандартов для JS на стороне сервера.Как упоминалось в ответе Брэндона, Общие JS group пытается сформировать серверный стандарт JS, и у Myna есть экспериментальная поддержка CommonJS через Нарвал

как это хорошо работает с точки зрения производительности?

По скорости необработанных вычислений немногие динамические языки могут сравниться со статически типизированными скомпилированными языками, такими как C # и Java.Сказав это, это действительно не имеет значения.Любая часть вашего приложения, требующая больших вычислительных затрат, вероятно, должна быть написана на Java или использовать существующую библиотеку Java.Я бы не стал предлагать кому-либо писать базу данных, например, на JS.Для реальных веб-приложений / SOA-сервисов основной причиной замедления является не необработанная скорость вычислений, а неэффективный код, особенно доступ к базе данных.Майна помогает с этим, делая такие вещи, как:

внутреннее кэширование скомпилированных JS-скриптов
Внутреннее использование кэшированных подготовленных инструкций для транзакций базы данных
Кэширование фрагментов запросов и выходных данных
Объединение в пул подключений к базе данных
Автоматическая поддержка хэша ETag
Инструменты профилирования
Отложенная загрузка метаданных

насколько хорошо мы можем внедрять и поддерживать транзакции с БД?можем ли мы сделать это на стороне сервера JS ..?

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

Если вы имеете в виду "какую поддержку базы данных имеет серверный JS?", то ответ зависит от платформы.Платформа Myna предоставляет следующие функции базы данных:

Веб-приложение администрирования, в котором вы можете определить "источники данных", то есть информацию о подключении к базе данных.Затем вы можете запросить эти источники данных по имени.Myna включает драйверы JDBC для H2, MySQL, Microsoft SQL Server и Postgresql, но можно использовать любой источник данных JDBC или ODBC
Майна.База данных и Майна.Стол обеспечьте доступ к metdata, не зависящий от базы данных, а также создание и модификацию таблиц.
У Майны Запрос объект поддерживает maxRows, подкачку, параметры SQL, пользовательские обработчики строк, запрос запроса, кэширование и многое другое
У Майны Менеджер данных объект поддерживает создание объекта ORM во время выполнения

возможно ли разработать RESTful и SOAP сервисы на стороне сервера JS ..??

Поддержка REST и SOAP является специфичными функциями платформы.У Майны Веб-сервис объект поддерживает следующие протоколы:

МЫЛО
XML-RPC
JSON-RPC-ФАЙЛ
Внешний Прямой
JSON-MYNA (простой протокол, который использует сообщения обычной формы и возвращает JSON.Простой в использовании из браузера)

Myna также понимает методы запроса PUT и DELETE и предоставляет доступ к содержимому тела запроса как в текстовой, так и в двоичной форме, так что можно обрабатывать эти методы RESTful специфичным для приложения способом.

Отладка

Традиционная отладка точки останова - это настоящая проблема на стороне сервера.Хотя Rhino поддерживает перехватчики отладчика, их использование из веб-приложения без состояния было бы довольно сложным.Лично я даже не использую отладчики точек останова, даже когда они доступны (напримерподжигатель).Вместо этого я предпочитаю вести журнал.

В Майне,

 Myna.log(type,label,detail)

создаст поток с низким приоритетом для записи HTML-сообщения журнала в базу данных ведения журнала Myna.Затем эти журналы можно просмотреть через администратора Myna.Журналы также записывают временные метки и истекшие миллисекунды для целей профилирования.Myna.dump(obj) также может быть использован для представления HTML-табличного представления любого объекта.Myna также регистрирует все необработанные исключения с трассировками стека, контекстом исходного кода и деталями запроса.Между dump(), log() и обработчиком ошибок по умолчанию у меня не возникает особых трудностей с отладкой Myna-кода

Другие советы

Используя серверный JS, можем ли мы реализовать все веб-приложение без использования каких-либо серверных языков (таких как C #, Java и т.д.).

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

Действительно ли это лучший подход??

Я не думаю, что JavaScript (как язык) действительно является лучшим или худшим вариантом, чем традиционные серверные языки.У него есть преимущества (наряду с другими динамическими языками, такими как Ruby и Python), такие как гибкость, быстрое прототипирование (без каламбура), податливость и т.д.С другой стороны, у него нет библиотечной поддержки, которая есть у Java и C #, или статической типизации (я не буду вдаваться в дискуссию о том, что здесь лучше;Мне нравится и то, и другое по разным причинам).

Если вы хотите получить лучшее из того и другого, вы можете использовать JavaScript в качестве языка сценариев, встроенного в ваше приложение.Rhino для Java и JScript.NET упрощает манипулирование "родными" объектами в JavaScript.Вы могли бы, например, написать свои доменные классы на Java или C # и скриптировать их с помощью JavaScript, где вам нужна большая гибкость.Однако, если вы достаточно хорошо разбираетесь в JavaScript, писать на одном языке может быть проще.

Я никогда не писал "настоящее" серверное приложение с использованием JavaScript, поэтому я не могу судить о том, лучше оно или хуже .NET (я также никогда не использовал JScript.NET).Я поиграл с несколькими фреймворками для развлечения, и в настоящее время я переписываю свой личный сайт, используя Helma NG.До сих пор это был хороший опыт (намного лучше, чем PHP, который мне никогда по-настоящему не нравился).

каковы преимущества и недостатки?

Преимущества:

Для программирования на стороне сервера и клиента необходим только один язык.
Возможность для общего кода, для таких вещей, как проверка формы.Jaxer позволяет запускать скрипты на клиенте, сервере или на обоих.
Вы можете программировать на JavaScript (при условии, что вам нравится этот язык).

Недостатки:

Многие фреймворки являются экспериментальными / не очень зрелыми.
Вы должны программировать на JavaScript (при условии, что вам не нравится этот язык).

как это хорошо работает с точки зрения производительности?

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

существует ли какая-либо реализация в реальном времени (общедоступные веб-сайты) только с использованием JS на стороне сервера (никаких других языков)?

Я не знаю ни одного крупного веб-сайта, использующего JavaScript, но некоторые из них могут быть.

какие альтернативы доступны поверх Aptana jaxer (с открытым исходным кодом)??

В Википедии есть большой список опций, но в нем не так уж много полезной информации.Существует множество вариантов с широким диапазоном зрелости и размера.

Вот некоторые из них, с которыми я знаком (в разной степени):

Хельма - Фреймворк на базе Rhino (Java) с активной записью.
Хелма НГ - Helma следующего поколения (экспериментальная версия, находится в активной разработке).
Фобос - Имеет хорошую поддержку в Сетевые приложения.
v8cgi - Маленький и простой, использует движок Google V8, вероятно, еще не готовый к производству.
Джаксер - Работает на Spidermonkey с реализацией DOM, поэтому вы можете управлять страницей с помощью фреймворков, таких как jQuery или Prototype.Имеет хорошую поддержку IDE в Aptana Studio.

Фреймворки на основе Rhino позволяют вам использовать классы Java, поэтому у вас есть полная поддержка JDBC.Я не пользовался библиотеками баз данных Jaxer, поэтому ничего не знаю о его возможностях.

возможно ли разработать RESTful и SOAP сервисы на стороне сервера JS ..??

RESTful API не должен быть какой-либо проблемой.Я не знаю о какой-либо конкретной поддержке SOAP, но она должна быть возможно.

В качестве предисловия скажу, что я использую SSJS на своей повседневной работе.Мы запускаем достаточно большой (с точки зрения сложности, а также просмотров страниц) веб-сайт на SpiderMonkey.Я добавлю к превосходному ответу Мэтью то, в чем у меня есть опыт.

Действительно ли это лучший подход, чем использование серверных языков (предположим, c #)

"Лучше" действительно зависит от того, что вы хотите с этим делать.Сам JavaScript обладает некоторыми замечательными функциями, а также довольно ужасными.Если вы серьезно относитесь к разработке JS (клиента или сервера), я не могу достаточно настоятельно рекомендовать вам посмотреть презентацию Дугласа Крокфорда, Javascript:Хорошие Части если вы еще этого не сделали.Он проделал фантастическую работу, разбираясь во всем этом, и вдобавок он отличный оратор.

Самое большое, чего, на мой взгляд, сейчас не хватает миру SSJS, - это зрелости.Я не знаком с C #, но в JavaScript нет зрелой стандартной библиотеки и нет зрелых средств распространения пакетов.Для меня это большая часть головоломки.

Тем не менее, не спускайте глаз с Общие JS Группа.Они работают над тем, чтобы дать точное определение этим вещам.Кроме того, в документации Jaxer Api перечислены встроенные модули, которые включены в эту платформу.

как это хорошо работает с точки зрения производительности?

JavaScript сам по себе не является ни медленным языком, ни особенно быстрым.Как отметил Мэтью, он должен быть сопоставим с любым другим языком сценариев, который вы бы использовали.Война между производителями браузеров за то, кто сможет создать самый быстрый браузер, пойдет на пользу и пользователям SSJS.

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

Похоже, что у Jaxer есть API баз данных MySQL и SQLite.Как упоминал Мэтью, если вы используете Rhino, вы можете использовать JDBC api.

Редактировать:Добавленные ссылки

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow