Share the Shared Project.
fretje opened this issue · comments
We should find a way to actually share the shared project between blazor and the api.
There's different options:
- create an entirely separate git repo for it and share it using submodules
- simply copy over the files periodically using a script (could be combined with the script for generating the api-client)
There's probably more (please tell!), but from those 2 I think the latter will be easier to manage.
creating separate git repo would make the project setup complicated.
probably a naive proposal - but is there a way to have a *.sln that combines say wasm ui + api projects?
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 ;-)
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!
@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...
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...
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 ?