Немного вас не понял. ExecutionContext двигается с нами, да. Но чтобы какую-то инфу двигать, нужно же вызывать как раз методы LogicalSetData/LogicalGetData.
Quartz.NET — это планировщик задач, так? Тогда у меня получится то же самое, что и способ с сохранением ID из статьи, только здесь еще и добавляется внешний инструмент. Планировщики задач это нужная штука при больших задачах, требующих последовательности/консистентности. А при таких маленьких задачах, как получение данных о пользователе, я считаю, это лишнее. Насчет нелогичности — спорный момент. Запрос к АПИ начинается во время запроса пользователя к сайту. Здесь же выигрыш в том, что в логе мы видим сразу всю инфу, а не ковыряем разные источники в ее поисках.
Да, Вы меня не поняли немного. Переформулирую: как вы отдадите случайное имя JS-скрипту, который обратился к вашему бэкенду? Вы либо будете писать в тело каждого сообщения для Kafka какой-то идентификатор, а потом этот идентификатор отдавать клиенту (то что я описал выше). Вариант второй: Вы поставите в паузу текущий поток общения клиента с сервером и будете ждать, пока другой поток не запишет результат в Ваше хранилище (при этом потребность в идентификаторах никуда не уходит, потому что вам нужно как-то различать одинаковые топики). В первом варианте клиент может оставить в покое сокет и сделать еще несколько запросов, дожидаясь результата на своей стороне. Во втором варианте сокет между браузером и приложением же будет висеть, поток для обработки тоже будет в повисшем состоянии, и вскоре сервер поднимет лапки (если мы говорим о более менее нагруженном сайте). Прибавьте к этому горизонтальное расширение бэкенд-серверов и распределение нагрузки между ними, и вы получите какую-то кашу.
Одно но: cейчас если мы, например, запустим 5 штук NameService, то в MainApp придет 5 имен, а не одно. Это из-за настроек Apache Kafka, прописанных в файле server.properties. В рамках туториала я этого намеренно не касаюсь, чтобы не усложнять материал.
У вас получается по коду, что делая запрос из клиента MainApp, мы сразу выходим из цикла и пишем ответ уже в другом потоке. При этом получается, что будь это веб-приложение, нам бы пришлось поддерживать на стороне бэкенда свою очередь тоже (т.е. пользователь нажимает на кнопку "Сгенерировать имя", мы сопоставляем этому запросу некий идентификатор, сохраняем его, а потом клиент через какое-то время достает ответ отдельным запросом к бэкенду, имея на руках этот идентификатор). Это, как известно, имеет свои последствия (в частности, возникает вопрос о масштабируемости такого решения). Но я всегда считал, что Message Broker должен позволять это сделать без всяких самописных очередей. Разве протокол Kafka не позволяет сделать нечто подобное?
var response = await msgBus.SendMessage(topic: gTopicNameCmd, message: gMessage);
Console.WriteLine(response);
Здесь подразумевается, что запрос и ответ имеют одинаковый topic gTopicNameCmd. Следовательно, Kafka сама разруливает кому какой ответ отдать, а мы ждем от нее ответ и никуда не уходим, пока он не прилетит.
Дело в том, что мы в проекте используем Typewriter для того, чтобы сгенерить типы данных Typescript по уже имеющимся типам C#. Так как Typewriter не умеет ссылаться на другой автосгенеринный тип данных автоматически, я это сделал следующим образом: все сгенерированные типы я экспортирую в одном файле all.ts и в шаблоне Typewriter я импортирую этот файл как: import * as Models from './all'. Думал, что как-то можно заюзать директиву module, но из ваших слов я понял, что это сделать не получится. От текущего решения я как-то не в восторге, поэтому надо искать что-то другое....
У меня один небольшой вопросик к знатокам typescript. Есть такая директива module. Как я понял, она позволяет создавать один модуль из нескольких ts-файлов. В итоге, в пределах данного модуля я могу спокойно обращаться к классу, находящемуся в другом файле, не импортируя его. Компилятор хорошо понимает, что я хочу сделать. Но webpack — нет. Уже в браузере мне выдается сообщение об ошибке, что класс не найден. Кто-нибудь знает, как побороть данную проблему?
Вы ошибаетесь. Это напрямую влияет на специфичность селекторов.
О БЭМ я думаю как о решении, разработанном конкретной компанией под их задачи, с которыми мне еще не приходилось сталкиваться. Это нестандартный взгляд на вещи со своими плюсами и минусами.
Я согласен насчет производительности. Даже не думал про нее. Я подумал, вы про именование и формат говорите, поэтому сказал, что всегда так пишу. Без препроцессоров это просто нереально поддерживать. Я никогда так не делаю, если пишу на чистом CSS.
На уровне исходных стилей поддерживать легко. Переносишь блок стилей на уровень корневого элемента и получаешь совсем другие конечные селекторы. А на уровне HTML поддерживать точно также как и все остальное. Эти вещи поддерживать мало влияют друг друга в случае использования препроцессоров, поддерживающих древовидную структуру.
Да. Только не на текущий, а на родительский селектор. Вот только ваш код моя библиотека не переваривает из-за неравномерно расставленных пробелов в строке. Будем разбираться. Попробуйте пока этот:
body {
a {
color: red;
&:visited {
color: blue;
}
.some-parent & {
font-weight: bold;
}
}
}
Вы имеете в виду древовидную структуру селекторов? Тогда, да. В MySheet есть данная возможность. В статье есть пример с этой функцией. Для наглядности приведу еще один:
html
height 100%
body
color #777
height 100%
font-family: 'Open Sans', sans-serif;
.wrapper
position relative
min-height 100%
#header
color #fff
background-color rgba(0, 0, 0, 60%)
#logo
float left
.title
padding 4px 5px
font-weight bold
font-size 14pt
#main-menu
overflow hidden
ul
float right
li
float left
padding 8px 6px
компилируется в следующий CSS-код:
html {
height: 100%
}
html body {
color: #777777;
height: 100%;
font-family: "Open Sans",sans-serif
}
html body .wrapper {
position: relative;
min-height: 100%
}
html body .wrapper #header {
color: #ffffff;
background-color: rgba(0, 0, 0, 0.6)
}
html body .wrapper #header #logo {
float: left
}
html body .wrapper #header #logo .title {
padding: 4px 5px;
font-weight: bold;
font-size: 14pt
}
html body .wrapper #header #main-menu {
overflow: hidden
}
html body .wrapper #header #main-menu ul {
float: right
}
html body .wrapper #header #main-menu ul li {
float: left;
padding: 8px 6px
}
Немного вас не понял. ExecutionContext двигается с нами, да. Но чтобы какую-то инфу двигать, нужно же вызывать как раз методы LogicalSetData/LogicalGetData.
Quartz.NET — это планировщик задач, так? Тогда у меня получится то же самое, что и способ с сохранением ID из статьи, только здесь еще и добавляется внешний инструмент. Планировщики задач это нужная штука при больших задачах, требующих последовательности/консистентности. А при таких маленьких задачах, как получение данных о пользователе, я считаю, это лишнее. Насчет нелогичности — спорный момент. Запрос к АПИ начинается во время запроса пользователя к сайту. Здесь же выигрыш в том, что в логе мы видим сразу всю инфу, а не ковыряем разные источники в ее поисках.
Хорошее замечание.
Не делает. Сайт из примера крутится на полном фреймворке (Target Framework у него — .NET Framework 4.6.2).
Да, Вы меня не поняли немного. Переформулирую: как вы отдадите случайное имя JS-скрипту, который обратился к вашему бэкенду? Вы либо будете писать в тело каждого сообщения для Kafka какой-то идентификатор, а потом этот идентификатор отдавать клиенту (то что я описал выше). Вариант второй: Вы поставите в паузу текущий поток общения клиента с сервером и будете ждать, пока другой поток не запишет результат в Ваше хранилище (при этом потребность в идентификаторах никуда не уходит, потому что вам нужно как-то различать одинаковые топики). В первом варианте клиент может оставить в покое сокет и сделать еще несколько запросов, дожидаясь результата на своей стороне. Во втором варианте сокет между браузером и приложением же будет висеть, поток для обработки тоже будет в повисшем состоянии, и вскоре сервер поднимет лапки (если мы говорим о более менее нагруженном сайте). Прибавьте к этому горизонтальное расширение бэкенд-серверов и распределение нагрузки между ними, и вы получите какую-то кашу.
У вас получается по коду, что делая запрос из клиента MainApp, мы сразу выходим из цикла и пишем ответ уже в другом потоке. При этом получается, что будь это веб-приложение, нам бы пришлось поддерживать на стороне бэкенда свою очередь тоже (т.е. пользователь нажимает на кнопку "Сгенерировать имя", мы сопоставляем этому запросу некий идентификатор, сохраняем его, а потом клиент через какое-то время достает ответ отдельным запросом к бэкенду, имея на руках этот идентификатор). Это, как известно, имеет свои последствия (в частности, возникает вопрос о масштабируемости такого решения). Но я всегда считал, что Message Broker должен позволять это сделать без всяких самописных очередей. Разве протокол Kafka не позволяет сделать нечто подобное?
Здесь подразумевается, что запрос и ответ имеют одинаковый topic gTopicNameCmd. Следовательно, Kafka сама разруливает кому какой ответ отдать, а мы ждем от нее ответ и никуда не уходим, пока он не прилетит.
Это идея. Надо будет попробовать. Спасибо.
См. мой коммент выше
Дело в том, что мы в проекте используем Typewriter для того, чтобы сгенерить типы данных Typescript по уже имеющимся типам C#. Так как Typewriter не умеет ссылаться на другой автосгенеринный тип данных автоматически, я это сделал следующим образом: все сгенерированные типы я экспортирую в одном файле all.ts и в шаблоне Typewriter я импортирую этот файл как: import * as Models from './all'. Думал, что как-то можно заюзать директиву module, но из ваших слов я понял, что это сделать не получится. От текущего решения я как-то не в восторге, поэтому надо искать что-то другое....
О БЭМ я думаю как о решении, разработанном конкретной компанией под их задачи, с которыми мне еще не приходилось сталкиваться. Это нестандартный взгляд на вещи со своими плюсами и минусами.
компилируется в следующий CSS-код: