И отсутствие готовой обёртки к популярному сервису действительно вызывает недоумение и недоверие
Вполне могу себе это представить. Обертка для Java, скорее всего, будет и будет актуальной, но ведь еще есть: .Net, Go, PHP, Ruby, Python и т.д. – поддерживать API обертки в актуальном состоянии для всех возможных языков и технологий может быть проблемой даже для очень крупной компании.
Некоторые мысли про REST сервисы
Эта проблема, на мой взгляд, проистекает из-за того, что у REST сервисов нет общепризнанного механизма их описания. Если бы он был (и все бы его использовали), то написать универсальные генераторы API оберток для всех актуальных платформ, не было бы проблемой.
И аргументы должны быть чёткими, чтобы два дня не объяснять
Так об этом и речь. В статье у коллеги автора были вполне уважительные причины сделать свою реализацию, но очень сложно сломить предупреждение, что свой велосипед никогда не может быть лучше, чем что-то готовое.
К сожалению, из личного опыта. Часто во внутрикорпоративных сетях достаточно много старого специализированного софта, который требует различных ActiveX, Java Applets, Silverlight и даже Flash, и соответственно, это все не будет работать в современных браузерах. Но софт со своими задачами справляется и гораздо проще продолжать использовать IE, чем пытаться найти замену этому софту.
До массового применения flexbox, которое началось последние года 2-3, вёрстка на html была сущим адом и xaml был (да и остаётся) куда более подходящим для вёрстки веб приложений (не сайтов).
Касательно Blazor, выглядит идея прикольно, но зачем? Ради лишь C# тащить на клиент целый рантайм это явно перебор. Я бы тогда уже предпочёл авлонию в браузере увидеть ) А так есть React, Angular и Vue, да и момент когда Typescript потеснит Js, на мой взгляд, не за горам.
Я имел в виду ситуацию, когда ошибка обнаружена в старой версии библиотеки, а на новую версию переключится непросто из-за проблем с совместимостью. Получить исходный код старой вресии обычно можно без проблем.
Обычно зависимость имеет строго определенную версию, которая не меняется годами, следуя принципу “Работает – не трогай!”. Если спустя много лет бага таки находится, то часто проще поправить ее самому, скопипастив исходный код, поскольку есть большой шанс, что за это время библиотека потеряла обратную совместимость или вообще была заброшена.
Это будет так только при определенных условиях (см. пример выше). Корме того, подобный хак может привести к ошибкам в рантайме, поскольку httpContext будет потерян и код "продолжения" не сможет получить доступ к данным запроса. Копирование http контекста из потока в поток это основная обязанность контекстов синхронизации применяемых в Asp.net, поэтому не стоит их выкидывать — лучше избавиться от этого антипаттерна .
Task это тоже вроде как монада, а async/await это просто синтаксический сахар. Вообще, работать с
монадами без специальных конструкций языка не особо удобно, так, например, в хаскеле почти всегда используется do нотация.
Кстати, ничто вам не мешает написать пару хелперов и работать с тасками через «from… in...» прямо как в Хаскеле :)
Разобрался с aspnet:UseTaskFriendlySynchronizationContext. Эта опция включена по умолчанию. C помощью этой опции можно выбирать тип контекста синхронизации между AspNetSynchronizationContext и LegacyAspNetSynchronizationContext. В “обычном” (TaskFriendly) используется неблокирующая очередь для выполнения “продолжений”, а в “старом” “продолжения” вызывались “как есть” (из потока в котором завершилась асинхронная операция).
На дедлок эта опция не влияет так как в обоих случаях вызывается код, который переносит данные запроса из одного потока в другой.
Это да, просто хотел показать, что ConfigureAwait(false) не панацея, поскольку нет никакой гарантии, что вызываемый код внутри использует ConfigureAwait(false).
Вот пример кода который все еще вызывает deadlock (WEB API 2):
[HttpGet]
public int Deadlock()
{
StartWork().Wait();
return 0;
}
private async Task StartWork()
{
await MyDelay(100).ConfigureAwait(false);
var s = "Just to illustrate the code following await";
}
private async Task MyDelay(int ms) => await Task.Delay(ms);
На месте MyDelay может быть любая другая библиотечная функция
У меня вот вопрос знающим людям. Теоретически, добавление <add key="asp:UseTaskFriendlySynchronizationContext" value="true" />
должно пофиксить дедлок в ASP.Net, поскольку эта опция разрешает выполнение кода поле асинхронной операции в любом потоке из пула (и это реально так), но по факту, дедлок остается :(
Не думаю, что у человека знакомого (хоть немного) с функциональным программированием возникнет проблема с пониманием этого кода. На мой взгляд, такая запись куда понятнее чем куча вложенных циклов.
С точки зрения кода, который использует эти методы (например, Dictionary), ничего не поменяется от того, что методы переопределены, поэтому принцип не нарушается.
Вполне могу себе это представить. Обертка для Java, скорее всего, будет и будет актуальной, но ведь еще есть: .Net, Go, PHP, Ruby, Python и т.д. – поддерживать API обертки в актуальном состоянии для всех возможных языков и технологий может быть проблемой даже для очень крупной компании.
Так об этом и речь. В статье у коллеги автора были вполне уважительные причины сделать свою реализацию, но очень сложно сломить предупреждение, что свой велосипед никогда не может быть лучше, чем что-то готовое.
а под IE нет — какой же интранет без IE? ))
Для вашей ситуации я бы рассмотрел ASP.Net (может быть даже Forms), при большом желании можно обойтись и без JavaScript и работать точно будет везде.
До массового применения flexbox, которое началось последние года 2-3, вёрстка на html была сущим адом и xaml был (да и остаётся) куда более подходящим для вёрстки веб приложений (не сайтов).
Касательно Blazor, выглядит идея прикольно, но зачем? Ради лишь C# тащить на клиент целый рантайм это явно перебор. Я бы тогда уже предпочёл авлонию в браузере увидеть ) А так есть React, Angular и Vue, да и момент когда Typescript потеснит Js, на мой взгляд, не за горам.
Может имелся в виду размер сжатых данных?
Может memcmp тоже SIMD внутри использует. Что-то уж больно быстр он.
Это будет так только при определенных условиях (см. пример выше). Корме того, подобный хак может привести к ошибкам в рантайме, поскольку httpContext будет потерян и код "продолжения" не сможет получить доступ к данным запроса. Копирование http контекста из потока в поток это основная обязанность контекстов синхронизации применяемых в Asp.net, поэтому не стоит их выкидывать — лучше избавиться от этого антипаттерна .
монадами без специальных конструкций языка не особо удобно, так, например, в хаскеле почти всегда используется do нотация.
Кстати, ничто вам не мешает написать пару хелперов и работать с тасками через «from… in...» прямо как в Хаскеле :)
aspnet:UseTaskFriendlySynchronizationContext. Эта опция включена по умолчанию. C помощью этой опции можно выбирать тип контекста синхронизации между AspNetSynchronizationContext и LegacyAspNetSynchronizationContext. В “обычном” (TaskFriendly) используется неблокирующая очередь для выполнения “продолжений”, а в “старом” “продолжения” вызывались “как есть” (из потока в котором завершилась асинхронная операция).На дедлок эта опция не влияет так как в обоих случаях вызывается код, который переносит данные запроса из одного потока в другой.
На месте MyDelay может быть любая другая библиотечная функция
Исходя из этого ограничения, ConfigureAwait не поправит ситуацию в общем случае.
Так если, например, заменить Task.Delay на
async Task MyDelay(int millisecondsDelay) => await Task.Delay(millisecondsDelayто дедлок останется.
<add key="asp:UseTaskFriendlySynchronizationContext" value="true" />должно пофиксить дедлок в ASP.Net, поскольку эта опция разрешает выполнение кода поле асинхронной операции в любом потоке из пула (и это реально так), но по факту, дедлок остается :(
Не думаю, что у человека знакомого (хоть немного) с функциональным программированием возникнет проблема с пониманием этого кода. На мой взгляд, такая запись куда понятнее чем куча вложенных циклов.