studio status report: 2022-10
month 10 of 2022 was about releasing AzureBlobStorageRestApiUtility and planning to release AzureKeyVaultRestApiUtility
The release of AzureBlobStorageRestApiUtility (see issue #149) establishes one of two Azure utilities that are fundamental to the “cloud strategy” of this Studio. Completion of issue #151 will release AzureKeyVaultRestApiUtility making the following the statement true:
This Studio uses REST APIs in the cloud for secrets and storage.
“How To Access Azure Key Vault Secrets Through Rest API Using Postman” by Anupam Maiti was the breakthrough message to me and my brain 🧠 that finally showed me the way to a fundamental that should have been in place years ago. I should have been demanding a RESTful approach to storage and secrets instead of getting lost in SDKs. The Core should be as primal as possible.
what month 10 looked like
Month 10 highlights:
something that can run locally and in the cloud with very little modification without using containers (or WebJobs)?
My lack of interest in containers is based on the reasonable fear that containers will be a rabbit hole 🐇🕳 —and they also feel too heavy and cumbersome for a my work (no lift-and-shifty DBMS behind micro-service(s) here). Moreover, I feel that Activity DLLs should be used in the cloud in [[Azure Functions]] for both local and cloud runs—because [[Songhay Activity]] DLLs contain stateless Activities, working on one input to produce one output. The biggest obstacle in front of this is where to store/retrieve secrets 🐇🕳.
Once the secrets challenge is met, then PowerShell can loop through things (synchronously) locally, effectively testing how Azure Functions run sequentially. Finally, Azure Function Orchestrations will be the last piece to put in place, looping through for parallel runs.
Step zero, before the secrets bit, is replacing PowerShell-based Azure Storage calls with REST calls in dedicated Activities. In summary:
- replace PowerShell-based Azure Storage calls with REST calls in dedicated Activities (a [[Songhay Dashboard]] Activity is improvisationally on the way)
- add secure secrets layer to the cloud
- replace PowerShell-based Activity-DLL calls with calls to an Activity hosted in an Azure Function
- Orchestrate Activity-DLL Azure Functions
add your own tooling to the [[.NET]] CLI
The dotnet pack command will save a NuGet package to the relative path specified below:
To install globally for the CLI, we use the following command, punctuated by the namespace, Weather.Cli, of the packaged app:
dotnet tool install --global --add-source ./nupkg weather.cli
“Lazy load assemblies in ASP.NET Core [[Blazor]] [[WebAssembly]]”
Blazor WebAssembly app startup performance can be improved by waiting to load app assemblies until the assemblies are required, which is called lazy loading.
[📖 docs ]
I assume the [[b-roll player]] will leverage lazy loading to switch among players.
some of my code is kind of famous this week
https://sergeytihon.com/2022/10/01/f-weekly-39-2022-fsharp-systemtextjson-1-0-fable-4-theta/
sketching out a development schedule (revision 26)
The schedule of the month:
- install Studio ‘floors’ in
Songhay.Player.ProgressiveAudioandSonghay.Player.YouTube☔☔ - add a GitHub Project for
Songhay.Player.ProgressiveAudio🐝✨ - change
Songhay.Player.YouTubeto support kinté space presentations 🔨 🚜✨ - replace the Angular app in
http://kintespace.com/player.htmlwith a Bolero app 🚜🔥 - generate Publication indices from LiteDB for
Songhay.Publications.KinteSpace - generate a new repo with proposed name,
Songhay.Modules.Bolero.Index✨🚧 and add a GitHub Project - switch Studio from Material Design to Bulma 💄 ➡️ 💄✨