Вхід і реєстрація
Розробка · 22 жовтня 2017, 11:23 3779
Vadym Shcherbyna

Один backend для сайта и приложения

Здравствуйте, подскажите пожалуйста по общему вопросу.

Планируется сайт и android приложение: сайт frontend будет static html, сайт backend будет laravel, приложение backend будет openAPI.

Frontend сайта должен быть чистый html без vue, angular. Весь Frontend должен собираться на сервере.

А можно как то что бы backend сайта использовал backend приложения (api)?

Или это полный изврат и надо делать API для приложения отдельно а backend сайта отдельно?

Смысл в том что бы: 1) 2 раза не писать бакенд 2) был единый бакенд для сайта и приложения

Или вот еще вариант чтобы baclend сайта забирал по API данные, потом собирал вьюху. Но обращаться же ларавел будет к API по http — и это же скажется на скорости?

👍ПодобаєтьсяСподобалось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
Євген Козлов Front-end developer в SoftServe 24.10.2017 00:46
1) 2 раза не писать бакенд

часть моделей будет юзаться обоими частями.
работа с БД будет юзаться обоими частями.
авторизация будет разная(token для API, сессия для web), вью будут разные(HTML vs JSON/XML/bin), роутинг и тот будет разный(CRUD vs action-based)
в итоге, наслаивая одно поверх другого придется делать дурную работу по преобразованию одного интерфейса(в программистком смысле) в другой.
я б даже логирование и обработку ошибок разделял.
а большинство изменений API аукнется переделкой web версии.
назачем?

UPD бляха, думал, свежий топик. теперь пролистал и вижу, шо повторяюсь. соррян.

Відповісти
Підтримати
Eugene Varava PHP/Python Developer 24.10.2017 00:07
Frontend сайта должен быть чистый html без vue, angular.

 а если на том же PHP сделать с full page cache?
технически,

Весь Frontend

и будет

собираться на сервере.
Відповісти
Підтримати
Vlad Skachkov лячкаю говнокод в ФОП 23.10.2017 15:40

запихнуть всю логику в модели.

дергать модели из апишек и с бекенда

Відповісти
Підтримати
Олексій Пєніє 23.10.2017 16:25

На пыхыпы всё так и делают. Как только пойдёт нагрузка, придётся оплатить за вычислительный ресурс. Не так чтоб уж много, но гектар-полтора оперативы тут же отхавает база. Ещё полгектара в лучшем случае сам бекенд. Ну и системе чего-то надо. Итого ≈8 евро в месяц, не так чтобы сильно имело смысл платить кодерам за рефакторинг.

Відповісти
Підтримати
Vlad Skachkov
Vlad Skachkov лячкаю говнокод в ФОП 23.10.2017 17:49
гектар-полтора оперативы тут же отхавает база. Ещё полгектара в лучшем случае сам бекенд

это наверно с каким-то ультра говнокодингом.
никогда не сталкивался с такими расходами ресурсов, а повидал я всяких индусов.

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 23.10.2017 21:47

Таким большим или таким малым? Просто это говорит скорее о вашем опыте, видать просто не было возможности держать в руках серьёзные проекты. Разумеется, hello world или магазинчик с двумя посетителями в сутки можно и на бесплатном хостинге поднять.

Відповісти
Підтримати
Vlad Skachkov
Vlad Skachkov лячкаю говнокод в ФОП 23.10.2017 22:27

ну был как-то проект по управлению умными(нет) домами и сбором/отображением статистики по количеству полученной/потраченной энергии из возобновляемых источников — база там была чуть больше средней (80гб) но вот на стороне пхп был мемори лимит 256 — хватало с головой

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 24.10.2017 01:31

И эти люди запрещают мне ковыряться в носу

Відповісти
Підтримати
Vlad Skachkov
Gennady Dogaev full-stack web developer (freelance) 23.10.2017 13:54
Frontend сайта должен быть чистый html без vue, angular

Кому должен?

А можно как то что бы backend сайта использовал backend приложения (api)?
Или это полный изврат и надо делать API для приложения отдельно а backend сайта отдельно?

Вообще в таком случае правильнее всего:
— Ядро, имеющее своё апи
— Сайт, использующий ядро через апи
— Апи для приложения, которое использует ядро через его апи

