Init.js: Навіщо і як розробляти з Full-Stack JavaScript

1. Історія Отже, у вас і у вашого партнера з'явилася чудова бізнес-ідея. Вірно? Ви постійно додаєте...
2. Чому я вибрав JavaScript
3. JavaScript від початку до кінця: Node.js і MongoDB
4. Серверне компонентне подання з Express.js
5. односторінкові додатки
6. Клієнтський MV * з Backbone.js, Marionette.js, і Twitter Bootstrap
7. Кращі методики: Grunt.js, Mocha.js, Chai.js, RequireJS, і CoverJS
8. Використання гілок для перемикання можливостей
9. Почніть проект з Init і розгорніть на Heroku сьогодні

Історія

Отже, у вас і у вашого партнера з'явилася чудова бізнес-ідея. Вірно?

Ви постійно додаєте в розумі все нові і нові можливості.

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

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

І нарешті, в один прекрасний день ви вирішили: "Зробимо це!". І ось ви вже намагаєтеся розібратися як реалізувати бізнес-логіку свого застосування, ту кілер-фичу, яка буде рухати продукт вперед. У вас є ідея як це зробити, і ви знаєте, що здатні на це.

І ось ви говорите: "Готово! Працює! "У вас є успішний прототип! Залишилося тільки упакувати його в веб додаток.

"Окей, зробимо сайт," говорите ви.

А тільки потім ви розумієте, що для цього потрібно вибрати мову програмування; потрібно вибрати (сучасну) платформу; потрібно вибрати якісь (сучасні) фреймворки; потрібно налаштувати (і купити) сховище, бази даних і хостинг; потрібно забезпечити інтерфейс для адміністрування; потрібно забезпечити контроль доступу і систему управління контентом. Ви хочете бути бережливим (lean) і гнучким (agile). Ви хочете використовувати технології, які допоможуть вам бути успішним як в короткостроковій, так і в довгостроковій перспективі. А вибрати їх далеко не завжди так просто.

Перед вами десятки і десятки архітектурних рішень, які необхідно прийняти. І ви не хочете помилитися: потрібні технології, які дозволять вести швидку розробку, підтримують постійні ітерації, максимальну ефективність, швидкість, стійкість і багато іншого. Ви хочете бути бережливим (lean) і гнучким (agile). Ви хочете використовувати технології, які допоможуть вам бути успішним як в короткостроковій, так і в довгостроковій перспективі. А вибрати їх далеко не завжди так просто.

"Я перевантажений", говорите ви і відчуваєте себе перевантаженим. Енергія вже не та, що була на початку. Ви намагаєтеся зібратися з думками, але роботи занадто багато.

Прототип повільно блякне і вмирає.

Речення

Після того, як я закинув купу ідей по схожих причинах, я вирішив спроектувати рішення для цієї проблеми. Я назвав цей проект ' Init '(Або init.js).

Основна ідея - використовувати один проект для старту будь-якого проекту, дати можливість розробнику або технічного керівника прийняти всі основні рішення за раз і отримати відповідний початковий шаблон, заснований на них. Я знаю, багато хто скаже "Не можна застосувати одне рішення до всіх проблем" (haters gonna hate). І вони, можливо, мають рацію. Але ми можемо постаратися створити відповідне в цілому рішення, і, на мій погляд, Init з цим завданням впорався.

Щоб досягти цієї мети, необхідно взяти до уваги кілька важливих моментів. При розробці Init я зробив наголос на наступному:

• компоненти

  Компонентне подання - одна з ключових характеристик будь-якої системи, так як вона дозволяє повторно використовувати компоненти програмного забезпечення в кількох проектах, що є основною метою Init. Але компонентне подання містить в собі побічний ефект - заменяемость, яка стане нашим основним союзником в боротьбі з різними проблемами, вирішення яких "майже" однаково.

• простота розробки

  Якась проблема десь має рішення, найкраще реалізоване на Brainf * ck . буде практично неможливою для написання, не кажучи вже про читанні. Це буде коштувати вам часу і величезних зусиль. В цілому, ви повинні використовувати мови і платформи, які спрощують, а не ускладнюють розробку для вас (і тих, хто буде робити її пізніше).

