×

Разделение мобильной разработки на Front-end и Back-end

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Всем привет!

Хотел бы с вами обсудить тему, которая уже давно витает в воздухе, но почему-то как-то в массах не особо обсуждается.

Было время, когда мобильные приложение были весьма тривиальными и в большинстве своем представляли из себя тонкий клиент, который подгружает некоторые данные с сервера и отображает пользователю в удобочитаемом виде. Когда я начинал свой путь в мобильной разработке, то большинство приложений, которыми я занимался, были именно такими. Поэтому моя работа в основном заключалась в верстке UI, а какая-то замысловатая внутрення логика, реализованная на стороне клиента была редкостью.

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

Но при этом нельзя сказать, что мобильная разработка полностью съехала во front-end, ведь кроме UI фреймворков добавилось много новых интересных возможностей, которые происходят «под капотом». И хотя с выходом новых версий мобильных SDK, разработка в какой-то степени упрощается, так как переносится на более высокий уровень абстракции, все равно появляется много различных нюансов и подводных камней, за которыми не так просто уследить.

И в результате получается что разработчик, который долгое время занимается в основном реализацией внутренностей приложения (клиент-серверное взаимодействие, локальное хранение данных, работа с геолокацией и т.д) упускает множество важных мелочей по разработке UI. К примеру, лично я за прошедший год сам столкнулся с такой ситуацией, а также слышал истории нескольких программистов, которые также столкнулись с такой проблемой. Более того, на сайтах по поиску работы стали появляться вакансии вида Senior iOS (Front-End) Developer, а это уже звоночек.

Вспомните как все начиналось в web-разработке, раньше ведь все были веб-мастерами, да веб-дизайнерами, а сейчас такие понятия вообще канули в лету.

К чему я все это ? Мне хотелось бы услышать ваши мнения, готов ли рынок к разделению мобильной разработки на front-end и back-end или же время еще не пришло ?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ну, (imho, ясен пень) основная причина разделения веб-разработки на FE/BE — это совсем разные технологии: языки, фреймворки, внутренняя логика. т.е. совмещать написание синхронного кода на Spring/J2EE и какой-нить событийно-ориентированный Backbone на JS — сложно. тем более, что интерфейс общения(HTTP протокол) достаточно просто и не так уж много подводных камней предлагает.

планируете ли вы в приложении писать UI и business-logic части на абсолютно разных языках/фреймворках/подходах(что оправдало бы затраты на согласование-общение)? есть ли стабильный канал для общения между этими частями(не добавится ли новых проблем с интеграцией?)?
если всё ок, то да, можно и разделить зоны отвественности.
как когда в большой системе два девелопера просто разные модули разрабатывают.

Врядли.
Времена нехилого урожая с оберток по JSON с сайтов проходят. Хотя не так чтобы уже прошли.
Эпл их, кстати, никогда особенно не любил и норовил прихлопнуть различные обертки на социалки еще года 2 назад, мотивируя недостаточностью функционала.
Свистелки в UI тоже притормозили. Т.к. народ наигрался. Выжило только самое функциональное типа сайдменю.
А игрушки-навигация-фотофильтры и пр. и так на 99% под клиента писались и там разделение по другим принципам, тут только легче становится по причине увеличения мощности проца и количества памяти год от года.
Да и вообще — фронтэнд, бекенд, термины из веб разработки. К «толстым» клиентам не сильно применимы.

Возможно для каких-то огромных проектов оно и будет иметь смысл. Но в глобальном плане рынок стал двигатся к смешиванию технологий. То есть кандидат должен уметь/знать больше одной технологии. Так что разделение конечно хорошо, но как по мне рынок стал двигатся уже в другом направлении.

готов ли рынок к разделению мобильной разработки на front-end и back-end или же время еще не пришло
в вакансиях различают? Тогда да.
готов ли рынок к разделению мобильной разработки на front-end и back-end?
С точки зрения архитектуры приложения — однозначно да.
С точки зрения разделения на Mobile frontend developer / backend developer — нет.
Мобильщик должен и «морду» уметь клепать, и бизнес-логику серьезную.

В чем собственно проблема? Неужели в том, что «серьезный» кодинг перекочевал на клиента? Это вызывает негативные чувства?
Имхо у Вас какое-то предубеждение. Раз пришел на клиентскую сторону, то обязан заниматься версткой? Никто не обязан это делать. Немного смазано сейчас требование front-end, но это пройдет. Что-то придумают. Всегда была и будет «верстка» и был и будет «кодинг». Потому что всегда найдется масса заказчиков, которых не устроит клонированная версия популярного UI фреймворка.
Короче.. Кодят люди на клиенте — пусть себе кодят. Кто работал со статикой (UI), то и будет этим заниматься. Кто — с динамикой (код), тот продолжит (на клиенте)

