Если память не изменяет то первым языком с поддержкой async/await был F#. Там толпа энтузиастов. Ну а компилятор преобразует это в CLR, и там это выглядит в виде машины состояния с двумя состояниями, и переход между ними выполняется с помощью goto оператора. Ну а в CLR самые узкие места написаны на C/C++.
если делать контейнеры только под линукс то навряд ли победят. Возможно получат большую часть рынка, но windows server довольно популярная ос в мире интерпрайза, и там тоже нужны контейнеры
Нет, и как по мне чрезмерно переусложненно. Наверное имеет смысл в приложениях со сложными запросами. К примеру интернет-магазин со множеством фильтров
Затянул с ответом, отпуск.
В gRPC мы передаём все данные в бинарном формате, так гораздо эффективнее, для чего собственно proto формат и был создан. В javascript-e из браузера работать с ним от слова почти невозможно, собственно выходит нужно передавать в каком нибудь другом формате. Ну а дальше натыкаемся на ограниченность формата json и самого http протокола, и невозможность напрямую предоставить некоторые типы данных. Для этого даже был создан документ у них в репозитории.
Так что пока gRPC для меня выглядит как идеальное решение для межсервисной коммуникации. Ту а для веба видать пока что лучше swagger-a альтернативы нету.
Если честно, я бы просто хотел генерировать модельки описанные в IDL. Если задуматься, имея готовые модели, можно не заморачиваться со спецификой protobuf протокола, и возвращать обычный json из уже готовой модели(так как для json-a у них свои ). Ну а сервисы, можно будет самому написать, без gRPC. Ведь кому-то нужен REST, а имея на руках готовые модели мы точно знаем какой объект нам придёт, за разработчиком остаётся только определить входные точки(endpoint). Кстати, не пробовали ли вы thrift? Ну я нарыл на днях решение от майкрсофта, где есть дженерики. Они, между прочим, тоже решили следовать gRPC.
Одно но, он веб как бы не поддерживает. Есть костыли от сторонних разработчиков которые пытаются приспособить его к вебу, но если сам гугл не сделал такой поддержки, значит оно ему и не нужно. gRPC скорее больше нужен как межсервисная коммуникация. Кстати по опыту CLI protobuf-a просто ужасен.
Всё равно осадочек остался от того что протащили windows-only API. Лучше совсем без них, и для windows-a предоставлять их в виде отдельных nuget пакетов. В принципе это ещё не поздно исправить, но никто этим заниматься не будет. Сейчас у них цель, проапгредить и заоптимизировать сетевой стек.
Всем советую, у кого есть готовая библиотека или какие-нибудь компоненты написать файл дефиниции типов(d.ts). Это позволит другим людям использовать вашу библиотеку в тайпскрипте, ну а если вы пользуетесь VisualStudio Code, так вы в придачу получаете intelisense, да же из javascript кода.
Могу вспомнить как минимум resource файл в VisualStudio. Можно статично через диалоговое коно указать путь к файлу. IDE ещё на прекомпиляции проверит что такой файл существует и сгенерирует статичный класс. Очень удобно например вынести все sql файлы в такой ресурс, а потом в месте использования заявки написать что то вроде:
var result = await db.Query(SQLResources.GetProducts);
Замечания:
1. Зачем вам класс Thread? Используйте Task. И почитайте про асинхронность. Судя по вашему методу мейн, если при открытии конзоли вы не нажмете клавишу, то мы понапрасну будем есть очень много ресурсов.
2. Не знаю в какие дебри вы залезли с http, но его использовать будет гораздо проще(потому что это текстовый протокол, а не бинарный коим являеться tcp). Особенно если вы планируете веб приложение, вам надо делать ставку на http.
3. Было бы не плохо выложить ссылку на репозиторий с кодом. В таком соятоянии, я вообще не вижу кода на расте, а по c# вам надо прочитать style guide. Именование методов с подчеркиванием разве что в WinForms я и видел, которые уже устарели.
Что интересно, по факту есть всего несколько имплементаций под OWIN интерфейс а именно Kestrel и Katana(IIS). Может кто знает проекты или попытки написать свой сервер под OWIN?
В gRPC мы передаём все данные в бинарном формате, так гораздо эффективнее, для чего собственно proto формат и был создан. В javascript-e из браузера работать с ним от слова почти невозможно, собственно выходит нужно передавать в каком нибудь другом формате. Ну а дальше натыкаемся на ограниченность формата json и самого http протокола, и невозможность напрямую предоставить некоторые типы данных. Для этого даже был создан документ у них в репозитории.
Так что пока gRPC для меня выглядит как идеальное решение для межсервисной коммуникации. Ту а для веба видать пока что лучше swagger-a альтернативы нету.
1. Зачем вам класс Thread? Используйте Task. И почитайте про асинхронность. Судя по вашему методу мейн, если при открытии конзоли вы не нажмете клавишу, то мы понапрасну будем есть очень много ресурсов.
2. Не знаю в какие дебри вы залезли с http, но его использовать будет гораздо проще(потому что это текстовый протокол, а не бинарный коим являеться tcp). Особенно если вы планируете веб приложение, вам надо делать ставку на http.
3. Было бы не плохо выложить ссылку на репозиторий с кодом. В таком соятоянии, я вообще не вижу кода на расте, а по c# вам надо прочитать style guide. Именование методов с подчеркиванием разве что в WinForms я и видел, которые уже устарели.