Comments 22
(Не замечая, что его любимый тул ездит гусеницами по кривым рельсам)
Проблематику как с языка сняли.
Мы идём ровно тем же путём, только команда у нас чуть меньше, и стек бэкенда — Java.
На этапе пилота мы столкнулись с низкой производительностью Apollo Server, а именно фазы сериализации данных. Вы проводили нагрузочные тесты? Какая планируется вычислительная мощность под Apollo?
Я это вот к чему, ИТ тема стала хайповой последние пару лет. Народ пачками лезет в эту тему, появляется конкуренция, соответственно всем приходится что-то постоянно придумывать, что бы как то обосновать свою зп.
И вот что я наблюдаю:
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 хайповая. Разобраться в чем-то бывает не просто, всё усложняется ещё и тем, что многие зарабатывают на этом хайпе. В итоге чтобы найти реально полезные вещи приходится сначала наступить на много граблей. Я описал реальную ситуацию — огромный проект с большим легаси, чтобы развиваться пришлось начать многое изменять (что-то из этого получилось, что-то нет). Надеюсь кому-то это подскажет решение их проблем и получится пройти наш путь проще и быстрее.
Выглядит как чудовище франкенштейна, если честно. Но всей специфики не знаю, поэтому сложно что-то советовать или комментировать.
Но эти затраты окупятся, когда пользователей API станет больше.
Надеюсь, вы правы.
Тоже думали про GraphQL, но в итоге отказались, он решает одни проблемы и приносит новые. Одно не пойму, синтаксис GraphQL и gRpc похож на json, почему его не сделать полностью совместимым, была бы сразу поддержка парсинга на всех языках. В итоге пока как самый простой вариант остановился на json-rpc. Простой стандарт, реализация вызовом между сервисами на разных языках делается за пару часов и никого не надо долго обучать как с этим работать
Как дела у всех этих модных GraphQL и gRpc обстоят с документированием api? У GraphQL на сколько помню все довольно не плохо, а у gRpc?
А вот насчёт формата данных от BE нужно подумать, у нас BE пишет сначала свой кусок и учит работать с ним FE, что иногда не очень потому что FE могут не понимать зачем им сложные куски и из них чтото собирать когда надо одну пропертю, иногда правы одни, иногда другие. BE хотят всё универсальным и быстродейственным зделать, a FE им написать табличку/формочку и забыть, а значит данные должны быть максимально простыми, и усложнения ведут к тому что может чтото поламаться и тогда клиенту вообще ничего не покажется
Как разделить фронтенд и бэкенд, сохранив взаимопонимание