Ако не сте чували, CodePile (www.codepile.net) е платформа за съвместно кодиране в реално време с много страхотни функции. Една от основните потребности винаги е била да се внедри синхронизиране на живо на всичко - от присъствието на потребителите до всички настройки и актуализации, без да е необходимо да опреснявате страницата. Има, разбира се, ниво на това, което вече е вградено във факта, че сайтът е приложение за една страница (създадено с AngularJS), но имах нужда и от решение за уеб сокети, за да синхронизирам всички промени в базата данни с всички свързани клиенти.

След известно проучване Firebase (firebase.google.com) беше очевидният избор. Използвайки 3-посочното обвързване на данни на AngularFire, което прави справянето с всички главоболия, свързани с настройването и управлението на уебсокет връзки, напълно прозрачно, успях да започна да внедрявам функции веднага, вместо да се тревожа за инфраструктура и конфигурация.

Освен това, въпреки че никога не бях работил със структура на NoSQL база данни, Firebase беше невероятно интуитивен и кривата на обучение беше бърза и безболезнена. Най-голямото отклонение на ума, идващо от SQL среда, беше умишленото де-нормализиране за лесна употреба и по-висока производителност. Например, трябваше да проследя потребителя, който е създал всеки кодов фрагмент (всеки „Pile“), и трябваше да покажа всички Piles, които влезлият в момента потребител е създал в своя профил. В SQL може да съм използвал индексирано поле „createdBy“ в таблицата Pile. Това ще ми даде достъп до създателя от Pile и мога да получа всички Piles за потребител със заявка като:

SELECT pileID FROM Pile WHERE createdBy = ‘[Current_User]’

При Firebase обаче подобна заявка е много скъпа. Следователно е много по-ефективно да се структурират данните, както следва:

 — Piles
 — — [PileID]
 — — — CreatedBy (UserID)
 — Users
 — — [UserID]
 — — — UserPiles
 — — — — [PileID]

Недостатъкът на тази структура е, че сега трябва да помним да управляваме Pile асоциациите на потребителя на две места. Въпреки това, след като свикнете с нея, не е трудно да видите предимствата на тази методология и да се адаптирате.

От скромното първо издание на доказателство за концепцията, уважаван мой приятел разработчик ми каза, че включването на достъп до необработен файл, подобно на GitHub, е необходима функция за CodePile, за да бъде жизнеспособно решение за хостване на код. Това ще му позволи да тества скриптове от терминала с помощта на команди като...

curl https://www.codepile.net/pile/xyz123.py | python

…или включете отдалечени CSS & Javascript ресурси в HTML файлове, хоствани и редактируеми на CodePile. Всичко това звучеше добре и добре, но тъй като първоначалната ми цел беше да изградя услугата изцяло на Firebase, изобщо нямаше управляван бекенд.

Друга бележка тук… CodePile използва оперативните функции за нишки и присъствие на Firepad, както и текстовия редактор Ace, допълвайки техническия стек, който захранва приложението. Едно нещо при използването на Firebase/Firepad за създаване на „документи“ е, че всъщност не съществува файл на нито един сървър. Всички актуализации на съдържанието се записват като поток от натискания на клавиши, които се превъртат бързо напред, за да се създаде текущото състояние на файла във всеки един момент. Това направи идеята за „суров“ достъп до файлове още по-трудна. Имах нужда от начин да създам „физически“ документ на сървъра, съдържащ текущото състояние на съдържанието на CodePile към момента, в който е поискано.

Въведете OpenShift и Node! Това беше първият ми опит да работя с Linux и беше по-малко болезнено, отколкото се страхувах. OpenShift (www.openshift.com) е страхотна услуга, предлагаща лесно зареждащи се безплатни Red Hat Enterprise Linux кутии. Моето приложение Node Express, хоствано на поддомейна raw.codepile.net, е доста просто, използвайки „безглавата“ Node библиотека на Firepad, за да изтегли текущото състояние на документа CodePile, който след това се записва във файл и се изпраща обратно чрез response.sendFile . Също така определям заглавката „text/plain“ Content-Type, за да позволя на браузъра да показва съдържанието по подразбиране или то да бъде включено като вграден ресурс в следващия ви проект.

Като цяло това работи много добре и сега имам минимален бекенд, върху който мога да създам други функции, които просто не работят в изпълнение само за интерфейс, като изпращане на имейли за добре дошли и уведомления. Този хибриден подход (Firebase + Node) ми дава възможността бързо да разработвам нови функции, като използвам всичко, което Firebase може да предложи, и го разширявам само там, където е необходим управляван бекенд. Не мога да бъда по-доволен от настройката!