Aspnetcore: Automating of Server API use in Blazor clients

[conficient]

One of the things that annoyed me about writing C# on the server and Javascript/Typescript on the client was how much plumbing you had to do to transfer data between the the two.

You create a strongly typed WebAPI in C# on the server, then have to reconstruct this on the client in TypeScript and reference the API using strings for URLs etc.

Things are a lot better in Blazor where we can call a Web API and transform back into strongly-typed C#, but perhaps there is a 'next level' where we can create an interface object to the API that can be consumed in Blazor.

For example the sample app gets the Weather Forecasts using

        forecasts = await Http.GetJsonAsync<WeatherForecast[]>("api/SampleData/WeatherForecasts");

We still have a magic string here, which would break if the URL changes, and if we had parameters would be more complicated to put together.

If the server API code could generate something the client could consume, perhaps we could in future have something like this:

        forecasts = await BlazorApp.Server.API.SampleData.GetWeatherForecasts();

This is a similar concept to the webservices that asp.net used to generate for SilverLight to consume.

This is just floating an idea for future, so please close as needed

[RyoukoKonpaku]

I think that's in plan for ASP.NET Core as you can see on it's road map for 2.2 here aspnet core 2.2 roadmap.. Particularly on the API client generation (C# & TypeScript) section.

[conficient]

Thanks for the pointer to that. If any Swagger compliant API can be used via this (not just ones we generate) that makes a lot of sense. Perhaps we need a future check that Blazor is able to consume the generated code.

[Beffyman]

@conficient
(shameless self promotion)
It is still in development and needs better documentation, but you can try and use this:
https://github.com/Beffyman/AspNetCore.Client
It generates c# clients from the c# server controllers.
One of the reasons I made it is because I hate hard coding routes/using HttpClient directly.

[danroth27]

@RyoukoKonpaku Thanks for answering! Client code generation is in fact planned for 2.2 and will be compatible with Blazor.

[dazinator]

@danroth27 can we now generate clients from swagger spec's to use in blazor apps? Or is this not available yet? (I'm developing in .net core 3 preview 5)

[danroth27]

@dazinator The client code generation work didn't make it for 2.2. We are still working on it for 3.0. Hopefully it will make it for this release. You can try out using a code generation tool like NSwag and see if it works today. If you do try out NSwag let us know how it goes!

[dazinator]

@danroth27 I gave NSwag a go.
Main issue I found was the generated C# client has a few methods that depend on Newtonsoft serialiser.
I've raised this issue: https://github.com/RicoSuter/NSwag/issues/2237 to see if they will consider adding support for the json serialiser that blazor provides instead.
The client does some serialisation and deserialisation from streams though (as newtonsoft can do that) so some of the serialisation methods would have to change when using blazor's serialiser to convert streams to strings first. Not sure how great that is from a perf perspective. Maybe it's best to wait to see if the json serialiser in blazor evolves and stabilises a bit more first before doing any work in nswag to support it.

[danroth27]

Main issue I found was the generated C# client has a few methods that depend on Newtonsoft serialiser.

@dazinator Were you not able to get Newtonsoft.Json to work in client-side Blazor? If it doesn't work it's probably a bug that should be reported to https://github.com/mono/mono. You can try to disable the IL linker and see if that works around the issue.

The client does some serialisation and deserialisation from streams though (as newtonsoft can do that) so some of the serialisation methods would have to change when using blazor's serialiser to convert streams to strings first.

Yeah, that does seem like an issue that would need to be fixed in NSwag.

Not sure how great that is from a perf perspective. Maybe it's best to wait to see if the json serialiser in blazor evolves and stabilises a bit more first before doing any work in nswag to support it.

We are in the process of moving away from Newtonsoft.Json in .NET Core 3.0 all up and switching to the new System.Text.Json serializer. That's the one we'd like to standardize on.

[dazinator]

We are in the process of moving away from Newtonsoft.Json in .NET Core 3.0 all up and switching to the new System.Text.Json serializer. That's the one we'd like to standardize on

Ok. Will wait for that. I'd love to see that the file size of a blazor client side app will be smaller than using newtonsoft as a result! (fingers crossed).