Це гарна ідея зробити користувальницький інтерфейс 100% у Javascript та надавати дані через API?

Моя основна робота щодня - це створення програм HTML. З цим я маю на увазі внутрішньо використовувані програми типу CRUD з безліччю редагованих переглядів сітки, текстових полів, спасних місць і т. Д. Ми зараз використовуємо веб-форми ASP.NET, які справді виконують роботу, але продуктивність в основному похмура, і досить часто ви доведеться стрибати через обручі, щоб отримати те, що потрібно. Обручі, які вішають на стелю і встановлюють полум’я.

Тож мені цікаво, чи, можливо, було б гарною ідеєю перемістити весь інтерфейс користувача на сторону JavaScript. Розробіть потужний набір елементів багаторазового керування, які спеціально підібрані до наших потреб, та обмінюйтесь лише даними з сервером. Так, мені подобається парадигма "control" (він же "віджет"), вона цілком підходить для таких програм. Таким чином, на стороні сервера у нас все ще буде основний макет, подібний до нашої поточної розмітки ASPX, але потім він буде надісланий клієнту лише один раз, і частина Javascript подбає про всі наступні оновлення інтерфейсу користувача.

Проблема в тому, що я ніколи цього не робив, і я ніколи не бачив, щоб хтось це робив, тому не знаю, які б проблеми були. Зокрема, мене хвилює:

• Продуктивність досі. Бенчмаркінг показує, що в даний час основна затримка знаходиться на стороні клієнта, коли браузер намагається відновити більшу частину сторінки після оновлення AJAX. Розроблена розмітка веб-форм ASP.NET надає нового значення слову "web", а багаті елементи управління Devexpress додають власний шар складності Javascript. Але чи було б швидше перерахувати всі необхідні зміни на стороні Javascript, а потім оновити лише те, що потрібно оновити? Зауважте, що я говорю про форми, які мають декілька редакторів сітки для редагування, безліч текстових скриньок, безліч спаднень, у яких є півмільйона фільтруваних елементів тощо.
• Легкість розвитку . Зараз буде набагато більше Javascript, і він, ймовірно, змішається з розміткою HTML сторінки. Той чи якийсь новий двигун огляду мав би бути виготовлений. Intellisense для Javascript також набагато гірший, ніж для коду C #, і через динамічний характер Javascript не можна очікувати, що він стане набагато кращим. Практика кодування може трохи покращити її, але не набагато. Крім того, більшість наших розробників в першу чергу є розробниками C #, тому будуть деякі криві навчання та початкові помилки.
• Безпека . Багато перевірок безпеки доведеться зробити двічі (на стороні сервера та на користувальницькому інтерфейсі), і на стороні сервера для обробки даних доведеться включити набагато більше їх. В даний час, якщо ви встановили текстове поле лише для читання на стороні сервера, ви можете залежати від його значення, що не змінюється через клієнтський перехід. Рамка вже має достатній код для забезпечення (за допомогою шифрування viewstate). З підходом лише до даних стає важче, тому що вам потрібно все вручну перевірити. З іншого боку, можливо, в місцях безпеки буде простіше помітити, тому що у вас будуть лише дані, про які потрібно турбуватися.

Загалом, чи вирішить це наші проблеми, чи погіршить їх? Хто-небудь намагався цього зробити, і які були результати? Чи є там якісь рамки, які допомагають у подібних починаннях (jQuery та моральні еквіваленти вбік)?

Linkedin робить це для свого мобільного сайту (див. Http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile, частина 4), і, мабуть, це було дуже корисно для них з боку точки зору продуктивності.

Однак я б радив вам не робити те саме з різних причин.

Перше - це ремонтопридатність: C # / ASP.net, завдяки серверній базі, не залежить від клієнта, тоді як Javascript не є (навіть із такою рамкою, як jQuery, ви не збираєтеся отримувати 100% сумісність між браузерами. , а не в майбутньому). Я б сказав, що також простіше перевірити функціональність програми зі статичним типом, ніж динамічного, і це обов'язково потрібно врахувати, якщо ви створюєте масштабні сайти.

Друга полягає в тому, що вам буде важко знайти інших людей, здатних (і готових) створити додаток із чистим JavaScript, який має складність, необхідну для запуску всього веб-сайту (порівняно з відносною легкістю пошуку. Програмісти NET). Це може не турбувати вас безпосередньо, але, безумовно, є над чим подумати з довгострокової точки зору.

