Все 3 зукипенра в одном кластере должны быть в одном состоянии? Т.е. каждый зукипер должен знать о состояниях всех брокеров? не совсем из контекста понял кто есть кто
По схемам - я абсолютно с тобой согласен, мы так все в итоге настроили для других реализаций, но это другая история. А про данную статью - в моменте разработки - эти идеи почему то не подошли или не пришли в голову.
По поводу Redis - изначально цель была исследовать как из коробки работает NestJs Microservices, где было обещано бесшовное переключение транспорта между сервисами. Так как Кафка была в этой "коробке" - и так как необходимо было чуть поднять экспертизу по ней - выбрана была она, чтоб убить несколько зайцев сразу. Ну как оказалось - из коробки оно не работает, да и как и предполагалось, к сожалению, не подошло к вопросу ответу
По gRPC - да спасибо, я внимательнее это все изучу - и так как он "в коробке неста" - попробую его затащить в будушем!
Динамическая схема - возможные поля описаны в БД в отдельной коллекции. В процессе мы дошли до того, что совершенно не страшно и быстро триггерить генерацию типов и схем при изменении бд разными хуками, но на тот момент - было как было.
По поводу масштабируемости gprc - это вопрос момента. Видимо в тот момент у меня было недостаточно экспертизы в этом, были какие то проблемы в TS с ним, да и быстро окинув взглядом статьи разные - увидел много мнений, кто то говорил "сложно масштабировать", кто то говорил "не сложно".
По поводу общего случая - для чего и что подходит - абсолютно согласен - для "точка точка" - пошли по более простому пути и по хттп стали стучаться от сервиса к сервису. - по поводу что Кафка изначально и не для этого - это понятно, просто необходимо было для исследования поведений Кафки в таких странных для нее случаях
По моему мнению, история JS на беке иногда начинается с историй про то, что удобно когда фронт и бек написан на одном языке, и можно на начальных стадиях развития проекта одним разработчиком закрыть сразу много "дыр", а потом уже разделяться на более глубокий бек и фронт.
Могут еще так же затесаться истории про пороги вхождения в язык и т.п.
Все 3 зукипенра в одном кластере должны быть в одном состоянии? Т.е. каждый зукипер должен знать о состояниях всех брокеров? не совсем из контекста понял кто есть кто
По схемам - я абсолютно с тобой согласен, мы так все в итоге настроили для других реализаций, но это другая история. А про данную статью - в моменте разработки - эти идеи почему то не подошли или не пришли в голову.
По поводу Redis - изначально цель была исследовать как из коробки работает NestJs Microservices, где было обещано бесшовное переключение транспорта между сервисами. Так как Кафка была в этой "коробке" - и так как необходимо было чуть поднять экспертизу по ней - выбрана была она, чтоб убить несколько зайцев сразу.
Ну как оказалось - из коробки оно не работает, да и как и предполагалось, к сожалению, не подошло к вопросу ответу
По gRPC - да спасибо, я внимательнее это все изучу - и так как он "в коробке неста" - попробую его затащить в будушем!
Динамическая схема - возможные поля описаны в БД в отдельной коллекции. В процессе мы дошли до того, что совершенно не страшно и быстро триггерить генерацию типов и схем при изменении бд разными хуками, но на тот момент - было как было.
По поводу масштабируемости gprc - это вопрос момента. Видимо в тот момент у меня было недостаточно экспертизы в этом, были какие то проблемы в TS с ним, да и быстро окинув взглядом статьи разные - увидел много мнений, кто то говорил "сложно масштабировать", кто то говорил "не сложно".
По поводу общего случая - для чего и что подходит - абсолютно согласен
- для "точка точка" - пошли по более простому пути и по хттп стали стучаться от сервиса к сервису.
- по поводу что Кафка изначально и не для этого - это понятно, просто необходимо было для исследования поведений Кафки в таких странных для нее случаях
По моему мнению, история JS на беке иногда начинается с историй про то, что удобно когда фронт и бек написан на одном языке, и можно на начальных стадиях развития проекта одним разработчиком закрыть сразу много "дыр", а потом уже разделяться на более глубокий бек и фронт.
Могут еще так же затесаться истории про пороги вхождения в язык и т.п.