В конце 2016 или начале 2017 года я наткнулся на это сообщение в блоге . Это было в тот момент, когда я начал подумывать о создании OSBO , и я знал, что для этого придется окончательно покинуть мою крепость только для Java/бэкэнда, которую я с радостью занимал на протяжении всей своей карьеры, и хотя бы немного переместиться на “вражеские территории”. Этот пост в блоге был забавным, но в то же время в некотором роде ошеломляющим. Это подтвердило все мои опасения по поводу того, как это будет выглядеть – выполнять какую-либо внешнюю работу. Это звучало просто безумно.
Теперь, 2,5 года спустя и много-много строк кода Vue спустя, я хочу сделать внешний мир немного менее пугающим для таких людей, как я (тогда). Компетентные/старшие разработчики Java, которые по той или иной причине (выбор или обстоятельства) не получили большого опыта выполнения (большой) фронтальной работы и не совсем уверены, с чего начать.
Когда вы останавливаетесь и задумываетесь на мгновение, мир Java – это также намного больше, чем просто Java, когда речь заходит о чем-то большем, чем HelloWorld. Раньше я был наставником нескольких младших разработчиков, и недавно мне стало немного жаль крутой кривой обучения, с которой им приходится сталкиваться. Если вы присоединитесь к современному проекту в наши дни, с первого дня вы, вероятно, столкнетесь со следующими именами (в произвольном порядке): Maven/Gradle; Spring, Spring JDBC, Spring MVC, Spring Boot, Spring Cloud, Spring … ; Hibernate; Ломбок, Гуава, Apache Commons; Джексон, JSON, Jaxb; Искра; Верблюд; JMS; Tomcat, Jetty, Netty; Эврика, Hystrix, Лента; JUnit, Mockito, AssertJ, Огурец; Slf4j, Логбэк , Log4j; Докер Не говоря уже : традиционные базы данных + SQL; MongoDB; Elasticsearch; Кассандра; Neo4j; Couchbase; Кафка; Ehcache, … А также : AWS, Облачная платформа Google, Azure – все с соответствующими сотнями продуктов. И это всего лишь материал с моей головы, верхушка айсберга. Есть еще так много всего.
Большинство из нас на самом деле не задумываются об этом, потому что мы уже знакомы с этим стеком. Мы добавляем инструменты и фреймворки по мере необходимости, учимся чему-то новому и двигаемся дальше. Именно когда вы смотрите на все это в одном месте, с точки зрения новичка, вы осознаете количество задействованных движущихся частей.
И с этим небольшим обходом я прихожу к признанию: честно говоря, я не знаю, почему я думал, что мир JavaScript будет другим:)
К счастью, многие вещи концептуально довольно легко соотносятся с тем, с чем мы уже знакомы, а остальное имеет логический смысл. Наш стек на данный момент состоит из Vue/Next/Vuetify, и поэтому я буду исходить из этой точки зрения. Так что без лишних слов:
- Vue – отображение в мир Java не всегда будет очевидным, и я думаю, что Vue против React против Angular – одна из тех вещей, которые не поддаются строгому переводу. Возможно, самым близким будет Java против Kotlin против Clojure против Scala против … – у вас все еще есть базовое ядро (JVM + байт-код), так же как в веб-фреймворках у вас есть браузеры, HTTP, HTML, CSS, JavaScript/машинопись в основе того, что в конечном итоге запускается. Зачем вам нужен Vue вместо простого HTML/CSS/простого Javascript/других более простых библиотек Javascript? Для меня это такой же вопрос, как когда люди спрашивают: “Зачем мне нужно портфолио Spring”. Технически вам это не нужно, но если вы его не используете (или используете только простую платформу внедрения зависимостей, такую как Guice), в любом более сложном проекте вы, скорее всего, в конечном итоге напишете свою собственную версию различных библиотек Spring с множеством ошибок и множеством потерянного времени. Что мне действительно нравится в Vue, и я не знаю, возможно, это похоже на React, так это реактивность. То есть вы как бы сообщаете Vue, что этот бит пользовательского интерфейса зависит от этой конкретной переменной (вы привязываете это к этому биту данных), и затем вы можете просто изменить данные, и компоненты пользовательского интерфейса автоматически обновятся – без фанковых прослушивателей, обратных вызовов или любых других шаблонов. Это делает создание прекрасного, интерактивного чрезвычайно простым.
- NodeJS – подумайте: Кот/Пристань и тому подобное. Точно так же, как они вам не нужны для каждого отдельного приложения Java, как только вы попадете в какие-либо более сложные/динамичные проекты, вы, скорее всего, будете их использовать.
Далее – это похоже на швейцарский армейский нож мира Vue. Это то, что такое Spring Boot для Java. Самоуверенные рамки, и вам лучше придерживаться условностей – но когда вы это делаете, это может сэкономить так много времени. Он объединяет ряд других полезных функций, от Vue, маршрутизатора Vue до webpack и множества других вещей, и просто работает. Я люблю это. Все следующее предоставляется бесплатно (в противном случае вам придется заставить эти вещи хорошо сочетаться).
- Проверьте – библиотеку компонентов для проектирования материалов. Сам Vue в основном касается “языка” для описания вашего приложения. Подумайте о циклах, условных обозначениях и структуре. Проверка – это то, что предоставляет вам готовые красиво оформленные кнопки, таблицы, итераторы, вкладки и многие другие строительные блоки, чтобы ваша страница выглядела красиво. Вы можете использовать Vue с чистым HTML/CSS, или многими другими библиотеками компонентов, или несколькими простыми слоями CSS выше – все зависит от личного вкуса. Мы нашли Verify чрезвычайно удобным для начинающих, так что, если вы не ниндзя CSS, вы не ошибетесь, начав здесь.
- VueX – библиотека управления состоянием, что-то вроде глобально доступного кэша в памяти для приложений Vue. Вероятно, вам это понадобится практически для любого приложения, более сложного, чем статическая страница с очень небольшим количеством данных.
- VueRouter – немного похоже на маршруты Spring MVC/контроллеров – в основном указывает, какая часть вашего кода отвечает за ту или иную часть вашего приложения
- SSR против клиентского режима против статически отображаемого контента – это действительно заслуживает отдельного поста, чтобы вдаваться в мельчайшие подробности, но сейчас нужно понять одну вещь. Далее дается три варианта запуска Vue:
- статически визуализированный сайт , то есть вы пишете свой код в Nuxt + Vue, а затем создаете красивую статическую страницу, т.е. нет Node.js , вы просто обслуживаете простой HTML/CSS/Javascript, даже из чего-то вроде S3. Подумайте, статический HTML-код на вашем жестком диске.
- полный режим SPA (одностраничное приложение) , то есть ваше приложение доставляется в браузер в виде практически пустой оболочки, а браузер выполняет Javascript для динамического создания HTML/DOM
- универсальный режим – первое попадание на вашу страницу будет выполнено на Node.js сервер (это имя: SSR, рендеринг на стороне сервера), а затем последующие страницы/маршруты в рамках сеанса этого клиента (если быть точным: пока кто-то не закроет/не откроет вкладку или не нажмет кнопку обновить) будут обрабатываться браузером
Преимущество сгенерированного статического сайта довольно очевидно – это гораздо проще обслуживать. Однако вы не сможете использовать его для приложений с высокой динамикой/данными. Если вы не можете использовать это, в чем преимущество универсального режима/SSR по сравнению с SPA? Короче говоря: SEO. В наши дни поисковые боты гораздо лучше работают с Javascript, чем раньше. Если у вас есть страница с небольшим количеством JSon, вы, вероятно, все равно получите индекс страницы в полном порядке. К сожалению, по нашему опыту, с чем-то более сложным, когда вы управляете своей страницей с помощью довольно большого количества вызовов данных, боты недостаточно долго ждут/обрабатывают все, чтобы правильно ее проиндексировать. Next делает невероятно простым использование SSR, и когда мы поняли, что нам нужен SSR, это был момент, когда мы начали использовать Nxt, так как без него мы были в Мире Боли.
- Аксиос – Аксиос =~ Опорная плита пружины. Удобная библиотека для совершения HTTP-вызовов. Хорошо интегрирован в Next, так что вы можете получить к нему доступ в любом месте, где вам это нужно, с очень небольшой конфигурацией.
- PWA (Прогрессивное веб-приложение) – по данным Google, Прогрессивное веб-приложение (PWA) – это веб-приложение, которое использует современные веб-возможности для предоставления пользователям возможности, подобной приложению. Далее идет модуль, который упрощает создание PWA. (Мы здесь только в начале пути но я могу написать об этом подробнее позже)
- нпм/пряжа + веб-пакет – Я объединяю это в одну точку, хотя это независимые технологии, потому что для меня все это вписывается в “как мне управлять своими зависимостями и создавать вещи”. То есть эквивалент Maven/Gradle. Центром здесь является package.json (магистраль: build.gradle/pom.xml ). Часть webpack – это не то, о чем вам нужно много думать, когда вы используете Next, поэтому мы этого не делаем, но вы можете немного настроить ее, когда это необходимо.
- Вавилон – вроде как связано с вышесказанным. были бы вы счастливы застрять на Java 1.4 или 5.0 и не иметь возможности использовать все то, что появилось в Java 6, 7, 8 … ? (риторический вопрос) Неудивительно, что люди, занимающиеся JavaScript, тоже не хотят зацикливаться на каком-то старом синтаксисе JavaScript. Но в отличие от мира Java, у вас очень мало контроля над тем, в какой среде (браузере) будет выполняться ваш код. Таким образом, в некотором смысле Babel похож на умный компилятор Java, который преобразует ваш совершенно новый код во что-то, что старая JVM… Я имею в виду старый браузер… все еще могу понять. Аккуратный. О, и что самое лучшее? Если вы используете Next, все волшебство происходит без того, чтобы вы даже думали об этом. Кстати, вы заметили, что я продолжаю использовать здесь “JavaScript” – справедливости ради, я, вероятно, должен сказать JS, ECMAScript, машинопись … – но это просто запутало бы ситуацию на данном этапе, поэтому давайте придерживаться JS как мысленного ярлыка, зная, что это не совсем так.
- Eslint + Prettifier – что-то вроде Findbugs, PMD и проверки стиля кода в мире Java. На самом деле мы их не включили, так как в конфигурации по умолчанию они были очень шумными, и у меня не было времени на их точную настройку – но это кое-что в моем (бесконечном) списке ДЕЛ.
- Цедра и кипарис – тестирование, тестирование, тестирование. Jest похож на JUnit, Cypress, который мы считаем полезным для высокоуровневого/функционального тестирования. Существует множество вариантов, и они, казалось, больше всего подходили нам.
И, честно говоря, это все! Это все, что вам нужно знать, чтобы начать свое путешествие с Vue/Vuetify/Nuxt. Да, конечно, есть намного больше, особенно когда вы начинаете немного больше заглядывать под капот или у вас есть необычные требования, но вполне возможно стать продуктивным, просто будучи смутно знакомым с вышесказанным. Это все, что вам нужно для создания приложения, а не просто супер простого Hello World!
Я часто получаю этот вопрос от своих друзей-разработчиков, так что с таким же успехом могу задать его здесь, один раз. Angular было легко – я абсолютно ненавижу тенденцию Google просто отказываться от проектов, и я убежден, что они сделают это снова, поэтому я даже не стал углубляться в это дальше. Честно говоря, я ничего не имею против React как такового – может быть, за исключением того, что он сделан злой злой компанией, которую я предпочитаю держать на расстоянии вытянутой руки. Но в остальном я уверен, что это блестящая технология. Так почему бы и нет?
Наш проект создан двумя людьми, мной и совершенно новым разработчиком, человеком, который в начале проекта мог бы претендовать на такой же опыт, как создание HTML-сайта в Dreamweaver. Сначала я заглянул в React, но все это отношение “только для Javascript” немного напугало меня. Даже для меня создание простого приложения, немного выходящего за рамки “Привет, мир”, не было 5-минутной работой, я не понимал, что происходит. Тот факт, что в Vue есть эта аккуратная концепция объединения HTML (структура) + CSS (стиль) + Javascript (действия) в компоненты, казался намного более понятным для новичка, и для меня это имеет огромный смысл. Существует также большой выбор действительно базовых материалов о HTML и CSS. Вы можете постепенно узнавать больше. Реагировать? Это просто казалось слишком крутым поворотом для начала.
Забавный факт : когда мы только начинали, потому что я был таким “хардкорным Java”, мы даже не использовали Next. Мы не использовали Node.js . Мы начали с того, что все было объединено в одно приложение, весеннюю загрузку с небольшим количеством FreeMarker, посыпанного plainview. Времена библиотек Javascript, обслуживаемых с веб-сайтов. Затем добавьте маршрутизатор Vue и VueX вручную. Это были веселые времена, я многое узнал о стеке таким образом – но это не обязательно тот способ, который я бы рекомендовал, если вы цените свое время 😉 Я думаю, что документы React сейчас могут быть немного лучше, но тогда это действительно подталкивало вас к полному стеку, и я просто не был готов к этому.
Итак, мы здесь. Я ни разу не пожалел об этом решении. Да, наличие навыков реагирования, вероятно, было бы немного более практичным с точки зрения “большего количества рабочих мест”, но в остальном мы очень довольны тем, как работает Vue.
Окружающая среда
До сих пор есть одна серьезная “ошибка”, которая действительно беспокоит меня в комбо Next/Vue, и это то, на чем вы, как разработчик бэкэнда, скорее всего, споткнетесь. Концепция “сборка-один раз-развертывание-несколько-раз”. На данный момент это действительно сложно сделать, и для этого требуется множество взломов, а не аккуратное стандартное решение. В вашем обычном приложении Java (не слишком сумасшедшем с sth, таким как сервер конфигурации Spring Cloud) у вас часто будет внешняя конфигурация в виде файлов свойств/yml и/или передачи переменных среды. Именно последнее, скорее всего, доставит вам бесконечное количество огорчений, потому что переменные среды в определенных частях Nuxt запекаются во время сборки . Позвольте мне повторить это. Далее/Сборка Webpack принимает ваши переменные среды во время сборки и превращает их в сгенерированные ресурсы. Они не берутся из среды во время выполнения.
Что еще больше сбивает с толку, так это то, что это не на 100% относится ко всем вашим приложениям/вариантам использования. Существует плагин для Nuxt, который позволяет вам читать и использовать переменные среды выполнения. Хорошее эмпирическое правило таково: если вы используете что-то в своем собственном коде, в своих компонентах – вам будет хорошо использовать переменные среды выполнения $env. Однако, и именно здесь все становится неприятно, если вы используете плагин или модуль 3-го участника Next (например, для Google analytics), и он настроен в nuxt.config.js – ты чучело. В настоящее время не существует элегантного способа использовать переменные среды для этой цели. Это очень сбивает с толку, так как nuxt.config.js запускается дважды – во время сборки, а затем при запуске вашего (встроенного) сервера. Так что, если у вас есть что-то вроде:
console.log("Full environment we're running in: " + JSON.stringify(process.env));
в начале вашего nuxt.config.js , тогда может показаться, что переменная среды установлена правильно. За исключением того, что к моменту запуска этого кода переменная в вашей конфигурации уже была жестко задана значением, которое присутствовало во время сборки. Это еще более (!) сбивает с толку, потому что, если вы работаете в режиме разработки (тот, который вы обычно используете во время тестирования на локальном хосте), все будет работать, потому что сборка и запуск фактически являются одним и тем же процессом, поэтому установка переменной среды для этого процесса будет работать просто отлично.
Фу. Это делает работу в Docker/cloud нетривиальной и фактически заставляет вас перестраивать (по крайней мере, часть) приложения при развертывании (или использовать один из многих возможных взломов, о которых я могу рассказать в будущем посте). Я действительно надеюсь, что следующая команда в какой-то момент найдет более аккуратное решение, так как на данный момент мне очень плохо.
Реактивность
Когда вы начнете использовать Vue, может потребоваться немного времени, чтобы понять, как именно работает магия реактивность Vue. Раньше у нас были случаи, когда мы пытались использовать динамическое значение, и оно не обновляло представление так, как мы ожидали. С нами этого больше не случается, поэтому я думаю, что теперь мы интуитивно поняли, как работает реактивность, но в прошлом это не всегда было очевидно. Если люди приведут какие-либо примеры того, что реактивность не работает, я думаю, что мог бы попытаться понять, почему, и, возможно, разбить ее на более интуитивные правила/способ взглянуть на нее.
Технически, здесь не так много кода, который можно было бы показать. У гайки есть отличный генератор для каркасного проекта, все, что вам нужно сделать (после установки пряжи и node.js ), выполняется:
yarn create nuxt-app plain-nuxt-app
Он задаст вам пару вопросов о том, что вы хотите включить в свой проект. Пример с вариантами, эквивалентными тому, что у нас есть в нашем проекте, можно найти в примеры/простое следующее приложение Конфигурация линтинга, включенная по умолчанию, очень строгая, поэтому вы можете пропустить ее, если вы только начинаете – в противном случае вы можете получить некоторые пугающе выглядящие запутанные ошибки и предупреждения.
И это все на сегодня, ребята. Если какой-либо из вышеперечисленных пунктов или тем особенно интересен, пожалуйста, прокомментируйте/запросите дополнительную информацию ниже!
Оригинал: “https://dev.to/lilianaziolek/a-super-quick-guide-to-vuejs-ecosystem-from-senior-java-dev-point-of-view-1kmo”