Здравствуйте, Pzz, Вы писали:
Pzz>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.
Точно так же, как и из tcp порта. Никакой разницы.
Здравствуйте, varenikAA, Вы писали:
AA>Но, так то да, прелесть js в том, что не нода, а в том что это слаботипизрованный лисп с синтаксом java(си).
Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.
Здравствуйте, AleksandrN, Вы писали:
I>>С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.
AN>Как API с языком связан? В любом случае, когда в системе есть несколько взаимодействующих частей, нужно сначала подумать о протоколе и форматах данных для взаимодействия и о разделении зон ответственности. Тут полезен будет подход API first. Можно для описания API через HTTP использовать инструменты типа swagger или RAML.
Непосредственно. Вот ты фронтненд разработчик к примеру. Тебе надо вызвать некоторый АПИ для своей формы. Джавы ты не знаешь, код у них энтерпрайзный, по паттернам, т.е. куда ни глянь, нигде нет полной картины происходящего. АПИ не готов.
Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.
Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.
Здравствуйте, Ikemefula, Вы писали: I>Непосредственно. Вот ты фронтненд разработчик к примеру. Тебе надо вызвать некоторый АПИ для своей формы. Джавы ты не знаешь, код у них энтерпрайзный, по паттернам, т.е. куда ни глянь, нигде нет полной картины происходящего. АПИ не готов.
Бардак в процессах разработки. I>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.
Требовать описания API, собрать команду для обсуждения.
По моему опыту, всегда, когда была необходимость создания API или своих сетевых протоколов, люди из разных команд совместно обсуждали, какие данные нужно передавать и в каком виде. Совместно принятое решение документировалось.
А для того, что описать что-то на сваггере или других подобных инструментах, всё равно нужно решение о том, какое должно быть API. Такие инструменты удобны тем, что есть генератор документации и генератор кода на разных языках. I>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.
Если используется один язык везде, удобно, конечно, написать обёртку над API и использовать её во всех частях. Но завтра может потребоваться прикрутить мобильное приложение на Kotlin/Java/Swift, послезавтра — железку с прошивкой на Си. Команда может за несколько лет поменяться полностью. Поэтому — документация по API необходима.
P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая.
Например — на Highload++2019 была пара интересных докладов на похожую тему
Здравствуйте, Sheridan, Вы писали:
S>И поэтому его надо заменить на рендеринг+скрипты, да.
Но ты же сам требовал писать энергосберегающий код. Вот тут как раз можно найти разумный компромисс между задачами сервера и клиента. Уровень повыше, чем машинных команд, но задача та же.
Здравствуйте, AleksandrN, Вы писали:
I>>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.
AN>Требовать описания API, собрать команду для обсуждения.
Ну собрал, ну обсудили, убедились что твой вариант годный. Жди, пока другие закончат свои важные дела или переключайся на другую задачу.
AN>По моему опыту, всегда, когда была необходимость создания API или своих сетевых протоколов, люди из разных команд совместно обсуждали, какие данные нужно передавать и в каком виде. Совместно принятое решение документировалось.
То есть, документирование избавит тебя от реализации?
AN>А для того, что описать что-то на сваггере или других подобных инструментах, всё равно нужно решение о том, какое должно быть API. Такие инструменты удобны тем, что есть генератор документации и генератор кода на разных языках.
Ля-ля-ля. Реализацию кто делать будет?
I>>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.
AN>Если используется один язык везде, удобно, конечно, написать обёртку над API и использовать её во всех частях. Но завтра может потребоваться прикрутить мобильное приложение на Kotlin/Java/Swift, послезавтра — железку с прошивкой на Си. Команда может за несколько лет поменяться полностью. Поэтому — документация по API необходима.
При чем здесь документирование?
AN>P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая.
Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить. Бакенды заняты. Джавы ты не знаешь. Заглушки тебя не устраивают. Что дальше?
Здравствуйте, Ikemefula, Вы писали:
Pzz>>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.
I>Точно так же, как и из tcp порта. Никакой разницы.
И как? Я гланул на спецификацию пакета http из ноды. Что-то не нашел там места, куда можно было бы самодельный объект для ввода-вывода передать.
Здравствуйте, Privalov, Вы писали:
P>Но ты же сам требовал писать энергосберегающий код. Вот тут как раз можно найти разумный компромисс между задачами сервера и клиента. Уровень повыше, чем машинных команд, но задача та же.
Можно, бесспорно. Только нода для этого не нужна ни разу.
Здравствуйте, Pzz, Вы писали:
I>>Точно так же, как и из tcp порта. Никакой разницы.
Pzz>И как? Я гланул на спецификацию пакета http из ноды. Что-то не нашел там места, куда можно было бы самодельный объект для ввода-вывода передать.
Почему ты решил, что заданная функциональность непременно должна быть доступна именно в этом модуле?
Здравствуйте, Ikemefula, Вы писали:
AN>>P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая. I>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить. Бакенды заняты. Джавы ты не знаешь. Заглушки тебя не устраивают. Что дальше?
То есть это такой случай, когда есть фронт разработчик, который хорошо понимает устройство и работу бэкенда, настолько что вполне может туда вписать адекватный код вместо бэкенд разработчиков, но при этом вообще нисколько-нисколько не знает C#/Java, который используют эти разработчики, а вот с js он бы писал там легко?
Мне почему-то кажется, что это весьма редкий случай. Чаще будет что или фронт-разработчик вообще не готов лезть в бэк, или синтаксис другого языка ему не будет сильной проблемой.
Здравствуйте, Ikemefula, Вы писали:
I>Непосредственно. Вот ты фронтненд разработчик к примеру. Тебе надо вызвать некоторый АПИ для своей формы. Джавы ты не знаешь, код у них энтерпрайзный, по паттернам, т.е. куда ни глянь, нигде нет полной картины происходящего. АПИ не готов. I>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно. I>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.
Ранее было сказано, что при использовании Java основная проблема что код "по паттернам, нигде нет ясной картины". Т.е. проблема НЕ в языке а в большой системе с неочевидными взаимосвязями. Почему в случае JS картина станет понятной и очевидной? Видимо, переход на node.js предполагает и упрощение структуры backend-а, но так может его просто надо было упростить на той же Java? Или там оно оправдано, но тогда, может быть, с упрощением в node.js варианте поспешили?
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, Ikemefula, Вы писали:
AN>>>P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая. I>>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить. Бакенды заняты. Джавы ты не знаешь. Заглушки тебя не устраивают. Что дальше?
F>То есть это такой случай, когда есть фронт разработчик, который хорошо понимает устройство и работу бэкенда, настолько что вполне может туда вписать адекватный код вместо бэкенд разработчиков, но при этом вообще нисколько-нисколько не знает C#/Java, который используют эти разработчики, а вот с js он бы писал там легко?
Выставить АПИ, который уже оговорен, это не рокет саенс.
F>Мне почему-то кажется, что это весьма редкий случай. Чаще будет что или фронт-разработчик вообще не готов лезть в бэк, или синтаксис другого языка ему не будет сильной проблемой.
Реализовывать АПИ редкий случай? Это самый частый случай. Эта работа как правило не сильно сложная, рядом с одним методом прикрутить еще один похожий.
Соответсвенно автономность как фронтов, так и бакендов увеличивается. Пофиксил свою часть — пофиксил и смежные, нет проблем. А если js-java, надо или универсальных солдат заводить, которых днем с огнем на найдешь, или трекать зависимости.
Здравствуйте, fmiracle, Вы писали:
F>Ранее было сказано, что при использовании Java основная проблема что код "по паттернам, нигде нет ясной картины". Т.е. проблема НЕ в языке а в большой системе с неочевидными взаимосвязями. Почему в случае JS картина станет понятной и очевидной? >Видимо, переход на node.js предполагает и упрощение структуры backend-а, но так может его просто надо было упростить на той же Java? Или там оно оправдано, но тогда, может быть, с упрощением в node.js варианте поспешили?
Нод жээс сам по себе проще джавы. Дополнительно, можно выделить АПИ таким образом, что бы его майнтейнили как фронты, так и бакенды.
На джаве когда то было нечто похожее, когда фронт пытались писать на джава. Но эти ужасы давно канули в лету.
Здравствуйте, Ikemefula, Вы писали:
I>Заглушки тебя не устраивают. Что дальше?
Не понял, кто мешает написать на фронтенде код-заглушку, который будет возвращать какие-то данные вместо бэкенда, для тестов.
А потом, когда бэкенд будет готов, подключить к нему уже готовый фронтенд.
Здравствуйте, Буравчик, Вы писали:
Б>Не понял, кто мешает написать на фронтенде код-заглушку, который будет возвращать какие-то данные вместо бэкенда, для тестов. Б>А потом, когда бэкенд будет готов, подключить к нему уже готовый фронтенд.
Эту самую заглушку делают не вместо бакенда, а вместе с бакендом, и находится она на стороне бакенда. Только пишет её как правило фронтендщик. АПИ, данные — ничего лишнего. Понадобилось чтото еще — не проблема, добавим сами.
И вот здесь нужно что бы фронтенд мог писать этот простой серверный код.
Писать заглушки на фронтенде смысла немного — слишком много лишней работы, поддержка только вырожденных кейсов.
На самом деле нужно стремиться к хорошему варианту — за один заход написать 100% фичи, без каких либо зависимостей, без каких либо издержек. Заглушки здесь слабо помогают — растягивается деливери, нужно трекать зависимости, переключаться на ровном месте и тд и тд.
Это от безысходности, а не какой то рокет саенс.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Буравчик, Вы писали:
I>Эту самую заглушку делают не вместо бакенда, а вместе с бакендом, и находится она на стороне бакенда. Только пишет её как правило фронтендщик. АПИ, данные — ничего лишнего. Понадобилось чтото еще — не проблема, добавим сами. I>И вот здесь нужно что бы фронтенд мог писать этот простой серверный код.
Зачем писать серверный код, если можно написать заглушку на фронтенде, зная API.
I>Писать заглушки на фронтенде смысла немного — слишком много лишней работы, поддержка только вырожденных кейсов.
Работы не слишком много. Не все кейсы покрываются, но это позволяет написать 80% фронтенда. Пока будешь писать и бэк уже напишут.
I>На самом деле нужно стремиться к хорошему варианту — за один заход написать 100% фичи, без каких либо зависимостей, без каких либо издержек. Заглушки здесь слабо помогают — растягивается деливери, нужно трекать зависимости, переключаться на ровном месте и тд и тд.
Идеал недостижим. Над фичей работают разные люди, кому-то из них приходится ждать других. Здесь как раз заглушки помогают.
Здравствуйте, Буравчик, Вы писали:
I>>Эту самую заглушку делают не вместо бакенда, а вместе с бакендом, и находится она на стороне бакенда. Только пишет её как правило фронтендщик. АПИ, данные — ничего лишнего. Понадобилось чтото еще — не проблема, добавим сами. I>>И вот здесь нужно что бы фронтенд мог писать этот простой серверный код.
Б>Зачем писать серверный код, если можно написать заглушку на фронтенде, зная API.
Забавно — ухитряешься задать вопрос сразу перед ответом на него.
I>>Писать заглушки на фронтенде смысла немного — слишком много лишней работы, поддержка только вырожденных кейсов.
Б>Работы не слишком много. Не все кейсы покрываются, но это позволяет написать 80% фронтенда. Пока будешь писать и бэк уже напишут.
Я бы сказал хорошо если половина. Заглушки на бакенде стоят дешевле, позволяют реализовать почти все кейсы, особенно, если используется микросервисная архитектура.
I>>На самом деле нужно стремиться к хорошему варианту — за один заход написать 100% фичи, без каких либо зависимостей, без каких либо издержек. Заглушки здесь слабо помогают — растягивается деливери, нужно трекать зависимости, переключаться на ровном месте и тд и тд.
Б>Идеал недостижим. Над фичей работают разные люди, кому-то из них приходится ждать других. Здесь как раз заглушки помогают.
И по твоему это повод отказываться от оптимизации разработки ? Заглушки помогают, но можно лучше. Например — размещать их на бакенде.
Здравствуйте, Ikemefula, Вы писали:
I>Я бы сказал хорошо если половина. Заглушки на бакенде стоят дешевле, позволяют реализовать почти все кейсы, особенно, если используется микросервисная архитектура. I>И по твоему это повод отказываться от оптимизации разработки ? Заглушки помогают, но можно лучше. Например — размещать их на бакенде.
А что такое заглушка на бэкенде? Может мы про разные вещи говорим.
Ты говорил о проблеме — пока бэк не реализован, фронтендеры не могут работать.
Не пойму, в чем суть твоей "оптимизации разработки". Подгонять бэкендеров? Превращать фронтендеров в фулл-стек?
Ну если фронтендеры бэкенд писать не умеют, то пишут фронт (заглушки на фронте). Да, это дополнительная работа, но скорость доставки фич у команды возрастает.
Здравствуйте, Буравчик, Вы писали:
I>>И по твоему это повод отказываться от оптимизации разработки ? Заглушки помогают, но можно лучше. Например — размещать их на бакенде.
Б>А что такое заглушка на бэкенде? Может мы про разные вещи говорим.
То же, что и на фронте, только возможностей больше.
Б>Ты говорил о проблеме — пока бэк не реализован, фронтендеры не могут работать.
Б>Не пойму, в чем суть твоей "оптимизации разработки". Подгонять бэкендеров? Превращать фронтендеров в фулл-стек?
Большая автономность у разработчиков, границы ответственности изменяются. Фронты частично пишут бакенд. Бакенды частично пишут фронтенд.
Чем меньше заглушек, тем лучше.
Б>Ну если фронтендеры бэкенд писать не умеют, то пишут фронт (заглушки на фронте). Да, это дополнительная работа, но скорость доставки фич у команды возрастает.
А если фронты умеют писать бек, а бакенды — фронт, то скорость доставки еще более возрастает.
