Seq Sink for Blazor

[zbecknell]

I've started evaluating Seq by using it for local Blazor development. I'm developing a hosted Blazor Web Assembly app, so I wanted to add logging to Seq from the client in addition to the server-side logging enabled by this sink. It turns out this is quite trivial to get set up initially, as you can see in this fork.

I added the Microsoft.AspNetCore.Blazor.HttpClient package to the project and was able to find out that as long as the setup is done in Startup.Configure() and later it works (this is a Blazor HttpClient limitation right now from what I can tell).

I wanted to bring this to your attention in case you wanted to add a new Seq Blazor sink. I'll be using this rough draft for now and testing out its limitations as I continue development but do hope to see an official version at some point that I can contribute to.

[nblumhardt]

Hi Zachary, thanks for the note and demo!

I am keen to know your thoughts on https://github.com/nblumhardt/serilog-blazor - I wanted to hook up Seq and Blazor early on, but was concerned that CORS issues, and distribution of Seq API keys, would make it tedious to post events directly from the client.

The linked repo has a client-side sink that POSTs events to your app's server-side API, and some ASP.NET Core middleware on the server side that channels these into the server's Serilog pipeline (where they can be forwarded on to Seq).

It would be interesting to hear how this matches up with the kind of app you're building; I'm still learning about this space and keen for ideas/perspectives :-)

[zbecknell]

I like what you have there actually -- it avoids CORS issues I've run into with our dev server and presumably means you even get to see the client-side logging right in the server console output during development, so that's pretty cool. I think that makes a ton of sense for the hosted Web Assembly Blazor as a smoother and less tedious version to set up. Non-hosted still could benefit from a standalone fork, however (although that's not the route we are pursuing for our project).

I'll probably spend some time tonight converting our project to use the BrowserHttp sink you've shared but in the long run, I'm sure people will want that direct client-to-Seq sink for their non-hosted scenarios.

[nblumhardt]

:+1: great, thanks for checking it out!

One thought I had, earlier on, was that if the endpointUrl is passed as, for example, https://my-seq/api/events/raw?clef&apiKey=12345, this will work with Seq today (the event format is the Serilog "compact" one, which Seq can directly ingest).

Seems like that might be one possible direction to take that would enable direct browser-to-Seq support, without adding a whole new sink that does essentially the same thing. I'd guess HTTP POST of newline-delimited JSON should be usable with some other log servers/ingesters, too.

What do you think?

[zbecknell]

That makes sense to me for a direct browser scenario, but my knowledge of the area is pretty shallow. It makes sense to create a solution that could be used across multiple log servers as well, so it seems effort would be well spent in that direction. I'm just now getting to starting the BrowserHttp route, so I'll let you know how that goes.

[nblumhardt]

I've updated the ingestion middleware and BrowserHttp sink in my example repo and pushed some (completely untested) packages: https://github.com/nblumhardt/serilog-sinks-browserhttp

Would be great to hear how this goes for you! 😎

[zbecknell]

This is working very well -- I really like everything funneling through the same sinks, so my console can look like this:

I've not encountered any issues yet. Thank you so much for putting that package out there!

[nblumhardt]

Nice console output! 😎

Thanks for the follow-up. Let's close this one for now, and keep tabs on how the whole thing pans out.