Comments 22
На КДПВ бэкендер огораживает свой стройный и прекрасный мир от результатов обсуждения фронтами последнего спринта по переползанию с React на Vue.
(Не замечая, что его любимый тул ездит гусеницами по кривым рельсам)
(Не замечая, что его любимый тул ездит гусеницами по кривым рельсам)
Проблематику как с языка сняли.
Мы идём ровно тем же путём, только команда у нас чуть меньше, и стек бэкенда — Java.
На этапе пилота мы столкнулись с низкой производительностью Apollo Server, а именно фазы сериализации данных. Вы проводили нагрузочные тесты? Какая планируется вычислительная мощность под Apollo?
Пока детальных нагрузочных тестов не проводили. Замеряли производительность клиентских приложений до и после перевода на GraphQL, просадку не заметили. Вообще судя по обзорам и статьям сам по себе GraphQL сильных тормозов давать не должен. В любом случае спасибо за наводку, покопаю в этом направлении.
Хоть бы кто показал готовый продукт, что бы понять имеет ли смысл подобного рода статьи.
Я это вот к чему, ИТ тема стала хайповой последние пару лет. Народ пачками лезет в эту тему, появляется конкуренция, соответственно всем приходится что-то постоянно придумывать, что бы как то обосновать свою зп.
И вот что я наблюдаю:
1) Разросшиеся команды программистов
2) Кучу продакт менеджеров
3) Кучу аналитиков
4) UI дизайнеров
5) Бесконечные переговоры, встречи, согласования
6) Туда-сюдашечки со стеками
А по факту мы имеем обычные GUI приложения, которые писались еще и 5 и 10 и 15 лет назад, ну да более технологичные, но смысловая нагрузка вообще никак не поменялась.
Хотелось бы видеть о какого рода продуктах вы говорите? Пощупать, потыкать… т.к сказать убедится, что все о чем вы написали действительно имеет практический смысл.
Вот честно залез на ваш сайт, по скриншотам сразу бросаются в глаза стыренные с инета иконки, стилистически относящиеся к 2007-2008 году, судя по описанному функционалу и картинкам — это максимум 3 разработчика. Опять судя по картинкам не понятно зачем вам вообще front разработчик?
Я это вот к чему, ИТ тема стала хайповой последние пару лет. Народ пачками лезет в эту тему, появляется конкуренция, соответственно всем приходится что-то постоянно придумывать, что бы как то обосновать свою зп.
И вот что я наблюдаю:
1) Разросшиеся команды программистов
2) Кучу продакт менеджеров
3) Кучу аналитиков
4) UI дизайнеров
5) Бесконечные переговоры, встречи, согласования
6) Туда-сюдашечки со стеками
А по факту мы имеем обычные GUI приложения, которые писались еще и 5 и 10 и 15 лет назад, ну да более технологичные, но смысловая нагрузка вообще никак не поменялась.
Хотелось бы видеть о какого рода продуктах вы говорите? Пощупать, потыкать… т.к сказать убедится, что все о чем вы написали действительно имеет практический смысл.
Вот честно залез на ваш сайт, по скриншотам сразу бросаются в глаза стыренные с инета иконки, стилистически относящиеся к 2007-2008 году, судя по описанному функционалу и картинкам — это максимум 3 разработчика. Опять судя по картинкам не понятно зачем вам вообще front разработчик?
А слова Gmail, Facebook и Twitter вам ни о чем не говорят? :)
Разработка ПО и программирование как частность в моем понимании это управление сложностью (если отбросить шелуху в виде технологий и инструментов). По факту мы действительно решаем те же задачи, но более технологичные, т.е. более сложные. Поэтому и требуются новые подходы и инструменты.
Всё о чем я пишу в статье к сайту компании никакого отношения не имеет, им занимается отдельная команда. Мы работаем над продуктом BILLmanager (почитать про него можно здесь www.ispsystem.ru/software/billmanager, там же есть ссылка на demo). На demo нет новой API, но общие объемы задач, которые подтолкнули нас к изменениям можно увидеть.
Правильно говорите тема IT хайповая. Разобраться в чем-то бывает не просто, всё усложняется ещё и тем, что многие зарабатывают на этом хайпе. В итоге чтобы найти реально полезные вещи приходится сначала наступить на много граблей. Я описал реальную ситуацию — огромный проект с большим легаси, чтобы развиваться пришлось начать многое изменять (что-то из этого получилось, что-то нет). Надеюсь кому-то это подскажет решение их проблем и получится пройти наш путь проще и быстрее.
Всё о чем я пишу в статье к сайту компании никакого отношения не имеет, им занимается отдельная команда. Мы работаем над продуктом BILLmanager (почитать про него можно здесь www.ispsystem.ru/software/billmanager, там же есть ссылка на demo). На demo нет новой API, но общие объемы задач, которые подтолкнули нас к изменениям можно увидеть.
Правильно говорите тема IT хайповая. Разобраться в чем-то бывает не просто, всё усложняется ещё и тем, что многие зарабатывают на этом хайпе. В итоге чтобы найти реально полезные вещи приходится сначала наступить на много граблей. Я описал реальную ситуацию — огромный проект с большим легаси, чтобы развиваться пришлось начать многое изменять (что-то из этого получилось, что-то нет). Надеюсь кому-то это подскажет решение их проблем и получится пройти наш путь проще и быстрее.
Почти дословно это многие говорят лет 15 уже минимум. А ещё так говорили, когда GUI пошёл в массы, только сравнивали с TUI (как у Norton Commander :) )
Выглядит как чудовище франкенштейна, если честно. Но всей специфики не знаю, поэтому сложно что-то советовать или комментировать.
Но эти затраты окупятся, когда пользователей API станет больше.
Надеюсь, вы правы.
На самом деле статья про очередные микросервисы. Разделяй и властвуй (в теории)
вот уже почти 30 лет одно и то же — Тонкие клиенты / толстые клиенты… rinse-wash-repeat. GraphQL или нет, но головой придется думать
Тоже думали про GraphQL, но в итоге отказались, он решает одни проблемы и приносит новые. Одно не пойму, синтаксис GraphQL и gRpc похож на json, почему его не сделать полностью совместимым, была бы сразу поддержка парсинга на всех языках. В итоге пока как самый простой вариант остановился на json-rpc. Простой стандарт, реализация вызовом между сервисами на разных языках делается за пару часов и никого не надо долго обучать как с этим работать
Как дела у всех этих модных GraphQL и gRpc обстоят с документированием api? У GraphQL на сколько помню все довольно не плохо, а у gRpc?
новомодные BE/FE разделения иногда выглядят глупо, есть же MVC при котором клиентскую часть будет рендерить сервер, фронтендеры при этом не страдают, а пишут темплейты с байдингом ну или как у автора Апи комманда которая создаёт прослойку которая только клиентской частью занимается и вместо базы данных будет сервис с которым каким-то образом можно общаться, REST или любой другой тут вообще нет ограничений в отличии от подхода где клиент из браузера может только по хттп спросить данные
А вот насчёт формата данных от BE нужно подумать, у нас BE пишет сначала свой кусок и учит работать с ним FE, что иногда не очень потому что FE могут не понимать зачем им сложные куски и из них чтото собирать когда надо одну пропертю, иногда правы одни, иногда другие. BE хотят всё универсальным и быстродейственным зделать, a FE им написать табличку/формочку и забыть, а значит данные должны быть максимально простыми, и усложнения ведут к тому что может чтото поламаться и тогда клиенту вообще ничего не покажется
А вот насчёт формата данных от BE нужно подумать, у нас BE пишет сначала свой кусок и учит работать с ним FE, что иногда не очень потому что FE могут не понимать зачем им сложные куски и из них чтото собирать когда надо одну пропертю, иногда правы одни, иногда другие. BE хотят всё универсальным и быстродейственным зделать, a FE им написать табличку/формочку и забыть, а значит данные должны быть максимально простыми, и усложнения ведут к тому что может чтото поламаться и тогда клиенту вообще ничего не покажется
Стоит различать BE/FE разделения организационные и технические. Если разделение чисто организационное, то часто страдают обе стороны. А даже введение отдельных темплейтов для фронтендеров уже по сути техническое разделение. Вопрос лишь как далеко заходить в этом разделении. А браузерный клиент ещё может данные по websocket запрашивать. Оно, конечно, не совсем независимо от http, но очень близко к тому
Прочитал два раза пост, но так и не понял до конца, можно ли считать, что изобрели паттерн API Gateway с технической точки зрения?
Наше API состоит из двух основных частей GRPC и GraphQL сервера (прослойки). Сейчас можно говорить что GRPC сервер отчасти следует паттерну API Gateway. Что касается прослойки, то на её стороне пока используется только один сервис, собственно GRPC. У Apollo ещё есть инструмент использования micro-schemas, когда несколько микросервисов предоставляют схемы своих API, а шлюз их объединяет и отдает конечному клиенту в виде единого API. Это кажется достаточно интересным, но требует высокого уровня развития микросервисов.
UFO just landed and posted this here
Sign up to leave a comment.
Как разделить фронтенд и бэкенд, сохранив взаимопонимание