Третє питання - сумісність з клієнтами; якщо ви створюєте загальнодоступні веб-сайти, то пам’ятайте, що в розумній частині мережі все ще не ввімкнено JS (з різних причин), тому вам потрібно бути абсолютно впевненим, що ви не збираєтесь виключати велику частину вашої бази даних, перейшовши на веб-сайт, керований JS.

Що стосується ваших проблемних проблем:

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

• Простота розробки насправді також не викликає занепокоєння, на мою думку, для розробки JS є дуже хороші інструменти, не просто вставте себе у VisualStudio, тому що ви звикли до цього! (спробуйте, наприклад, JetBrains WebStorm).

• Працездатність двигунів перегляду JS у більшості випадків абсолютно чудова (знову ж таки, на моєму досвіді), я їх активно використовую щодня. Я б запропонував уникнути більш важких рамок, таких як knockout.js тощо, і натомість скористайтеся чимось на зразок мікро шаблону Джона Резіга. Таким чином, ви можете підключити підтримуючий код таким чином, щоб ви були впевнені, що вони швидкі та надійні.

Що б я зробив, якби ти був, - це справді вивчити причини цього перемикача; Цілком може бути, що ви просто не використовуєте .NET ефективно та потребуєте вдосконалення своєї гри, WebForms - це не особливо повільний фреймворк, який не виходить з коробки, тому, можливо, деякі сторонні бібліотеки, якими ви користуєтеся сповільнюють показ.

Спробуйте зробити профіль продуктивності програми, використовуючи інструмент для перевірки навантаження та профілювання, і подивіться, де стоять ваші вузькі місця, перш ніж витратити велику кількість часу та зусиль на більш радикальне рішення, ви, ймовірно, здивуєтеся тому, що знайдете як винуватець вашої повільності!

Використовуйте ExtJS, якщо хочете піти цим шляхом, не винаходити колесо. Але будьте готові, це означає повну зміну парадигми. Ви навички HTML майже застаріли. AJAX скрізь, сервер здебільшого надає API AJAX. Ви будете писати набагато більше JavaScript, ніж будь-коли, тому краще переконайтеся, що ви справді підходите до JavaScript.

Команда, в якій я перебуваю, вирішила перейти до ExtJS наприкінці 2008 року. У нас в цей момент було додано PHP на 200 000 ліній, які страждали від проблем, пов'язаних з передовим процесом. Наша ситуація була набагато гіршою, ніж у вас, тому що у нас була керована система управління формою, яка була дуже поганою, і ми сильно використовували рамки для завантаження розділів сторінки (візуальна архітектура датована 2005 роком, і команда не знала Ajax, що рано). Нам все-таки довелося перефактурувати код, так що це полегшило рішення про сильну перестановку кодової бази в основному на стороні клієнта.

На сьогоднішній день додаток складає 300 000 рядків, з яких 60 000 рядків - код extjs, і приблизно 3/4 функціоналу перенесено на ExtJS. Код extjs - це додаток на одній сторінці, але він все ще містить деякі застарілі форми у iframes. Ми перенесли спочатку навігаційний контейнер, а потім перенесли різні ділянки з частинами. При такому підході нам вдалося перенести міграцію extjs у звичайний процес розробки функцій, не надто сповільнюючи нас.

• Продуктивність

  Код ExtJS виявився набагато швидшим, ніж застарілий код. Старий код був, звичайно, дуже поганим у виконанні, але навіть ми задоволені результатами. Код користувальницького інтерфейсу - це все статичний javascript, тому він кешується дуже добре (ми перебуваємо на етапах планування викидання його на CDN). Сервер не бере участь у передньому візуалізації, що зменшує навантаження там. Це також допомагає, що ExtJS забезпечує великий контроль за життєвим циклом інтерфейсу користувача (лінива візуалізація, легке завантаження невидимих ​​елементів інтерфейсу). Зазвичай після завантаження коду (архітектура завантаження на вимогу) більша частина часу завантаження екрана витрачається на виклик веб-служби для отримання даних. Сітка ExtJS дійсно швидка, особливо при використанні буферних подань для надання видимих ​​рядків у прокрутці.