Это, на мой взгляд, была бы самая правильная архитектура. Но с другой стороны есть ведь бюджет и время. Поэтому можно всё слепить. Но сделайте чтобы всё что касается апи для приложения лежало в отдельной директории (модуле или что там у ларавеля есть) и c url поступите так же. Типа www.mysite.com/api/resourceName. Будет дешево и сердито.

Відповісти
Підтримати
Vladyslav Melnyk 22.10.2017 16:48
Frontend сайта должен быть чистый html без vue, angular. Весь Frontend должен собираться на сервере.

И для чего если не секрет?=)
Я думал в 21-м веке уже все делается как SPA.
Как вариант:
модели>репозитории>сервисы.
А дальше переиспользуете эти сервисы и в backend’e сайта и в backend’e api.

Відповісти
Підтримати
Elance Test 22.10.2017 17:39
Я думал в 21-м веке уже все делается как SPA.

Угу. ebay, payoneer, amazon, twitter да все что угодно более-менее известное SPA не является. Из известного сходу недавно наткнулся на Linkedin — теперь он SPA.

Відповісти
Підтримати
Vladyslav Melnyk
Vladyslav Melnyk 22.10.2017 18:43
twitter

1 страница, сплошные ajax’ы, посты загружаются Lazy Loading’ом. Чистый SPA.

ebay, payoneer, amazon

Говно мамонта, которое пилилось, когда о SPA никто и не знал. В том же Payoneer до сих пор WebForms используется.

Відповісти
Підтримати
Elance Test
Vladyslav Melnyk 23.10.2017 00:20

Никто же не спорит, но это не значит что новые проекты надо лепить на WebForms в 2017-м году.

Відповісти
Підтримати
anonymous
Elance Test 24.10.2017 17:12
1 страница, сплошные ajax’ы, посты загружаются Lazy Loading’ом.

Да. Соглашусь. Кстати там файл есть на 40 К строчек jQuery кода. Представляю как у любителей spa фреймворков полыхает.

Відповісти
Підтримати
Vladyslav Melnyk
Gennady Dogaev full-stack web developer (freelance) 24.10.2017 19:56

Про gulp слышали?

Відповісти
Підтримати
Elance Test
Elance Test 24.10.2017 21:19

Я скорее об обилии богомерзких дом-манипуляций, от которых доу-тру-фронтенд-братия покрывается пузырями как от святой воды.

Відповісти
Підтримати
Gennady Dogaev
Elance Test 24.10.2017 11:44

Не знаю на счет реакта, но нашел тьму кода на jQuery.

Відповісти
Підтримати
Valentine Zgonnik
Elance Test 24.10.2017 12:15

Попробовал:

wappalyzer.com
builtwith.com
chrome.google.com/...​benondhkanegppccanebkdjlh

Реакт не обнаружен. Я не всегда доверяю этим штуковинам, хотелось бы чтобы был кусок кода явно из реакт-мира.

Відповісти
Підтримати
Valentine Zgonnik
Valentine Zgonnik JavaScript Dev 24.10.2017 12:40

штуковина от реакт разработчиков и показывает state приложения, значит обнаружен
blog.twitter.com/...​e-built-twitter-lite.html

Відповісти
Підтримати
Elance Test
Elance Test 24.10.2017 17:14

Так это мобильный твиттер. А я о настоящем.

Відповісти
Підтримати
Valentine Zgonnik
Valentine Zgonnik JavaScript Dev 25.10.2017 00:20

Настоящий использует компоненты на нем, например плеер для видео и гифок. Но весь он конечно не полностью на react. Хоть и есть ssr

Відповісти
Підтримати
Elance Test
Vadym Shcherbyna 22.10.2017 18:14

1) для seo
2) мы староверы — js запрещен, верстаем на таблицах, режем в fireworks.

Відповісти
Підтримати
Vladyslav Melnyk
Alex Xtrace 22.10.2017 21:03
1) для seo

срочно начинайте читать гайдлайны по SEO оптимизации от самих поисковых машин в разделах для web-developer-ов... правильные sitemaps решают.