• Спільнота

  Яку б платформу ви не вибрали, переконайтеся, що навколо неї існує велика спільнота. Таке, яке може допомогти вам з більшістю стандартних і нестандартних проблем. Пам'ятайте: jQuery, можливо, не сама швидка , чиста , І елегантна бібліотека, але вона - переможець, завдяки своєму спільноті .

Я покажу як приймав рішення при створенні Init, не забуваючи про ці цілі.

У серці Init - парадигма 'Full-stack JavaScript' '-' повний набір JavaScript '(деякі люди називають її або її частина 'MEAN Stack' ). Працюючи з таким набором, Init дозволяє використовувати лише одну мову для створення дивно гнучких і повнофункціональних оточень для розробки веб додатків. Коротше кажучи, Init дозволяє використовувати JavaScript не тільки для розробки клієнтських і серверних рішень, але і для складання, тестування, шаблонізаціі і так далі.

Але давайте зупинимося на мить і запитаємо себе: чи така хороша етo ідея - використовувати JavaScript?

Чому я вибрав JavaScript

Я працюю веб-розробником з 1998 року. В той час ми здебільшого використовували Perl для серверної розробки, але навіть тоді у нас був JavaScript для клієнтської частини. Технології веб-серверів дуже сильно змінилися з тих пір: ми пройшли через кілька хвиль мов і технологій, таких як PHP, AP, JSP, .NET, Ruby, Python. Розробники почали усвідомлювати, що використання двох різних мов в серверній і клієнтської частини ускладнює роботу. Спочатку спроби об'єднати дві частини під однією мовою вилилися в створення клієнтських компонентів на сервері і компіляцію їх в JavaScript. Результати не виправдали очікувань, і велика частина таких проектів провалилася (наприклад, ASP MVC, який замінив веб-форми ASP.NET , і GWT який, судячи з усього, в найближчому майбутньому буде замінений Polymer 'Ом). Але, по суті, це була чудова ідея: одна мова для клієнта і сервера, що дозволяє повторно використовувати компоненти і ресурси (це ключове слово: ресурси).

Відповідь була простою: перенести JavaScript на сервер.

Насправді JavaScript народився з серверної стороною в Netscape Enterprise Server, але мова просто-напросто не був готовий на той момент. Через роки спроб і невдач, з'явився, Node.js який не тільки переніс JavaScript на сервер, але також просунув ідею неблокуючим програмування , Назавжди змінивши те, як ми пишемо "fread" (I / O) (більше про це читайте тут ).

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

Але ці ідеї не були новими, чому ж вони стали так популярні з приходом Node.js? Просте неблокірующіх програмування досягається декількома способами. Мабуть, найпростіший це використовувати зворотні виклики (callbacks) і цикл подій - event loop . У більшості мов це непросте завдання: якщо зворотні виклики це досить поширена функція, то цикл подій - немає, і в якийсь момент ви опиняєтеся в сутичці з зовнішніми бібліотеками (наприклад: Python, з Tornado ). Але в JavaScript зворотні виклики це частина мови, як і цикл подій, і кожен програміст, який хоча б пробував JavaScript, знайомий з ними (або як мінімум використовував їх, навіть якщо не до кінця розумів що таке event loop ).

Раптово, будь стартап на Землі може повторно використовувати розробників (читай: ресурси) і на клієнтської і на стороні сервера, вирішуючи кадрову проблему , "Нам потрібен гуру Пітона".

Отже, тепер у нас є неймовірно швидка платформа (Спасибі неблокірующіх програмування) з мовою, який дуже легко використовувати (спасибі JavaScript). Але чи достатньо цього? Чи буде це працювати? Я впевнений що JavaScript займе важливе місце в майбутньому. Дозвольте пояснити чому:

• функціональне програмування

  JavaScript був першою мовою програмування, приніс парадигму функціонального програмування в маси (звичайно, першим був Lisp, але більшість програмістів жодного разу не створювали повністю завершений продукт на Lisp). Lisp і Self, основні мови, вплинули на JavaScript , Сповнені інноваційних ідей. Ці ідеї можуть звільнити наш розум для вивчення нових технік, шаблонів проектування і парадигм. Всі вони перейшли в JavaScript. Погляньте на монади , числа Черча , Або навіть (більш практичний приклад) функції колекцій Underscore.js які можуть вберегти вас від безлічі рядків зайвого коду.

