Оцінка Ваадіна: Сильні та слабкі сторони

1. Події низького рівня
2. Компоненти та їх розподіл
3. Модель, керована подіями
4. Сильні сторони
5. Слабкі сторони
6. Немає фантастичних графічних інтерфейсів
7. SEO
8. Резюме - Мінуси

Vaadin - це зріла веб-основа для розробки багатих інтернет-додатків. Створення веб-графічних інтерфейсів з Ваадіном схоже на розробку настільного додатка, яке є чудовим, зручним і швидким. Однак є ситуації, коли Ваадін не підходить. У цій статті ми розглянемо архітектуру Ваадіна і вкажемо на його сильні та слабкі сторони. Давайте розпочнемо.

Vaadin дозволяє створювати Rich Internet Applications (RIA). RIA намагаються бути настільки ж чуйними та інтерактивними, як настільні програми (менше перезавантаження сторінок, обмін частинами сторінки за допомогою AJAX та DOM маніпуляції). Vaadin йде навіть на крок попереду цього, створюючи веб-додаток з однією сторінкою (SPA) (без перезавантаження сторінки взагалі).

Єдиною мовою програмування, яка вам потрібна, є Java. Немає необхідних веб-інтерфейсів, таких як JavaScript або HTML. Щоб отримати уявлення про те, як ви програмуєте графічний інтерфейс користувача в Vaadin, погляньте на приклад Addressbook на веб-сайті Vaadin.org:

Перш за все, давайте поглянемо на архітектуру Ваадіна. Це важливо для подальшої оцінки.

Події низького рівня

Важливим моментом є асинхронні повідомлення, які обмінюються між клієнтом і сервером на основі дій користувача. Ви можете побачити це в Застосування адресної книги . Давайте розглянемо, які повідомлення надсилаються на сервер, коли натискаю кнопку, щоб видалити вибраний контакт.

Події низького рівня асинхронно обмінюються між клієнтом і сервером

Клієнт не каже "видалити цей контакт" на сервер (семантична подія). Натомість він просто говорить: «натиснута кнопка 74» (подія низького рівня). Повідомлення містить лише низьку інформацію про взаємодію користувача. У цьому повідомленні немає логіки програми. Тільки сервер знає, що кнопка натискання означає семантично. Вся логіка програми розташована виключно на стороні сервера.

Компоненти та їх розподіл

Наступна графіка ілюструє компоненти Vaadin та їх розподіл:

Архітектура Ваадіна: Розподіл компонентів

Двигун на стороні клієнта працює у веб-переглядачі і написаний на JavaScript. Він передає користувальницький інтерфейс і отримує взаємодію з користувачем і надсилає їх як події на сервер. Браузер служить лише як так звана «платформа тонких клієнтів». Він має лише відображати інтерфейс користувача та передавати події на низькому рівні серверу. Не існує специфічного для програми з'єднання між клієнтом і сервером. Це є перевагою, оскільки логіка програми не розсіяна по клієнтам і серверам.

Server-Side Framework містить логіку UI та стан кожного клієнта. Тут виконується логіка програми. Кожен компонент на стороні сервера (наприклад, Button, TextField, Table) має клієнтську сторону, "віджет". Цей віджет представляє компонент на стороні клієнта.

Розробник повинен тільки реалізувати логіку UI і бекенда. Все перед цим шаром є прозорим для розробника. Він не повинен піклуватися про веб-технології (HTML, JavaScript) або клієнт-сервер-комунікації (HTTP, AJAX, JSON серіалізація, сесії). Він використовує тільки Java API компонентів.

Модель, керована подіями

Наступна графіка ілюструє обробку подій у Ваадіні.

Обробка подій у місті Vaadin

1. Користувач робить щось у інтерфейсі користувача, наприклад, натиснувши кнопку. Це викликає подію, яка споживається відповідним віджетом (кнопкою) на стороні клієнта.
2. Ця подія серіалізується до JSON і асинхронно надсилається сервлету Vaadin, запущеному на сервері. Сервлет отримує запит клієнта і посилає подію на відповідний компонент UI. Це можливо тому, що кожна подія (віджета) асоціюється з компонентом і доставляється слухачеві подій, визначеному в логіці UI.
3. Логіка інтерфейсу (реалізована розробником) обробляє подію і змінює компоненти інтерфейсу на стороні сервера (наприклад, вставляючи текст до текстового поля, вимикайте кнопку або фільтруйте таблицю).
4. Сервлет повідомляє про зміни в інтерфейсі браузера, посилаючи відповідь назад у веб-переглядач. Клієнтський движок у браузері отримує відповідь.
5. Двигун на стороні клієнта змінює сторінку в браузері, маніпулюючи DOM. Оновлений користувальницький інтерфейс подається користувачеві.

Сильні сторони

Мій досвід показує, що Vaadin дозволяє писати інтерактивні та чуйні веб-додатки з високим рівнем комфорту та швидкості розробки. Він поставляється з потужним, простим у використанні набір компонентів . Іншою практичною перевагою є підхід до програмування моноглотів і використання відомого імперативного стилю програмування GUI. Якщо ваша команда розробників вже знайома з Java і вже має досвід роботи з графічним інтерфейсом у Swing, SWT / JFace або JavaFX, вони стануть продуктивними відразу. Те ж поняття, однакова мова. Вони не змушені вивчати JavaScript, декілька бібліотек JavaScript (jQuery, jQuery UI, AngularJS і т.д.), веб-техніки (AJAX, сеанси, файли cookie, специфічні для браузера обробки), протоколи і формати (HTTP, WebSockets, JSON). Ваадін опікується цим. Однак корисно знати їх.

