bolero: translate selected `Songhay.Dashboard/Client/src/app/services`

Question

bolero: translate selected `Songhay.Dashboard/Client/src/app/services`

BryanWilhite opened this issue 3 years ago · comments

The Bolero docs do not recognize the possibility of calling an API from WebAssembly [📖 docs]. They present remoting [📖 docs] exclusively. In my current state of ignorance, I assume that this preference is for the following architectural reasons:

allowing the Wasm to call any remote location from the client side can lead HTTP infrastructure change/maintenance and even secrets adding complexity and possible security flaws exposed on the client
Wasm-based HTTP infrastructure could compete architecturally/conceptually with using Wasm as a cache for remoting (via the Web Storage API [📖 MDN])

Today, I assume that designing a “rich client” with a dependency on one server is easier to maintain than a “rich client” that knows about many, many servers (with many, many possible authentication strategies).

add Songhay.Modules F# library project
translate SyndicationFeedItem[ GitHub] into Songhay.Modules
translate SyndicationFeed [ GitHub] into Songhay.Modules
complete the steps listed under 📖 https://fsbolero.io/docs/Remoting#defining-the-service
replace/translate dashboard-data.store.ts with/to DashboardServiceHandler
add IHttpClientFactory pipeline to support Bolero Service Handler(s) [📖 docs]
add Oryx https://github.com/cognitedata/oryx to consume IHttpClientFactory output
add test coverage for the above

Bryan Wilhite · Answer 1 · Wed Jan 12 2022 11:36:26 GMT+0800 (China Standard Time)

dotnet new classlib --name Songhay.Modules --framework net5.0 --language F#
dotnet sln Songhay.Dashboard.Bolero.sln add Songhay.Modules/Songhay.Modules.fsproj

dotnet new nunit --name Songhay.Modules.Tests --framework net5.0 --language F#
dotnet sln Songhay.Dashboard.Bolero.sln add Songhay.Modules.Tests/Songhay.Modules.Tests.fsproj 
dotnet add Songhay.Modules.Tests/Songhay.Modules.Tests.fsproj reference Songhay.Modules/Songhay.Modules.fsproj

Bryan Wilhite · Answer 2 · Sun Jan 23 2022 10:59:01 GMT+0800 (China Standard Time)

i have chosen Oryx https://github.com/cognitedata/oryx over FsHttp [ https://github.com/fsprojects/FsHttp ] because Oryx does not concern itself with IHttpClientFactory like FsHttp does

the answer to a question among FsHttp issues indicates a history of intentionally wrapping/hiding IHttpClientFactory which competes with the DI features of modern ASP.NET

as of this writing, Oryx and FsHttp are listed as two of the three awesome HTTP client solutions for F#