уточню: любое SEO на ресурсах, где действительно финансово обосновано замарачиваться подобным, должно формироваться вокруг главного концептуального СЯ (семантического ядра) релевантного бизнес-модели данного веб-ресурса (т.е. той части трафика с поисковых запросов, которые гарантированно отобъются в некой обозримой перспективе в виде финансового профита) Во всех остальных случаях, SEO — лохотрон (уже давно переставший быть модным) для закешенного лоха-клиента.

в любом случае, sitemap по СЯ вашего ресурса, который разумеется может «изменить мир к лучшему», будет выглядеть незаметным по размеру файлом среди прочих seraya_lineyka_v_menu_sverhu.png и подобных ресурсов, когда же использование адекватных frontend фреймверков окупит чеовеко часы на порядки, избавляя от необходимости вас и команду «перебивать» руками говноhtml каждый раз, когда что-то поменяется на backend-е

в общем, не замарачивайте рассудок холливаром который имел место быть года 3 назад (plain html vs isomorphic apps vs backend templating) и используйте universal apps (как писалось выше) или современный mvvm фреймверк на фронтенде и только один backend с версионностью/facade-слоем API для веба и мобильного приложения

Відповісти
Підтримати
Vadym Shcherbyna
Олексій Пєніє 22.10.2017 23:25

SEO — не аргумент. Никто не говорит тянуть весь контент скриптами. Наоборот, надо сначала взять контент статикой, а уже потом (или сразу) в динамике собрать (лучше из кеша) всю обвеску. Ещё более правильно — отдать контент в IFrame, если он не имеет жёстких связей с обвеской.

Если хочешь прокачать SEO — сделай «версию для печати» и отдавай туда только контент.

Відповісти
Підтримати
Vadym Shcherbyna
Євген Козлов Front-end developer в SoftServe 24.10.2017 00:49
Наоборот, надо сначала взять контент статикой, а уже потом (или сразу) в динамике собрать (лучше из кеша) всю обвеску.

что, конечно, будет быстрее, чем old-school HTML. или нет?

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 24.10.2017 01:33

Насколько old?
Если это для SEO, то есть роботов кормить, то можно нахер дизайн убрать как таковой и отдавать контент текстами.

Відповісти
Підтримати
Євген Козлов
Євген Козлов Front-end developer в SoftServe 24.10.2017 14:15

я не однозначно выразился.
«быстрее» в отношении разработки и деплоя, а не «быстрее будет работать».
не вижу смысла в СПА, если у тебя нет активного влияния пользователей на контент

Відповісти
Підтримати
Олексій Пєніє
mobile mobile 23.10.2017 23:44

тут про линкед ин вспоминали, он после того как стал СПА — редкостное глючное болото. Я конечно понимаю что некоторые продукты не имеют реальной ценности и пытаются юзера плюшечками оставаться подольше, но лично у меня такие сайты вызывают отвержение, особенно когда что то там на бекэнде глючит и ты жми-не-жми а результата нету

Відповісти
Підтримати
Vladyslav Melnyk
Alexandr Sova Developer 22.10.2017 15:25

Ты же всё равно где-то (скорее всего в контроллере) будешь получать данные что тебе нужно отобразить на странице и в приложении. А html or json etc. это же только типы вьюхи. Различай их по Accept request header и в порядке приоритета строй ту что клиент поддерживает. Так можно потом будет и совсем до binary уйти если вдруг понадобится.

Відповісти
Підтримати
Олексій Пєніє 22.10.2017 13:11

Давай покажу тебе монстра который может получиться по итогу, если решишь отказаться от логики на фронте, предоставив львиную часть беку. Вспомни какой товар их ассортимента этого магазина недавно покупал, и попробуй купить его здесь. А именно — прицениться, посмотреть ассортимент и выбрать то что тебе надо. Цель — не застрелиться.

Итак, в номинации «Звизда UI» первое место и звание «Жлоб 2016» получает... 27.ua, принадлежащий скромной бедной конторке по имени Эпицентр.

Відповісти
Підтримати
Олексій Пєніє 22.10.2017 13:04

Технически можно всё, и на практике примерно это всё и делается (я про Java). Вот только физически этим зверем сложно управлять, и как правило его потом разбивают: одно ядро на ведение модели, и несколько к нему более простых интерфейсных фиговинок.