Основна інформація - Плюси:

• Швидкий розвиток
• Плоска крива навчання через програмування моноглотів (лише Java)
• Розробляти веб-додатки, як настільні програми.
  • Добре відома імперативна парадигма програмування інтерфейсу користувача
  • Веб-специфічні проблеми є прозорими для розробників. Вони не повинні їх вивчати.
• Комплексний і складний набір компонентів і механізм прив'язки даних.
• Дійсно хороша документація та активна спільнота

Слабкі сторони

Масштабованість

Одним з недоліків Ваадіна є його погана масштабованість. Для кращого розуміння я порівнюю архітектуру Vaadin з архітектурою тонкого сервера.

Серверні фреймворки презентації порівняно з архітектурою Thin Server

У архітектурі тонкого сервера логіка UI і стан знаходяться на клієнті. Ви використовуєте бібліотеки HTML і Java-Script, такі як AngularJS для програмування елементів інтерфейсу та логіки. Сервер зводиться до постачальника даних через веб-службу REST. Вам не потрібно багато запитів, тому що потрібно лише запитувати дані, а не логіку інтерфейсу користувача. Цей підхід досить добре масштабується, оскільки стан клієнтського інтерфейсу розташований на клієнті (зберігає пам'ять сервера), логіка UI працює на клієнті (зберігає використання процесора сервера), а виклики служби REST можуть бути легко кешовані та відправлені за допомогою балансувача навантаження. (Повідомлення REST є самоописувальними; для обробки на них немає необхідного стану на сервері). В цілому, ця архітектура може добре справлятися з великим трафіком.

Це неприпустимо для застосувань на основі Vaadin, що є рамкою презентації на сервері. Стан UI і логіка зберігаються на сервері, і для кожної взаємодії з користувачем, запит повинен бути відправлений на сервер, щоб клієнт знав, як він повинен реагувати. Це призводить до збільшення мережевого трафіку та зайнятості сервера. Більш того, для кожного клієнта необхідно утримувати стан UI. Якщо кількість клієнтів збільшилася, потрібно більше пам'яті сервера для утримання станів UI.

Тим не менш, я настійно рекомендую вам прочитати цей пост Чи масштабуються програми Vaadin? . У ньому говориться, що Vaadin може обробляти тисячі одночасних користувачів . Я хотів би підкреслити, що це величезна кількість і має бути достатньо для багатьох випадків використання. Для мене аргумент масштабованості використовується занадто часто і навіть у випадках, коли серверний підхід все ще здатний обробляти навантаження. Але якщо ви створюєте веб-сайти, що орієнтовані на громадськість, Ваадін не підходить, тому що він не може масштабувати, а також інші підходи - завдяки його архітектурі.

« Ваадін ніколи не був побудований для масових веб-сайтів, що стоять перед громадськістю . Якщо вам потрібна масштабованість на рівні facebook, Vaadin не є найкращим інструментом для цього. Але нічого менше, Ваадін явно працює і працює добре. ”Йенс Янссон, Ваадін. Джерело: Чи масштабуються програми Vaadin?

Немає фантастичних графічних інтерфейсів

Компанія Vaadin дуже швидко розробляє бізнес-додатки. "Бізнес-додатки" означає програми, що складаються переважно з форм і таблиць. Однак, якщо ви хочете складний і важкий інтерфейс користувача (наприклад, анімації і користувальницькі функції UI), Vaadin не підходить, тому що вам потрібен тонкий і прямий доступ до DOM , що не так просто з Vaadin. У цьому випадку розглянемо наймання ніндзя JavaScript і безпосередньо будуємо інтерфейс користувача з веб-інтерфейсними технологіями.

SEO

Оскільки Vaadin завантажує асинхронний вміст за допомогою JavaScript на одній URL-адресі, SEO є складним. Існує трюки та бібліотеки щоб зробити вміст доступним для сканерів. Але вони, безумовно, вимагають додаткових зусиль, і результат може бути не таким гнучким, як ви бажаєте. Якщо SEO є найвищим вимогою для Вас, Vaadin (або SPA в цілому) не є найкращим вибором.

Резюме - Мінуси

• Не добре масштабується в порівнянні з іншими архітектурними підходами. Підвищення навантаження на мережу і сервер (пам'ять, процесор).
• Непридатний для фантастичних графічних інтерфейсів.
• SEO

Висновок

Перш за все, мені подобається Ваадін і ідея, що стоїть за нею. Vaadin сприяє розробці Rich Internet Applications з високою продуктивністю і комфортом, використовуючи виключно Java. Щоб вирішити, чи підходить Vaadin для вашого проекту, потрібно врахувати загальні вимоги (очікуване навантаження, цільовий рейтинг пошукової системи, вимоги інтерфейсу користувача)

Якщо ви зіткнулися з низьким або середнім навантаженням (наприклад, для внутрішніх систем або внутрішніх програм для вибраної групи користувачів), Vaadin ідеально підходить. У цьому випадку ви можете скористатися прискореним розвитком, плоскою кривою навчання і високим комфортом. Якщо ваша команда вже знайома з Java та імперативним програмуванням на графічному інтерфейсі, перевага Vaadin ще більше.

Навпаки, якщо вам доводиться мати справу з величезною кількістю користувачів, рейтинг Google є важливим або у вас є надзвичайні вимоги до інтерфейсу користувача, то Ваадін менш доречний. Таким чином, я б не рекомендував будувати інтернет-магазин з Ваадіном.