Мултиплатформени приложения

Не за пръв път ми се случва да правя архитектура на уеб приложение, което ще бъде мултиплатформено, аджеба няма да се ограничаваме само с PHP или Джава, но може би за пръв път се задълбочавам толкова много в това си начинание. Малко предистория – за нашия опен сорс стартъп, едно от няколкото приложения, които решихме да направим е тип GTD, което е практически почти клонинг на изестните такива (tadalist, mojonote), но поправя някой тяхни дразнещи недостатъци. За повечето от вас, които не знаят аз съм голям почитател на тодо списъците. Правя си постоянно. Правя ги в промишлени количества. И както сами се досещате използването на хартиен носител за такова начинание води до много неудобства. Естествено сметнах, че е безумие да се налага да си нося десетките списъци постоянно с мен за да правя справки. Именно поради тази причина започвах да използвам различни уеб приложения. Повечето от тях са много готини, но все намирах недостатък. И така се роди идеята за проекта.

Архитектурна идея

Архитектурата на приложението е изключително проста. Колко от вас знаят какво е Thin Server Architecture? Вероятно много малка част, което надявам се ще се промени съвсем скоро. Накратко – идеята е следната: имате бекенд, който е писан на без значение какъв сървърен език, може да е PHP, може да е Ruby, Python – без значение. Той се занимава основно с бизнес логиката на приложението и не се съсредоточава ни най-малко върху презентационната част. Звучи нетипично нали, ползваш MVC фреймуърк, но почти не му ползваш V-то Може и да ви прозвучи налудничево, но в този начин на работа може да постигнете перфектното разделение и да се съсредоточите над важните неща, точно където трябва да го направите. Не казвам, че MVC не е правилния избор. Казвам, че в зависимост от нуждите, се използват различни подходи. Вземете например GMail. Вземете сега Ruby on Rails като стандартен инструмент. Замислете се… как би изглеждал кода, който ще напишете? Най-вероятно, ако имате достатъчно опит, си представят това, което по принцип наричате кошмар. Нормално. Стандартните инструменти, които използваме на ежедневен принцип не винаги са най-добрите. Отделете 40 минути и изгледайте видеото. Наистина ще чуете някой полезни идеи.

Ядрото – RESTful

В тази секция надали ще кажа нещо кой знае колко ново. REST не е от вчера (бел. HTTP). Фреймуърци като CakePHP и Ruby on Rails позволяват много бързо и безпроблемно да създадете ядрото на приложението ви. Също така правят процеса на работа доста лесен. В нашия случай, т.нар ядро не съдържа кой знае колко код. Лесен е за тестване, не се занимава капка с типични неща от рода на кеширане, което го прави още по изчистен.

Потребителска част – фронтенд

Стигаме до по-интересната част. Тъй като приложението е замислено да бъде доста „като фейсбук“ както се изразяват често нашите клиенти, се налага използването на голяма доза javascript, който прави сумати ajax повиквания. Щеше да е убийствено ако го бяхме мешели PHP код с HTML с javascript, но не го направихме. За целта използвахме JavaScriptMVC. За какво става на въпрос.. Ако тръгна да обяснявам на дълго и на широко няма надали ще се намери някой който ще прочете статията, включително и аз. Но все пак накратко. Замисляли ли сте се, колко по-удобно би ви било, ако до като пишехте PHP кода на view-тата ви знаехте дали точно в този момент потребителя е експанднал навигацията или не. Е, ако използвате JavaScript за визуализация няма да срещнете такъв проблем

Освен JS фронтенда, се породи и идея да направим малки десктоп приложения, които да бъдат като бонус за хората, които са свикнали да работят с десктоп софтуер. Платформите са Windows, Linux, Mac OSX, но да не забравяме и мобилните версии за iPhone, Android. Защо не и нещо за Windows Mobile? Е, ако използваме стандартния начин на проектиране, щеше да се налага вече или да имплементираме апи или да пренаписваме. Но благодарение на избрания метод, не се наложи да барнем нито един ред от бекенда на приложението. Досещате се колко часа работа се спестиха. Плюс това цялата сигурност, цялата валидация се намира на едно централизирано място. JS фронтенда работи с нея, десктоп приложенията също. Няма нужда да имплементираме едни и същи неща навсякъде. Гъвкавостта на ядрото ни позволи да използваме Java, C#, Objective C и ще ни позволи да имплементираме идиотщини от рода на Flex, без да се налага да променяме капка код на бекенда и без да имплементираме всичко на ново. Яко а? Якото тепърва предстои

API

В 2011 година за радост не звучи толкова странно да си имаш собствено API. Всъщност мен ако питате е напълно задължително. Няма да говоря за преимуществата на API-тата. Много точен и ясен пример е Twitter, мисля че няма човек, който да не знае каква огромна крачка направиха напред след като си отвориха API-то. В нашия слуачай, както сами се досетихте, не се наложи да променяме нищо за да имаме напълно работещо, unit тествано api.

Заключения

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

P.S. Очаквайте гореспоменатото приложение + неговия по-голям брат, който е на друга тематика, но все така с отворен код, за който споменах в един по-стар пост съвсем скоро