В общем то эволюционный процесс никто остановить не смог.

Фронтенд — да, выделяется, для mobile (tablet) девайсов он должен делаться во многом иначе, чем десктоп. Разница вызвана геометрией (разрешением) дисплея, плюс ротацией устройства в пространстве, ну и главное это сенсорный дисплей. WYSIWYG очень и очень. И наоборот — ты делаешь только то в том участке работы приложения, что там нудно делать. Ничего лишнего, никаких менюшек куда «когда то может быть» я кликну.

По бэкенду — приоритет в проектировании приложений и их взаимодействии идет на асинхронные сервисы, ибо доступность модильного устройства для серверной части непредсказуема. (тут сервисная часть это некие гарантировнно доступные сервера в датацентре), плюс глобальная локация мобильного девайса (сегодня я в Европе, завтра в Аргентине например). Если весь бэкенд (сервисы) работает в самом девайсе автономно, то тут все проще.

Рынок готов. Разработчики по мере приобритения опыта также оформят свою специализацию.

Классная заметка.

Я бы лучше разделил заказчиков (тех.директоров) по мобильным приложениям на таких которым:
а) важны бантики — красота приложения
б) нужно, чтобы работало

Первые могут 2 месяца «блукать» в рамках первых 5-ти экранов: логин — регистрация — забыл пароль, переделывая дизайн и правля его раз 5, а иногда и больше. Потом кончились деньги или просто выдохлись.

Вторые говорят, «я знаю, что это не сложно, работы на 3 дня», хотя реально работы недели на 2-3 если делать по людски.

Ни там ни там нет людской спецификации, где четко написано, что нужно получить в качестве конечного продукта.

На мой взгляд есть еще такие проблемы разработки для мобильных девайсов:
1. Мало кто кроме девелоперов понимает, что мобильные приложения это «данные в кармане, а не Интерент везде», другими словами заказчики и руководители проектов почему-то слепо уверены что доступ к сети будет у пользователей всегда.
2. «Владельцы продукта» (в терминах ПМ) — не читают гайдлайны, соответственно хотят то, что неправильно, в результате делают грубые ошибки и по стуку конкурентов их приложения банятся.
3. Как следствие п.2 в мобайл пришло много кроссплатформенных разработчиков, которые просто красиво обворачивают мобильный сайт обверткой и выдают за мобильное приложение, что в сознании больниства «биздесменов» только подтверждает п.1.
4. И как результат п 1, п.2. и п.3 Мобильные приложения мало кто воспринимает «в серйоз», чтобы на них можно было делать ставку как на частный случай решения задач. Например рекрутеры чаще на мобайл получают уведомления о новых сообщениях в линкедине, а отвечают на сообщения через вебинтерфейс, потому что им «не удобно, экран маленький».

что вы имели ввиду под пунктом 2 — «не читают гайдлайны»?

Є гайдлайни для мобильних додатків та пов"язані з ними. Їх не читають.

Наприклад для іОС є таке:
developer.apple.com/...​erview/design-principles

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

Стосовно прикладів в мобільній розробці — на жаль прямо зараз навести не можу. Те що актуальне — воно під НДА, що старе, то там могли накосячити нове.

А есть ли такие гайдлайны для мобильных игр?

У Самсунговського стора є гарний чеклист і для ігор в тому числі також.
Свого часу створював додаток для розміщення в Самсунг сторі, так вони надали достатньо детальний чеклист, який містив розділ і для ігор також.

Сейчас на рынке массово появляются планшеты на Intel Atom X5 (X4) которые работают на полноценной windows 10. Например наша компания устанавливает на планшет (!) базу данных Oracle XE + Apex и на такой платформе можно автоматизировать небольшое производственное предприятие или торговую точку. Понятно что класические мобильные задачи (сбор заказов, инвентаризации и т.д.) можно реализовать практически за день. Для связи с центральной БД в облаке используем DB link, что позволяет реализовать очень быстрый, а главное транзакционный обмен.
Я считаю что мобильные устройства перейдут в разряд «носимых серверов» и грань между мобильной и не мобильной разработкой исчезнет. Напротив будут новые направления например «мобильный DBA» :)

И как такое чудо синхронизировать с ЦБД и друг с другом?

Выше написано что через DBlink, например так
insert into empl as select * from empl@srv

И что такое есть «empl» в распределенной БД?
Судя по обсуждению.... в моем тлф. есть своя, локальная Table-"empl"
Есть еще куча customer со своими тлф и своими локальными Table-"empl"
Есть еще ЦБД со своим «самым главно-актуальным» Table-"empl"

