|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
mikola1982 не совсем понял, кто будет отдавать первую страничку, то есть когда пользователь нажимает на ссылку... запрос уходит на какой сервер (имеется ввиду программная реализация). ведь пользователю кто-то должен вернуть страничку с которой уже браузер получит JS, который сможет слать запросы WEBApi. Кто отправляет первую страничку? сервер и отправляет как обычно. В этом и гемор c этими решениями на webapi - все равно надо отдавать HTML традиционным способом а потом таскать данные через api и растыкивать их с помощью клиентских решений. В результате трудоемкость вырастает раза в три. лишний раз убеждаешся что все эти MVC не говоря уже о клиентских фреймворках и SPA страницах придуманы теми кто не занимается практическим програмированием. Нет ни малейшего смысла в таких решениях, потому как пользователю начхать как там сайт рендерится (если конечно это не мобильный браузер где все эти клиентские фрейморки работаю очень хреново) а програмисту больше работы. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 11:33 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
caballero сервер и отправляет как обычно. В этом и гемор c этими решениями на webapi - все равно надо отдавать HTML традиционным способом а потом таскать данные через api и растыкивать их с помощью клиентских решений. В результате трудоемкость вырастает раза в три. Ну как бы для решения проблем придумали микросерверную архитектуру. Т.е. клиенту пофиг что там на стороне сервера. Главное чтобы на запросы отвечал. Серверу пофиг, что там на стороне клиента. Главное, чтобы запросы были правильные. Т.о. на сервере пишут сервисы (например REST-сервисы, которые отдают JSON) А клиент работает с этими сервисами. Причем клиентом может быть как браузер HTML5 +js, так и десктоп, так и мобильное приложение. В тему топика. Выбрать удобный, современный js-фреймворк. Благо их как грязи. А на серверы реализовывать REST-ы. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 11:46 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
mad_nazgul, не надо рассуждать о том о чем не имеете представления. еще раз - это красивая теория. а практика - мобильные браузеры не вытягивают ни по памяти ни по быстродействию клиентские фреймворки. а писать отдельное приложение для каждого сайта - еще сложнее и дороже. в любом случае вопрос остается - ради чего эти мучения? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 12:19 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
caballeromad_nazgul, не надо рассуждать о том о чем не имеете представления. еще раз - это красивая теория. Ага. Участвовал уже в двух проектах. которые сделаны по этой "теории". caballeroа практика - мобильные браузеры не вытягивают ни по памяти ни по быстродействию клиентские фреймворки. а писать отдельное приложение для каждого сайта - еще сложнее и дороже. в любом случае вопрос остается - ради чего эти мучения? Э-э-э как-то наоборот получается проще и дешевле. Серверная часть делается одна для всех клиентов. А клиентская часть затачивается под конкретное устройство. Под iOS свой клиент, под Android свой. Только под ПК приходится мучится с кроссбраузерностью и темой для слабовидящих. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 12:50 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
mad_nazgul Ага. Участвовал уже в двух проектах. которые сделаны по этой "теории". это ничего не доказывает кроме того что вы где то участвовали . а другие не участвовали И что? Э-э-э как-то наоборот получается проще и дешевле. Серверная часть делается одна для всех клиентов. А клиентская часть затачивается под конкретное устройство. Под iOS свой клиент, под Android свой. Только под ПК приходится мучится с кроссбраузерностью и темой для слабовидящих.[/quot] вы хоть немного логику применяете когда пишете? человеку нужен просто сайт, как это нужно в подавляющем большинстве случаев. а вы предлагаете вместо просто разрабтки сайта, мало того что усложнить сам сайт еще писать приложения под три платформы и это при том что в мобильных устройствах есть браузеры которые нормально справляются без всяких SPA, RESt и прочего. даже если система должна предоставлять API для внешнего обмена данными, все равно быстрее и проще разрабатывать сайт традиционным способом хотя бы потому что тогда API будет решать только узкую задачу обмена необходимыми данными а не выполнять функцию обмена со всем сайтом чтобы обеспечить функционал всех страниц. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 13:13 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
caballeroэто ничего не доказывает кроме того что вы где то участвовали . а другие не участвовали И что? А то, что теория подкреплена практикой. Рабочей практикой. Причем у меня была практика и "монолитных" сайтов. Где формирование и обработка страниц происходила только на стороне сервера. Оно конечно работало... Но микросервисы мне как программисту показались удобнее. Да и тестировать проще. caballeroвы хоть немного логику применяете когда пишете? человеку нужен просто сайт, как это нужно в подавляющем большинстве случаев. Статичные странички вообще могут без бакенда. Все что работает по принципу "запрос-ответ" удобнее реализовывать ч/з микросервисы. caballeroа вы предлагаете вместо просто разрабтки сайта, мало того что усложнить сам сайт еще писать приложения под три платформы и это при том что в мобильных устройствах есть браузеры которые нормально справляются без всяких SPA, RESt и прочего. Да. Есть. Справляются... Как раз для таких браузеров микросервисы ложатся как влитые. HTML5 наше всио! :-) caballero даже если система должна предоставлять API для внешнего обмена данными, все равно быстрее и проще разрабатывать сайт традиционным способом хотя бы потому что тогда API будет решать только узкую задачу обмена необходимыми данными а не выполнять функцию обмена со всем сайтом чтобы обеспечить функционал всех страниц. Как раз микросервисы позволяют разрабатывать сайты "традиционным способом". В качестве API выступает REST-сервис. Мало того это API "универсальное", то слабо зависит от клиента. Т.е. к этому API может подключится любой клиент. Грубо говоря версталщик делает страницы как ему заблагорассудится, а фронтенд-программист пишет запросы к REST'ам и распихивает ответы в нужные узлы DOM-модели в любом удобном для него фреймворке. Да и по трафику выходит выгоднее. Статичная информация передается на клиент один раз, а данные подгружаются по мере необходимости. Ну аж для мобилок вообще все замечательно. Иногда заказчик хочет не сайт, а "мобильное приложение". Вместо того, чтобы писать специально для мобилок свой API, он оказывается уже написан когда делали сайт. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 14:05 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
mad_nazgulНо микросервисы мне как программисту показались удобнее. Да и тестировать проще. это уже как "сто лет" называется компонентной архитектурой . ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 14:12 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
iscrafmmad_nazgulНо микросервисы мне как программисту показались удобнее. Да и тестировать проще. это уже как "сто лет" называется компонентной архитектурой . Согласен. Просто микросервисы задали "стандарт" для API между клиентом и сервером. Например на том же SOAP делать такие приложение то еще удовольствие. А REST прост, быстр и понятен. ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 15:03 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
v_enomWebAPI - те же REST контроллеры, та же модель, возвращаемая как json. Просто уже приготовленно всё - webApi приготовлен для ajax запросов с UIТут надо уточнить, что не обязательно JSON (content negotiation) и не обязательно с UI. v_enomWCF нужны скорее для работе по SOAP или даже бинарных данных а также очень тонкой настройки. WebAPI упрощены, что вполне удобно. Просто WCF больше пока не будут поддерживаться. Хз что там и почему, но инфа ещё с того года.Какая-то у Вас "левая" инфа. Вот что Вы предлагаете использовать вместо net.tcp и nms (Apache ActiveMQ) биндингов? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 15:36 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
mad_nazgulПросто микросервисы задали "стандарт" для API между клиентом и сервером. Например на том же SOAP делать такие приложение то еще удовольствие. А REST прост, быстр и понятен. ;-) замечательно и круто. эйчэры будут в восторге. вопрос только один - на фига это нужно НА ПРАКТИКЕ в подавляющем большинстве случаев при разработке сайта, особенно если учесть что сайт с помощью стилей легко заточить на любой браузер и любое устройство.. экономия трафика - не аргумент при нынешних скоростях инета ( тем более экономии там на самом деле никакой нет) а вот время разработки, то есть стоимость програмиста куда критичнее. Особенно при разработке на несколько платформ. и ничем REST не упрощает - в больших проектах как раз SOAP выгоднее, просто потому что предоставляет обьектный интерфейс а не стопицот отдельных методов. впрочем нет смысла спорить с человеком просто нахватавшимся умняков с инета. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 15:38 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
caballeromikola1982не совсем понял, кто будет отдавать первую страничку, то есть когда пользователь нажимает на ссылку... запрос уходит на какой сервер (имеется ввиду программная реализация). ведь пользователю кто-то должен вернуть страничку с которой уже браузер получит JS, который сможет слать запросы WEBApi. Кто отправляет первую страничку? сервер и отправляет как обычно. В этом и гемор c этими решениями на webapi - все равно надо отдавать HTML традиционным способом а потом таскать данные через api и растыкивать их с помощью клиентских решений. В результате трудоемкость вырастает раза в три. лишний раз убеждаешся что все эти MVC не говоря уже о клиентских фреймворках и SPA страницах придуманы теми кто не занимается практическим програмированием. Нет ни малейшего смысла в таких решениях, потому как пользователю начхать как там сайт рендерится (если конечно это не мобильный браузер где все эти клиентские фрейморки работаю очень хреново) а програмисту больше работы.Вот Вам простой практический пример: на WebAPI написан сервис бронирования чартерных рейсов, морды к которому клиенты пишут сами на чём хотят. Тем, кто не может самостоятельно написать веб-морду, продаём сайт, написанный на ASP.NET MVC. Чем это не практично? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 15:40 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
caballeromad_nazgulПросто микросервисы задали "стандарт" для API между клиентом и сервером. Например на том же SOAP делать такие приложение то еще удовольствие. А REST прост, быстр и понятен. ;-) замечательно и круто. эйчэры будут в восторге. вопрос только один - на фига это нужно НА ПРАКТИКЕ в подавляющем большинстве случаев при разработке сайта, особенно если учесть что сайт с помощью стилей легко заточить на любой браузер и любое устройство..Ахаха, то есть responsive design это типа очень просто, а REST сложно... Ну ну... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 15:44 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
skyANAcaballeroпропущено... сервер и отправляет как обычно. В этом и гемор c этими решениями на webapi - все равно надо отдавать HTML традиционным способом а потом таскать данные через api и растыкивать их с помощью клиентских решений. В результате трудоемкость вырастает раза в три. лишний раз убеждаешся что все эти MVC не говоря уже о клиентских фреймворках и SPA страницах придуманы теми кто не занимается практическим програмированием. Нет ни малейшего смысла в таких решениях, потому как пользователю начхать как там сайт рендерится (если конечно это не мобильный браузер где все эти клиентские фрейморки работаю очень хреново) а програмисту больше работы.Вот Вам простой практический пример: на WebAPI написан сервис бронирования чартерных рейсов, морды к которому клиенты пишут сами на чём хотят. Тем, кто не может самостоятельно написать веб-морду, продаём сайт, написанный на ASP.NET MVC. Чем это не практично? :) практично всем. Просто не все это понимают. То, что в WEB-разработку начало это продвигаться от имени Фаулера внушает некоторую надежду, что существующий сегодня бардак в этой отрасли будет постепенно вымирать. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 16:01 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
caballeroSOAP выгоднее, просто потому что предоставляет обьектный интерфейс а не стопицот отдельных методов объектный интерфейс хорош в системных разработках. В прикладной логике как раз "стипицот" отдельных методов хороши, из которых пользователь может выбрать нужные ему ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2015, 16:05 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
Получается гибрид между приложением WEBApi и ASP.NET MVС. или стоит отдельно поднять веб-сервер для отдачи начальных страниц, а эти страницы уже будут ломится на webApi сервер. получается web-приложение где на сервере практически не будет логики, плюс webApi-сервис. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 06:06 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
mikola1982, перечитайте внимательно первый пост. Да, сервис отдельно, клиент отдельно. Автора интересует на чем писать последний. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 06:22 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
Кстати, если рассматривать только клиента, то я таки за вариант 3. Осталось подходящий фреймворк(и) выбрать. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 06:29 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
Cheerful Calf, а в вариантах 1, 2 ASP.NET приложение с какого конца медленного интернета устанавливается? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 06:33 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
skyANAmikola1982, перечитайте внимательно первый пост. Да, сервис отдельно, клиент отдельно. Автора интересует на чем писать последний. как я понял автор определился, а что бы не создавать новую тему, задал свой вопрос. Всем спасибо за ответы. идея с WEBApi очень интересная, у такого сервиса появляется масса возможностей, web- приложения, мобильные приложения, декстоп-приложения все будут ломится на один сервис, и брать что им нужно, единственный минус глобальные изменения в webApi, могут потребовать переписывания кучи софта, но тут можно легко выкрутится, добавляя новый функционал не трогая старый. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 07:09 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
caballeroзамечательно и круто. эйчэры будут в восторге. Я уже в том возрасте когда на HR мне плевать. А вот дуобство в работе ценю. caballeroвопрос только один - на фига это нужно НА ПРАКТИКЕ в подавляющем большинстве случаев при разработке сайта, особенно если учесть что сайт с помощью стилей легко заточить на любой браузер и любое устройство.. Обычно, на практике, тот кто пишет бакенд, верстает сайт и пишет стили, и тот кто пишет js-скрипты это три разных человека. Причем, они работают не последовательно, а параллельно. И для того, чтобы они работали параллельно микросервисная архитектура подходит идеально. Пока бакендщик напишет сервис, js-скрпитер на заглушках отладит скрипты и вместе с верстальщиком сделают морду. На другом проекте, где использовался более традиционный подход. Либо я ждал, когда верстальщик сделает сверстает страницу, либо верстальщик ждал, когда я сделаю страницу. А сейчас я сделал сервис за пару дней. А верстальщик с аналитиком, пусть кнопочки двигают туда суда, по хотелкам заказчика. Я же следующий сервис пилю. caballeroэкономия трафика - не аргумент при нынешних скоростях инета ( тем более экономии там на самом деле никакой нет) а вот время разработки, то есть стоимость програмиста куда критичнее. Особенно при разработке на несколько платформ. Как я и гвоорил выше. Скорость разработки возрастает. Не скажу насколько. Но как минимум я могу делать больше. Т.к. моя задачи просты и понятны. Получил запрос, отправил ответ. caballeroи ничем REST не упрощает - в больших проектах как раз SOAP выгоднее, просто потому что предоставляет обьектный интерфейс а не стопицот отдельных методов. В силу специфики проектов, я грубо говоря, занимаюсь переводом SOAP-сервисов в REST. Так вот SOAP ни разу не выгоднее. Это связано с тем, что SOAP более универсальное, а соответственно более сложное решение. REST и JSON прост. Он не может много, но для подавляющего большинства задач возможности SOAP просто не нужны. Ну нафига нам описание контракта, с встроенной валидацией. Когда нужно передать формочку, а в ответ получить табличку. ФЛК все равно надо делать на js. Чтобы сразу указать пользователю на ошибку не дожидаясь ответа от сервера. А табличку надо просто показать, без всякой проверки. Кроме того мне как программисту все равно что REST-JSON, что SOAP-XML. И то, и то с помощью соответствующих фреймворков спокойно преобразуется в объекты. Причем JSON мне читать проще, чем XML. caballeroвпрочем нет смысла спорить с человеком просто нахватавшимся умняков с инета. Ага. Который сидит в суровом Ынтырпрайзе и ковыряет SOAP-сервисы, попутно борясь со всякими шинами. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 07:15 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
mikola1982Получается гибрид между приложением WEBApi и ASP.NET MVС. или стоит отдельно поднять веб-сервер для отдачи начальных страниц, а эти страницы уже будут ломится на webApi сервер. получается web-приложение где на сервере практически не будет логики, плюс webApi-сервис. на сервере не будет формирования интерфейсов, логика никуда с него не уходит. Если Вы о "микропросервисах" и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 08:46 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
что-то почти никто не обратил внимание на "медленный интернет", для меня например это 64кб/с с обрывами, и ни о какой передаче данных в реальном времени речи идти не может, а следовательно и о рендеринге на стороне сервера Cheerful Calf, поясните насчет медленного интернета? рассматривался вариант декстопных клиентов? иначе надо искать js фреймворк, который позволит написать полностью автономное приложение на js, это в свою очередь означает первичную загрузку большого объема данных и кеширование в браузере, далее обращение к серверу допустимо только за данными (причем возможно со сжатием), но может работать медленно так же я бы построил прототип, на котором выяснил бы баланс между кол-вом запросов и объемом предаваемых данных (можно один большой запрос и тысячу маленьких) - и потестировал бы с медленным интернетом и заданной нагрузкой по кол-ву одновременных пользователей есть ли ограничения при выборе хостинга? платформа - линкус или виндовс? ps кендо для версии mvc - тот ещё отстой, как пытаешься сделать что то отличное от демо примеров - спотыкаешься, возможно js версия лучше, но я бы в любом случае рассматривал бы написание своего движка на основе js фреймворка ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 09:14 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
17-77рассматривал бы написание своего движка на основе js фреймворка программист не будет программистом, если при наличии готового не напишет свой движок. Предсказуемо.... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 09:34 |
|
На чем писать клиента?
|
|||
---|---|---|---|
#18+
17-77ps кендо для версии mvc - тот ещё отстой, как пытаешься сделать что то отличное от демо примеров - спотыкаешься, возможно js версия лучше, но я бы в любом случае рассматривал бы написание своего движка на основе js фреймворка Зачем? Есть же уже готовые фреймворки, для которых нужно только сервисы написать. Например angular. Хотя у моего коллеги при слове angular рука тянется к пистолету :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.08.2015, 12:20 |
|
|
start [/forum/topic.php?fid=33&msg=39028666&tid=1547442]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 209ms |
0 / 0 |