• Динамічне програмування і прототипна спадкування

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

• JavaScript це інтернет

  JavaScript був спроектований для інтернету , Він тут з самого початку, і він не збирається нікуди йде . Всі спроби знищити його провалилися: подивіться, наприклад, на падіння Java аплетів , Заміну VBScript'а TypeScript'ом від Майкрософт (Який компілюється в JavaScript), смерть Flash від рук мобільного ринку і HTML5. Неможливо замінити JavaScript не руйнуючи мільйони веб сторінок, так що нашою метою повинно бути поліпшення мови. І ніхто для цього завдання не підходить краще, ніж Technical Committee 39 з ECMA.

  Так, альтернативи JavaScript'у народжуються кожен день, наприклад, CoffeeScript , TypeScript і мільйони мов, які компілюються в JavaScript . Ці альтернативи можуть бути корисними на етапах розробки ( завдяки source maps ), Але їм не вдасться замінити JavaScript в довгостроковій перспективі з двох причин: їх спільноти ніколи не стануть більше, і їх кращі можливості будуть реалізовані в ECMA Script (читай: JavaScript). JavaScript це не мова асемблера, це високорівнева мова програмування з вихідних кодом, який ви можете зрозуміти, так що ви повинні зрозуміти його.

завдяки проекту Esprima project ви можете створювати власні інструменти для роботи з вихідним кодом: код можна модифікувати, змінювати стиль, додавати компоненти, інструменти і будь-які інші речі, які можна собі уявити граючи з Абстрактним синтаксичним Деревом вашої програми як якби це було дерево DOM.

JavaScript від початку до кінця: Node.js і MongoDB

Отже, це були причини вибрати JavaScript. Тепер я спробую переконати вас використовувати Node.js і MongoDB.

• Node.js

  Node.js це платформа для створення швидких, масштабованих мережних додатків - приблизно так його описує офіційний сайт. Але Node.js це більше, ніж просто платформа. Це найкраще оточення для запуску JavaScript-додатків з доступом до пристроїв введення / виводу. Навіть якщо ви не плануєте писати основне серверний додаток на Node.js, ви можете використовувати інструменти, створені на основі Node.js, щоб поліпшити процес розробки. наприклад, Mocha.js для юніт тестів, Grunt.js для автоматичного складання, або навіть Brackets для повнотекстового редагування коду.

  Так що якщо ви плануєте писати програми для сервера або клієнта на JavaScript, ви повинні познайомитися з Node.js, тому що він буде вам необхідний кожен день. Існують деякі цікаві альтернативи , Але ні в одній з них немає і 10% співтовариства Node.js.

• MongoDB

  MongoDB це документо-орієнтована NoSQL база даних, яка використовує JavaScript в якості мови запитів, дозволяючи замкнути цикл роботи з платформою JavaScript. Але це не головна причина використовувати MongoDB.

  MongoDB не вимагає опису схем таблиць завдяки чому ви можете з легкістю зберігати об'єкти, і таким чином швидше пристосовуватися до змін у вимогах. До того ж, MongoDB добре масштабується і використовує map-reduce , Що робить її хорошим вибором для додатків з великими даними. MongoDB настільки гнучка, що може використовуватися в якості документної бази даних без схеми, реляційного сховища (але без транзакцій ), Або навіть сховища ключ-значення для кешування.

Серверне компонентне подання з Express.js

Серверне компонентне подання - складне завдання. але з Express.js (і Connect.js ) З'явилася ідея "проміжного шару" (middleware). На мою думку, проміжний шар це найкраще визначення компонентів сервера. Якщо хочете порівняти його з відомим шаблоном проектування, то це щось на зразок конвеєрів і фільтрів.

Основна ідея в тому, що ваш компонент - це частина конвеєра. Конвеєр обробляє запит (input) і генерує відповідь (output), але ваш компонент не відповідальний за весь відповідь. Навпаки, він лише модифікує те, що необхідно, а потім передає завдання наступного елементу конвеєра. Коли останній елемент конвеєра закінчує обробку, відповідь надсилається назад клієнтові.

Ми називаємо ці "елементи конвеєра" "проміжним шаром". Очевидно, що можна створити два типи проміжних шарів:

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

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

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

односторінкові додатки