И о чем говорит это ваше «insert into empl as select * from empl@srv» ?
(Синтаксис правда не совсем понятен что и куда мы вставляем)

Аааа! это типа у нас интернет всегда доступен? Ну тогда о чем речь?
Не похрен получаю я доступ к БД через локалку или через GPRS?
Это-ж канальный уровень, Application-Level, Data-Storage и прочему бизнес-процессу на это глубоко плевать каг-бе.

empl — таблица в телефоне,
empl@srv таблица на сервере
insert into empl as select * from empl@srv — означает скопировать все из таблицы empl на сервере в таблицу empl на телефоне. Интернет нужен только во время копирования, дальше приложение работает с локальной таблицей.

Также возможна обратная операция, перенести все данные из телефона на сервер
insert into empl@srv as select * from empl

Ситаксис стандартный DML.
(www.firststeps.ru/mfc/msdn/r.php?101)

Прикольно... те а давайте затрем все мои данные на тлф, данными с сервака?
Грубо говоря....
А если у меня есть очень специальные castomer-s кот. я не хочу затирать? и не хочу их светить на ЦБД?
А если ID ЦБД пересекаются с ID моих локальных customers?
А если 2 sales-manegers имеют 2х разных customers с одинаковыми Local-ID?
как они их будут заливать в ЦБД и как будут с нее обновляться?

Это типа кто первый успел, того и ID? а второй customer в пролете?

Судя по синтаксису..... ну да, какой-то модифицированный DML из стандарта SQL-92
Даж примитивный Firebird на такую инструкцию выругается Ворнингом «Менять ВСЕ? без Where.... Вы в своем уме?»

Я привел простейший пример для понимания процесса работы. Понятно что вреальном проекте логика намного сложнее, используются процедуры, функции и пакеты. Функционал обмена может быть любой (даже передача файлов).

Ок.
Ну в разрезе этой статьи тогда давайте фиксировать:
1. Связь с ЦБД есть всегда (для простоты)
2. На нижнем уровне имеем стандартную 3х-звенку: БД(как хранилище данных)-AplicationServer(стандартно Web-Server)-UI(стандартно Web-Brauser)
3. AplicationServer реализует некоторую бизнес логику (принимает запросы от UI, выгребает соотв. данные из БД, перелопачивает их в соотв. с бизнес-логикой и выплевывает в сторону UI)
4. Вопрос.... можно-ли и надо-ли резать классический UI на бизнес-модуль и чистый UI?.... Ну все зависит от задачи и сложности обработки того что приходит с ApplicationServer. Если с сервака приходит чистый Html.... ну замахаешся пыль глотать — выдергивать на клиенте отдельные куски, как-то их перелопачивать и в JavaScript тулить результат в уже готовую страницу.
Если результат приходит как XML или что-то подобное.... ну клиентская часть может сделать пост-обработку таких данных.... в зависимости от чего-то.... (почему эту пост обработку не смог сделать сервак? перед отправкой данных?)
--------------
Те. теоретически можем на mobile-device выделить 3Level:
1. Канальный — прием-отправка сырых данных
2. Бизнес-логика — обработка данных по заданным правилам (если mobile-device имеет какие-то сильно специфические х-ки)
3. Отображение результата в UI

В данном случае я так понимаю речь идет о том, что связь с ЦБД есть не всегда. Если подразумевается что связь есть всегда, то вообще ничего выдумывать не нужно, мобильное устройство используется как тонкий клиент.
А вот если связи нет, то одно и то-же приложение (один и тот-же код) может работать как на десктопе так и на мобильном устройстве с синхронизацией (когда будет связь) через dblink, master-master или master-slave это уже другой вопрос.
В любом случае если подразумевается автономная работа, будет бэк на устройстве и механизм синхронизации с ЦБД. Собственно так и работают наши смартфоны и планшеты с те-ми же контактами.

Забавно, несколько лет назад работал в подобном проекте для строительной отрасли. Backend на Java/MSSQL, и то же самое на Windows—планшете (+UI). То есть на клиенте крутилась реплика сервера и базы, между ними шла непрерывная синхронизация при наличии соединения, а в его отсутствии (на стройплощадке) была возможна полностью автономная работа. Так вот, та система писалась в ~2005 году, так что подход ни разу не новый. В мою бытность, та фирма как раз слезала с описанной архитектуры, и переходила на модный нативный iPad app.

И вот опять...

