Зміни в CleverStyle Framework 5

Деякий час тому вийшов перший реліз гілки 5.x, а потім кілька менших патч-версій, так що знову є чого розповісти.

Попередні зміни: частина 1, частина 2, частина 3, частина 4.

Коментарі під попередньою статтею і в чатиках були дуже корисними, окреме спасибі fesor, який хоч і не згоден, але надає конструктивну критику, яка має позитивні наслідки.

Безліч змін зробили систему швидше, легше і зручніше ніж коли-небудь до цього. У статті коротко про основні зміни, їх причини і наслідки.

Прощай jQuery
У версіях 4.x jQuery спочатку була оголошена застарілою, пізніше в 5.x вона була повністю випиляна з фреймворка.

Безліч рутинних операцій з використанням Polymer стають декларативними і тягнути jQuery заради невеликої кількості методів не хотілося.

Ще jQuery активно використовувалася для XHR запитів, але з широкою підтримкою XHR2 зникла необхідність писати декілька реалізацій, і була написана функція cs.api(), що:

  • забезпечує 95% потреб з набагато більш зручним синтаксисом
  • підтримує відправку форм і файлів
  • інтерфейс базується на ES2015 Promise
  • підтримує обробку помилок з висновком користувачеві красивих спливаючих повідомлень
Деякі модулі використовували jQuery плагіни, вони тепер використовують NPM версію jQuery.

Так само один з jQuery плагіни що використовувався в ядрі був отрефакторен без використання jQuery, патч прийнятий upstream, так що фреймворк включає чистий оригінальну версію: github.com/voidberg/html5sortable/pull/204

Більше немає плагінів і шаблонів блоків
Раніше окремо були модулі і плагіни. Плагіни були схожі на модулі, але без власних сторінок, админок, налаштувань, API та іншого.

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

Так само
components/blocks
та
components/modules
згодом перенеслися в
blocks
та
modules
за аналогією з
themes
.

Шаблони блоків були досить кривий штукою спочатку і за фактом були дуже прив'язані до конкретного проекту. Якщо додати до цього неможливість встановлення блоків з пакетів — користь і зовсім зводилася до нуля.
Тому шаблони блоків теж були випиляні, тепер блоки самі турбуються про власному зовнішньому вигляді.

Консистентним інтерфейсів
Разом з чищенням другорядних фіч було проведено багато роботи по консистентности внутрішнього API фреймворка.

Наприклад,
cs\CRUD
при роботі з різними движками БД тепер призводить числові типи до одного виду (MySQL навіть для числових стовпчиків повертав рядка, а SQLite повертав числа).

Ще один приклад — видалення підтримки
cs\DB::instance()->$db_id
та
cs\DB::instance()->$db_id()
замість
cs\DB::instance()->db($db_id)
та
cs\DB::instance()->db_prime($db_id)
. Коли-то давно це використовувалося, але це не дуже зручно і ускладнює виведення типів для IDE.

Безліч подібних дрібниць було виправлено і приведені до загального виду.

Тестування
Тестування в останніх версіях було приділено набагато більше часу ніж розробці нових фіч, також було додано обчислення покриття коду фреймворку тестами.

В результаті загальне покриття фреймворку тестами 66%+ на момент написання статті, покриття системних класів 96%+ (папка
modules
практично повністю складається з контролерів, тому пріоритет нижче):





Так само облік покриття коду дозволив знайти ділянки, які раніше не перевірялися, а так само ряд дрібних помилок, які було б складно знайти іншим способом.

Фронтенд ще легше, функція відключення підтримки веб-компонентів
Оскільки не всі ще перейнялися веб-компонентами, може здатися занадто дорогим вантажити Polymer, полифиллы і HTML імпорти якщо вони не будуть використовуватися. Саме для цих випадків в останньому релізі підтримка веб-компонентів стала отключаемой для просунутих користувачів в адмінці.

Друге важливе вдосконалення — перехід на асинхронні інтерфейси роботи з перекладами фронтенде.

Раніше було так:

cs.Language.system_profile_hello('Username')
// або
cs.Language('system_profile_').hello('Username')

Тепер же потрібно почекати:

cs.Language.ready().then(function (L) {
L. system_profile_hello('Username');
});
// або
cs.Language('system_profile_').ready().then(function (L) {
L. hello('Username');
});

Насправді під капотом до 6.x воно все ще синхронно, але в підсумку переклади будуть завантажуватися тільки коли потрібні.

Всі ці зміни дозволять зменшити обсяг обов'язково завантажуваного JS код з 312 Кіб до менше ніж 30 Кіб (це все без урахування gzip), а обсяг HTML импортов з 107 Кіб до 0 Кіб (0 файлів).

По суті, буде завантажуватися Alameda (RequireJS) і декілька допоміжних системних функцій/об'єктів.

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

Особливо корисним є оптимізація API запитів. Істотними (відносно) накладними витратами мала робота з перекладами, великий JSON обіймав час на парсинг, так і пам'ять. Тепер же під час API запиту, не працює з многоязычностью, переклади взагалі не будуть завантажені в пам'ять.

Для порівняння з конкурентами був зроблений форк популярного бенчмарка з купою різних фреймворків, так що результати можете відтворити самі:

Прихований текст
В текстовому вигляді:


|framework |requests per second|relative|peak memory|relative|
|-------------------|------------------:|-------:|----------:|-------:|
|silex-1.3 | 3,029.75| 8.8| 0.59| 1.0|
|symfony-2.7 | 1,423.83| 4.2| 1.41| 2.4|
|symfony-3.0 | 995.79| 2.9| 1.64| 2.8|
|laravel-5.2 | 342.99| 1.0| 1.98| 3.4|
|zf-2.5 | 671.20| 2.0| 1.36| 2.3|
|cleverstyle-5.15 | 1,939.17| 5.7| 0.66| 1.1|


Так само зросла пікова продуктивність під вбудованим Http-сервером разом з відмінною масштабованість (HHVM, 16 процесів, Core i7-4900MQ):
Прихований текст

nazar-pc@nazar-pc /w/t/www> ab -c500 -n100000 -k http://test.com:9990/api/System/blank
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking test.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software: nginx/1.10.1
Server Hostname: test.com
Server Port: 9990

Document Path: /api/System/blank
Document Length: 4 bytes

Concurrency Level: 500
Time taken for tests: 9.375 seconds
Complete requests: 100000
Failed requests: 0
Keep-Alive requests: 0
Total transferred: 24400000 bytes
HTML transferred: 400000 bytes
Requests per second: 10666.64 [#/sec] (mean)
Time per request: 46.875 [ms] (mean)
Time per request: 0.094 [ms] (mean, across all concurrent requests)
Transfer rate: 2541.66 [Kbytes/sec] received

Connection Times (ms)
min mean[±sd] median max
Connect: 0 8 69.2 1 1013
Processing: 0 39 30.9 31 272
Waiting: 0 37 30.5 29 272
Total: 0 47 75.3 35 1199

Percentage of the requests served within a certain time (ms)
50% 35
66% 48
75% 57
80% 63
90% 83
95% 104
98% 137
99% 166
100% 1199 (longest request)

А в однопоточному режимі запити відпрацьовують починаючи з 0.6 мс (0.0006 секунд), що дуже гідний результат, хоча і хотілося б забратися під 0.5 мілісекунди.

Наостанок
Як завжди, буду вдячний за конструктивні коментарі.
Репозиторій на GitHub: github.com/nazar-pc/CleverStyle-Framework
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.