Всё сильно зависит от нагрузки. Совет как от архитектора: не заморачивайся с архитектурой, особенно если это стартап. Знаешь что делать — делай быстро так как знаешь. Живой процесс перестроить можно, и даже недорого пока мало клиентов. А если начнёшь планировать сразу монстра — монстром и получится. Слишком рано перейдёт в стадию зрелости, и проиграет эволюцию.

На практике фронт всё равно удобнее со скриптами. Просто потом что когда-то «тонкий» клиент стал полноценным сервером приложений, с распределением данных и безопасности, умеющий сшивать DOM-модель с потрясающей скоростью и рулить то чем видишь. И хотя сейчас каналы быстрые — но они быстрые не везде, ты не можешь рассчитывать на пинг 8мс. Так что спешу расстроить, фронт делать нужно.

Больше скажу, с фронта надо начинать, это та часть проекта которая будет монетизироваться. А вот бекенд будет писаться и переписываться потом. У тебя через два года жизни проекта останется в лучшем случае 10% от старого кода на бэкенде.

Обращаться по HTTP — нормально. Вон в JAVA сколько счастья по SOAP работает, и прекрасно всё крякает. Правда по мере эволюционирования имеет свойство обрастать мусором (для совместимости со старыми версиями), но это уже мелочи корпоративного софта, не обращай внимания.

Відповісти
Підтримати
Vadym Shcherbyna 22.10.2017 11:53

Проблема в том что: надо что бы не frontend сайта (vue/angular) обращался к API и рендерил страницу, а backend laravel обращался к API, забирал json и рендерил blade шаблон с данными.

Відповісти
Підтримати
anonymous
Vadym Shcherbyna 22.10.2017 12:00
Парсить страничку на фронте — это безумие.

Парсить страничцу на backend-е — вы имели ввиду?

Відповісти
Підтримати
anonymous
Vadym Shcherbyna 22.10.2017 12:09

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

Відповісти
Підтримати
anonymous
Alexander 22.10.2017 12:08

У вас в laravel чтоль if-ы закончились? Или там нету поддержки query параметров?

Відповісти
Підтримати
Vadym Shcherbyna
Alexander 22.10.2017 11:39

Обычно все делают 1 бекенд.

Відповісти
Підтримати
Vadym Shcherbyna 22.10.2017 11:42

И backend сайта обращается по http к API? Или Vue/Angular обращается к API?

Відповісти
Підтримати
Alexander
One dev army None 22.10.2017 14:21

Есть SPA на фронте, которое ходит к backend API.

Відповісти
Підтримати
Vadym Shcherbyna
Dmitriy Chaban 22.10.2017 18:50

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

Відповісти
Підтримати
Vadym Shcherbyna
Vadym Shcherbyna 22.10.2017 19:28

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

Відповісти
Підтримати
Dmitriy Chaban
Dmitriy Chaban 22.10.2017 23:27

Вот пример от линкедина:
content.linkedin.com/...​g/migrated/arch_soa_0.png
полная статья — engineering.linkedin.com/...​-history-scaling-linkedin
В общих чертах примерно так и используется.
Front web app на картинке у вас по сути будет заменен на 2 компонента — рест апи и какие-то веб приложение которое может рендерить темплейты на стороне сервера.
По производительности проблем обычно нет, т.к. все находится в пределах одного датацентра и каждый компонент можно горизонтально масштабировать в случае необходимости.

Відповісти
Підтримати
Vadym Shcherbyna
Alexandr Sova Developer 22.10.2017 23:40

Есть разные примеры, но на старте проекта этим лучше не заморачиваться. Обычно такое хорошо делать если есть недешёвое железо и недешёвый канал. Тогда, если правильно всё сделать, http или какое-нибуть асинхронное взаимодействие не станет затыком. Но в таких случаях нужно уже будет помнить что там где в монолите есть true/false в распределённых системах будет true/false/ConnectionError и это уже нужно обвешивать resilensy, self-healing и прочим что звучит здорово, но готовится не просто. В результате для очень простой задачи придётся переломить мышление, забыть о вожделенном request-response lifetime и рассчитывать на fire and forget only. Оно вам надо в начале? Кому как, а большинству систем такое лучше вводить после милиона пользователей.

Відповісти
Підтримати
Vadym Shcherbyna
mobile mobile 23.10.2017 23:46

поддержу , будет миллион юзеров- начнете решать ити проблемы.

Відповісти
Підтримати
Alexandr Sova

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.