Новое, хорошо забытое старое :)
Сегодня планшеты на windows (Atom X5, 2Gb Ram, 32SSD, Windows 10) стоят порядка 100$, автономности хватает на полноценный день. В 2005 данные устройства работали по 3 часа и стоили по 1K$ и решения на нативные приложения под ios/android были более интересными для заказчика. Сегодня ситуация изменилась, если говорить про приложения заказчик разницы не увидит (между ios и windows), везде сейчас js/css/html, разница будет существенной в скорости разработки и возможности удаленной поддержки. Все вышесказанное в большей степени касается сложных специфических решений (например учетные системы). Если продукт серийный, лучше портатить время на нативное приложение для ios/android.

Нескоклько раз прочитал текст, пытаясь уловить настоящую мысль. Я правильно понял, что тут вы говорите не про «сервер-приложение», а про разделение самой мобильной разработки на UI и логику?

:)
Я о мобильной разработке знаю только по комментариям коллег, но кажется, что мобильная разработка тоже движется к какому-то разделению, аналогичному вебу: верстка и яваскрипт.

Мобильная разработка ничем принципиально не отличается от разработки под обычные компы, только свои новые фишки. Под WindowsPhone можно как и прежде писать в визуал студии (там же и эмулятор телефона есть). Что касается бекэнда, реализуемая логика на сервере вообще не должна зависить от интерфейса клиента и платформы где он воплощён, всё пишится как обычно.

А чем бек-енд мобильной разработки отличается от бек-енда любой другой?

Ну в рамках обсуждения этой темы это оффтопик, имхо.

не офтопік а дуже цікаве питання
бакенд він не розділяється на окремо мобільний і «десктопний/вебовський» він один. А до нього можуть бути різні типи кліентів

Вы меня не правильно поняли, я под бекендом имел ввиду не сервер, а внутреннюю логику приложения.

Тогда никакой это нафиг не бекенд. Вся «внутренняя логика» подчиняется фронту, от его пляшет.

Да, бывают исключения. Например, игры — многие должны работать автономно, в отрыве от серверов. Но это не бекенд, это считается тоже фронтом. И для него нельзя нанять отдельного профессионала, ибо объём взаимодействия будет такой, что 5 дней на митинги и 1 час на работу.

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

У вас слишком узкое понятие о бекенде, бекенд это не всегда серверная часть, это уровень взаимодействия с данными, а не с представлением (UI).

Как раз нет. Перевод данных в UI — это работа фронта. В противном случае это ещё одно звено, в большинстве случаев отсутствующее как таковое. Причина банальна: всё что можно делать на сервере — стараются там и делать.

Однако и здесь свои нюансы. Если работать на китайский рынок, там проблемы с инетом, и потому всё что может делаться в оффлайне — в оффлайн и переносят. Вот там да, оффлайновая логика требует высокой квалификации разработчика. Но язык не повернётся назвать его работу бекендом. Поскольку опять-таки, эта логика пишется по человеческим правилам, а не по серверным.

Ты же не называешь производителя тяжеловесных апликух под винду — бекендерами? Нет. Они просто производители приложений. Так и с мобайлом — очень нескоро, если вообще произойдёт, начнётся МАССОВОЕ деление квалификации с выделением фронтендера. Но повысится востребованность специалистов по UI — это факт. Потому что возможности мобайла растут, а возможности пользователя — нет. А значит огромная конкуренция именно за внимание юзера.

Если работать на китайский рынок, там проблемы с инетом

Далеко не только на китайский. Проблем с инетом хватает и в западном мире, если не ограничиваться локациями «дом», «офис», «деловой район мегаполиса».

Но в Китае решение этих проблем должно работать «из коробки». Онлайновое приложение в Китае априори проигрывает тому, которое способно нормально работать в оффлайне, требуя лишь эпизодического соединения для синхронизации.

Примерно как кит: выныривает, подышит, и снова под воду.

Собственно говоря, в Украине те же грабли. Просто её мало кто рассматривает как платежеспособный рынок.

Senior Inside Logic iOS Developer?

Немного оффтопик, но советую прочитать нашумевшую заметку Криса Мессины о «conversational commerce»:

medium.com/...e-1586e85e3991#.k8fw3nq0h

Возможно, в скором будущем вам вообще не прийдется задумываться о проблеме озвученной в топике.

Год китайской моды в Калифорнии, или Командная Строка — возвращение живых мертвецов?

А вообще забавный тренд, да. Но имхо на один сезон, не больше. По-моему выросло новое поколение людей, не знакомых с концепцией CLI, и соответственно загоревшихся идеей. Пройдет в очередной раз.

новых интересных возможностей, которые происходят «под капотом»
Каких именно ?

Тут про мобильную разработку идет речь. Точнее, про iOS.

Ну я бы не сказал что конкретно про iOS, это я просто пример привел, я имел ввиду все мобильные платформы.

Ну я на ваш профиль посмотрел и предположил :)

Підписатись на коментарі