Я думаю, что мы как разработчики избалованы. Хотя у нас так много вариантов, так много фреймворков и языков программирования, мы легко попадаем в ситуацию, когда нас не устраивает ни один из наших вариантов (мы даже можем начать ненавидеть некоторые из них 😤). Но было бы хорошо напомнить себе, что довольно часто заказчик не заботится о стеке технологий, а просто хочет получить работающее решение. И это глубокое понимание должно помочь нам быстрее принять решение, поставить MVP и двигаться дальше по жизни. 😀

Я вкратце поделюсь своим опытом решения такой дилеммы, которая возникла у меня во время бэкэнд-разработки. Итак, задача заключалась в следующем:

Javascript (NodeJs - Express) против Java (Play Framework).

Краткое описание Play и Express

Play Framework упрощает создание веб-приложений на Java и Scala. Play основан на легкой, удобной для веб-архитектуры архитектуре без сохранения состояния.
Express - это минимальная и гибкая платформа веб-приложений Node.js, которая предоставляет надежный набор функций для веб-приложений и мобильных приложений.

Поскольку я вырос в корпоративной среде, где Java присутствует повсюду (от производства до внутренних инструментов), а основной акцент на javascript заключается в манипулировании DOM каким-то плохо выглядящим веб-интерфейсом администратора, я чувствовал себя более уверенно с Java. Это полноценный язык общего назначения, и нет ничего, что нельзя было бы построить с помощью Java. Кроме того, зрелая и богатая экосистема библиотек побудила меня попробовать первую платформу Play Framework.

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

1. Настройка

Хотя Play Framework - это первоклассный фреймворк на основе Scala, мне пришлось приложить некоторые усилия (больше, чем хотелось бы) для настройки среды разработки. Моим первым препятствием было настроить Eclipse для распознавания проекта Play. Мне пришлось использовать плагин, ориентированный на конкретную версию среды выполнения Eclipse и Scala, и мне было сложно все это настроить (устранение ошибок IDE). Я только что получил отзыв о том, что IntelliJ Community хорошо работает с платформой Play, так что это может быть лучшим выходом. Мощь полнофункциональной IDE (интеллектуальное автозаполнение, инструменты тестирования, зрелые плагины) является сильным преимуществом.

Настроить платформу Express было очень просто и приятно. Вы только создаете файл server.js и package.json, запускаете npm, выполняете исполняемый файл node и у вас есть работающий сервер. А легкий редактор кода Visual Studio дает вам больше, чем нужно для разработки. Но все же вам нужно знать наизусть некоторые javascript api.

2. Организация и архитектура

Когда я создавал проект Play, я был в восторге от подхода к архитектуре конфигурации. Контроллеры, модели, файл маршрутов, конфигурация, библиотеки и почти все находится в нужном месте, и я могу легко изучить другие проекты Play и найти то, что можно использовать повторно. Это большое преимущество. Я вижу, что разработчики Play позаимствовали много умных вещей из других подобных фреймворков: Django, RoR, ASP.NET…

В Express вы можете делать все, что душе угодно, создавать спагетти-код и беспорядочную организацию файлов, импортировать что угодно из любого места, изменять любой объект; а что лучше - все еще как-то работает; пока этого не произойдет. 😟 Но у этого есть и другие недостатки - обнаруживаемость кода и потенциальные ошибки, вызванные невежеством или ленью разработчика.

3. Отладка

IMHO Java имеет лучшие возможности трассировки стека и отладки. Период. Java вам ничего не прощает и заставляет определять все до мелочей. И это помогает вам в долгосрочной перспективе (но делает вас несчастным в текущий момент 😖). Его журналы и трассировки стека раскрывают всю информацию, необходимую для отслеживания причины ошибки.

Javascript может пропускать строки кода, в которых есть опечатки. Что еще я должен сказать ?! В javascript нормально использовать динамические типы, которые разрешаются во время выполнения, и именно здесь начинается самое интересное, если есть некоторые ошибки. Вы не представляете, что к чему. А в консоли вы часто получаете что-то вроде: Исключение необработанного обещания. Вот и все. А затем идите и вводите повсюду операторы журнала и молитесь, чтобы вам удалось воспроизвести что-то подобное. Я знаю, что должен быть какой-то лучший способ отладки javascript, но Java дает вам гораздо больше из коробки.

4. Код

В сообществе веб-разработчиков существует огромная шумиха вокруг функционального подхода, который постепенно поощряется (принудительно), поэтому ваш код Java иногда выглядит так:

public CompletionStage<Result> show(Long id) {
    return CompletableFuture
            .supplyAsync(() ->provisioningService.getAgencyUser(id))
            .thenApply(agencyUser -> ok(Json.toJson(agencyUser)));
}

Что бы ни представляли и ни поставляли CompletionStage, CompletableFuture, мне это не нравилось. Java - объектно-ориентированный язык, и такое происхождение кажется мне странным и чуждым. У неопытных разработчиков может сразу закружиться голова и они потеряют уверенность в своих скромных знаниях Java. Обработка данных JSON (отображение, фильтрация) также может иметь накладные расходы на код. Функциональный подход пытается помочь, но сначала мы должны усвоить такую ​​парадигму и синтаксис в Java.

В NodeJs все, что касается асинхронного кода, обещаний и JSON, выглядит естественно (в то время как это одна из основных целей этого языка). Но загвоздка в том, что всегда есть несколько способов что-то сделать (различные стандарты ECMA, дюжина вспомогательных библиотек - jquery, bluebird, lodash). Когда вы гуглите некоторые решения, вы обнаруживаете разные стили циклов for, обещаний и обработки исключений. И если (когда) вы их копируете и вставляете, ваш код выглядит намного сложнее, чем он есть на самом деле. Эта свобода хороша и плоха одновременно, и разработчик должен взять на себя ответственность больше заботиться о стиле кодирования.

Заключение

Я бы сказал, что Express хорош для быстрой проверки концептуальных решений, а Play - для более серьезных вещей, требующих более длительного времени, большей безопасности и стабильности. Оба хороши и забавны в использовании, и я думаю, что в зависимости от конкретной ситуации я мог бы использовать тот или иной. Так что я бы сказал, что оба фреймворка победили в этом испытании 🏆

На этом пока все. Если я осознаю интерес к этой теме, в следующий раз я продолжу свой опыт, касающийся тестирования, хостинга, безопасности…

Прокомментируйте и аплодируйте, если вам это интересно. Спасибо.