Проект Init фокусується на створенні односторінкових додатків - 'single page applications' (SPAs) . У більшості веб-розробників не раз була спокуса спробувати себе в створенні односторінкових додатків. Я зробив кілька (в основному для себе), і можу з упевненістю сказати, що за ними майбутнє веб-додатків. Ви коли-небудь порівнювали SPA зі звичайним веб-додатком на мобільному з'єднанні? Різниця у відгуку складає десятки секунд.

Ви коли-небудь порівнювали SPA зі звичайним веб-додатком на мобільному з'єднанні? Різниця у відгуку складає десятки секунд.

Односторінкові додатки - це майбутнє інтернету, так що навіщо створювати свій продукт в застарілому форматі? Частий аргумент, який я чую - це труднощі з SEO. Але якщо ви реалізуєте все правильно, це не буде проблемою: сам Google пропонує дуже хорошу інструкцію як це зробити, та й тут є непогані коментарі.

Клієнтський MV * з Backbone.js, Marionette.js, і Twitter Bootstrap

Багато що було сказано про MVC * фреймворки для односторінкових додатків . Це складний вибір, але я б сказав, що три фаворита - це Backbone.js , Ember.js , і Angular.js .

Всі вони вважаються дуже хорошими. Але якою буде кращим для вас ?

На жаль, змушений зізнатися, що у мене дуже мало досвіду з Angular.js, так що я виключу його з цієї дискусії. Отже, Ember.js і Backbone.js представляють собою два різних шляхи для вирішення однієї проблеми.

Backbone.js мінімальний, простий і пропонує вам необхідний мінімальний набір для написання простого SPA. Ember.js ж - це повноцінний і професійний фреймворк для створення односторінкових додатків. У ньому більше можливостей, але і крива навченості крутіше.

Залежно від розміру програми, рішення може бути таким же простим, як аналіз відносини "використовуються функції / доступні функції". Воно дасть вам хорошу підказку.

У випадку з Init, я хотів покрити більшість сценаріїв, тому вибрав Backbone.js для простого створення SPA, з Backbone.Marionette.View для компонентізаціі. У такій схемі кожен компонент - це просте додаток, а кінцевий продукт може бути настільки комплексним наскільки я захочу.

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

Bootstrap був створений з використанням мови LESS Bootstrap - проект з відкритим вихідним кодом, так що його можна модифікувати якщо потрібно. У комплекті з ним купа елементів призначеного для користувача інтерфейсу з хорошою документацією на сайті Bootstrap . PК того ж є модель для модифікацій що дозволяє без праці створити власні елементи. Безсумнівно, це кращий вибір для нашої задачі.

Кращі методики: Grunt.js, Mocha.js, Chai.js, RequireJS, і CoverJS

Нарешті, ми можемо виділити кращі методики та з'ясувати, як Init може допомогти нам в їх реалізації і подальшої підтримки. Наше рішення засноване на декількох інструментах, кожен з яких в свою чергу заснований на Node.js.

• Mocha.js і Chai.js:

  Ці інструменти дають можливість управляти процесом розробки із застосуванням TDD або BDD , Надають інфраструктуру для організації юніт тестів і дозволяють автоматично запускати їх.

  існують тисячі фреймворків для юніт тестів на JavaScript. Чому варто використовувати Mocha.js? Коротка відповідь: він гнучкий і закінчений.

  Довгий відповідь: у нього є дві важливі особливості (інтерфейси, репортери), і в ньому немає бібліотеки тверджень (assertions) Дозвольте пояснити.

  • Інтерфейси: можливо, ви звикли до концепціям TDD на кшталт юніт тестів і колекцій сценаріїв (suite), можливо, ви віддаєте перевагу ідеї BDD зі специфікаціями поведінки "описами" і "це повинно". Mocha.js підтримує обидва підходи.

  • Репортери: запуск ЮНІТ тестів генерує Звіти про результати, и ви можете форматуваті ЦІ Звіти с помощью різніх репортерів. Наприклад, якщо вам потрібно подавати інформацію сервера безперервної інтеграції, то можна підібрати репортер спеціально для цього завдання.

  • Відсутність бібліотеки тверджень (assertion): Mocha.js був створений так, що з ним можна використовувати будь-яку бібліотеку тверджень, що покращує гнучкість. існує багато варіантів , Але тут варто розглянути Chai.js.

  Chai.js це гнучка бібліотека тверджень, яка дозволяє використовувати будь-який з трьох основних стилів:

  • Затвердження (assert): класичний стиль тверджень зі старої школи TDD, наприклад:

    assert.equal (variable, "value");

  • Очікування (expect): Стиль ланцюгових тверджень, найчастіше використовується в BDD. например:

    expect (variable) .to.equal ( "value");

  • Повинен (should): Також використовується в BDD, але я віддаю перевагу "очікування" тому що "повинен" звучить співзвучно з специфікацією поведінки 'він ( "повинен робити щось")'. например:

    variable.should.equal ( "value");

  Chai.js відмінно поєднується з Mocha.js. Використовуючи ці дві бібліотеки можна писати юніт тести в TDD, BDD або будь-якому іншому стилі, який можна собі уявити.

