Один 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
1) 2 раза не писать бакенд

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

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

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

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

Весь Frontend

и будет

собираться на сервере.

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

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

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

гектар-полтора оперативы тут же отхавает база. Ещё полгектара в лучшем случае сам бекенд

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

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

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

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

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

Кому должен?

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

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

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

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

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

Я думал в 21-м веке уже все делается как SPA.

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

twitter

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

ebay, payoneer, amazon

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

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

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

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

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

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

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

Попробовал:

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

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

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

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

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

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

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 для веба и мобильного приложения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Парсить страничку на фронте — это безумие.

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

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

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

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

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

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

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

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

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

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

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

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