search

fullstackhero / blazor-wasm-boilerplate

Clean Architecture Boilerplate Template for .NET 6.0 Blazor WebAssembly built for FSH WebAPI with the goodness of MudBlazor Components.
https://fullstackhero.net/blazor-webassembly-boilerplate/general/getting-started/
MIT License
527 stars 324 forks source link

Share the Shared Project. #87

Open fretje opened 2 years ago

fretje commented 2 years ago

We should find a way to actually share the shared project between blazor and the api.

There's different options:

There's probably more (please tell!), but from those 2 I think the latter will be easier to manage.

iammukeshm commented 2 years ago

creating separate git repo would make the project setup complicated.

274188A commented 2 years ago

probably a naive proposal - but is there a way to have a *.sln that combines say wasm ui + api projects?

fretje commented 2 years ago

Not naive... It's probably possible... there's now even multi repo support in visual studio, which would make that even more possible, or at lease easier to set up ;-)

jiscanlon commented 2 years ago

Hey all, these projects have been interesting to me because myself and others in the company I work for are updating our internal development platforms and Blazor WASM (standalone not hosted) and a well defined Rest API that focuses on Domains is, independently, the way we chose to go so there is a lot in common. Right now, we too are copying the generated Swagger file over to our front end. One thing we are considering is using GraphQL as an orchestrator like service. So instead of tying GraphQL directly to EF as is normally done, it points to the various endpoints of the Domain focused service(s). the client needs. The great thing from the client perspective is that the client can make more independent decisions on what data is important to it and it can dictate the shape of the data being returned. I am just bringing it up here for consideration because I think if it is done correctly, it could be another good piece of the puzzle to be templated and it is a potential solution for the current issue being discussed. It also solves the Git issues involved with sharing a library across repos. I wish I had free time to work on more of these projects myself but at present I don't so I'll go back to lurking and cheering you all on from the background. Cheers all!

fretje commented 2 years ago

@jiscanlon totally agree on the GraphQL thing being something interesting to add to the template... but that would fit bitter on the actual api repo (https://github.com/fullstackhero/dotnet-webapi-boilerplate/issues)...

I don't really see how that would be a solution to this issue though, as the shared project contains mainly things like Permissions and SignalR messages... and almost nothing anymore related to the actual api...

fretje commented 2 years ago

I have created a very naive script (It's part of the Identity Cleanup PR #109), but it works on my machine...

It can work as a basis for other people to work on ;-)

Maybe pulling the changes from the actual github repo using git could work? Maybe with a parameter for the branch then...

chihabhajji commented 2 years ago

Why does the client have the compiled FSHApi.cs file in the Client.Infrastructure.ApiClient, do i need to compile using NSwag and link to the client every time I modify the API's source code ?