• Grunt.js:

  GGrunt.js дозволяє автоматизувати складання, починаючи з простого копіювання-вставки і склеювання файлів, до прекомпіляції шаблонів, компіляції метамовою для стилів (тобто, SASS і LESS), юніт тестування (з mocha.js), аналізу і мініфікація коду ( наприклад, з UglifyJS або Closure Compiler ). Ви можете додати власні автоматизовані завдання в Grunt, або знайти потрібне рішення серед сотень і сотень існуючих полігонів , (Знову ж таки, використання інструментів, за якими стоїть відмінне співтовариство, грає нам на руку). Grunt також може стежити за файлами і запускати дії при їх зміні.

• RequireJS:

  RequireJS може здатися просто черговим способом завантаження модулів поряд з AMD , Але я запевняю вас що RequireJS здатний на більше. Щоб зрозуміти чому, по-перше, потрібно згадати ідею області видимості модуля (наприклад, demo.views.hello), яка допомагає тримати глобальну область видимості чистої, приховуючи кожен модуль в своїй галузі. Проблема в тому, що ці модулі не можна використовувати повторно: якщо ви зміните namespace одного з примірників, це торкнеться всіх екземпляри. RequireJS, в свою чергу, дає можливість спочатку створювати модулі для повторного використання. (До того ж він допомагає використовувати впровадження залежності (Dependency Injection), щоб ваші модулі не зверталися до глобальних змінних .

• CoverJS:

  покриття коду - це міра оцінки тестування. З назви зрозуміло, що бібліотека дає інформацію про покриття коду вашої поточної колекцією тестів. CoverJS оцінює покриття коду тестами інструментації інструкцій (а не через рядки коду, як JSCoverage ) І генерацією інструментальної версії вашого коду. Він також може генерувати звіти для сервера безперервної інтеграції Server.

Використання гілок для перемикання можливостей

Я почав роботу над Init і мені потрібен був спосіб для включення і виключення різних можливостей, які можуть знадобитися в проекті. Я вибрав радикальний підхід: використання гілок git'а для реалізації цього завдання.

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

Поки така ідея злиття для додавання функціональності може бути використана для технологій-шаблонів (на кшталт Backbone, Node, Express). Але в майбутньому ви зможете перемикатися між бекенда (наприклад, з MongoDB на Postgres) і клієнтськими рішеннями.

Почніть проект з Init і розгорніть на Heroku сьогодні

Ще ніколи не було більш простого способу почати проект. Просто перейдіть в репозиторій GitHub , Виберіть гілку з останніми коммітов (зараз - usermanager, однак це може зміниться в майбутньому) і потім:

1. Створіть директорію для свого проекту (або використовуйте існуючу).

2. Створіть репозиторій за допомогою git init (або використовуйте існуючий репозиторій).

3. Додайте віддалений репозиторій init

   git remote add init git: //github.com/picanteverde/init.git

4. Отримайте потрібну гілку

   git pull init usermanager

5. Отримайте процес-файл для heroku

   git pull init heroku-webprocess

6. З встановленим Heroku Toolbelt створіть додаток Heroku

   heroku create

7. Надішліть вашу майстер гілку в Heroku

   git push heroku master

8. Відвідайте ваше вже працює додаток в Heroku!

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

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

Матеріал переведений Рахімом Давлеткаліевим, учасником Transbunko - торговельний майданчик для технічних перекладів.