• Простота розвитку

  Якщо чесно, це мішана сумка. ExtJS - це DSL, це не насправді веб-розробка в традиційному розумінні. Нашим розробникам знадобилося багато часу, щоб справді вивчити API рамки, і я не бачу, щоб ця крива була менш крутою для інших клієнтських рамок. Усі в команді повинні бути "старшими" розробниками javascript (як правило, книга Crockford не повинна зберігати секретів). Ми страждаємо від проблем завантаження з новими розробниками, тому що експертиза на стороні клієнта не настільки широко поширена, як ви могли б подумати, а досвід роботи extjs майже нульовий (у Бельгії, де ми знаходимося).

  З іншого боку, як тільки ви швидкісні, досвід розробників дуже приємний. ExtJS дуже потужний, тому, якщо ви знаходитесь в канаві, ви можете збити дивовижні екрани дуже швидко. По мірі IDE, ми використовуємо PHPStorm, який я визнав досить компетентним з кодом ExtJS.

• Безпека

  Безпека - одна з головних причин користувальницького інтерфейсу на стороні клієнта. Причина проста: зменшення поверхні атаки. API веб-служби, який використовується нашим кодом ExtJS, є набагато меншою поверхнею атаки, ніж рівень інтерфейсу на стороні сервера. ASVS OWASP вказує, що ви повинні перевірити весь вхід на сервері для правильності перед його використанням. В архітектурі веб-служб очевидно і просто, коли і як зробити перевірку вводу. Мені також простіше міркувати про безпеку в архітектурі інтерфейсу на стороні клієнта. Ми все ще боремося з проблемами XSS, тому що ви не позбавлені кодування до HTML, але в цілому ми набагато краще щодо безпеки, ніж ми були на старій базі коду. ExtJS полегшує перевірку полів форми на стороні сервера, тому нам не потрібно сильно писати код двічі.

Якщо ви можете дозволити собі не підтримувати безскриптних користувачів, а пошукові системи вас не стосуються, то так, це цілком життєздатний підхід. Ось короткий перелік плюсів і мінусів:

Плюси:

• все в одному місці (javascript)
• ви можете завантажувати дані з сервера, а не розмітку, що може зекономити велику пропускну здатність, якщо зробити все правильно
• легше отримати чуйний додаток (затримка в мережі все ще є, але початкова відповідь на введення користувача приходить швидше)
• веб-серверу не потрібно надавати HTML або розширювати шаблони (тобто зусилля з обробки переміщуються з сервера на клієнта)

Мінуси:

• все має бути у javascript (може бути, а може і не бути проблемою)
• критичну логіку потрібно дублювати на сервері
• стан потрібно підтримувати на клієнті та сервері та синхронізувати між обома
• безпеку може бути важче виправити (враховуючи, як чим-небудь у коді клієнта можуть управляти зловмисні користувачі)
• ви виставляєте значну частину своєї кодової бази (код, який працює на сервері, неможливо побачити ззовні)

Особисто я думаю, якщо ви йдете цим маршрутом, ASP.NET UpdatePanels - це не правильний шлях. Вони чудово підходять для часткового відключення існуючих веб-додатків, але вони все ще надсилають HTML через AJAX, і керування станом таким чином може бути досить волохатим. Вам краще пройти весь шлях, обслуговуючи лише статичний документ HTML, а потім скористатися бібліотекою шаблонів javascript, щоб зробити візуалізацію HTML; сервер взагалі не обслуговує жодного динамічного HTML, натомість клієнт здійснює виклики бізнес-логіки на сервері та отримує необроблені дані.

Так, можна, але ..

Вам потрібно переконатися, що у вас витончена «деградація», щоб критичні частини вашої програми все ще працювали без Javascript.

Ось так я будую більшість додатків у стилі "HIJAX".

Мій сайт ще знаходиться в зародковому стані, але 100% js ui для мене досі добре. Єдина логіка сервера, що існує на передньому кінці, - це відображення моделей та URL-адрес ajax. Сервер взагалі не має знань про інтерфейс, який мені дуже легко обслуговувати. Якщо ви зацікавлені, ви можете замовити мій сайт, написаний на ExtJS http://coffeedig.com/coffee/ . На моєму веб-сайті насправді немає проблем із безпекою, але клієнт допомагає звичайному користувачеві простим підтвердженням. Я знаю, що зловмисник може дійсно надіслати будь-який аякс на сервер, тому вся логіка "безпеки" виконується на сервері.

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