Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Share the Shared Project. #87

Open
fretje opened this issue Jan 17, 2022 · 7 comments
Open

Share the Shared Project. #87

fretje opened this issue Jan 17, 2022 · 7 comments

Comments

@fretje
Copy link
Contributor

fretje commented Jan 17, 2022

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.

@iammukeshm
Copy link
Member

creating separate git repo would make the project setup complicated.

@274188A
Copy link
Contributor

274188A commented Jan 25, 2022

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

@fretje
Copy link
Contributor Author

fretje commented Jan 25, 2022

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
Copy link

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
Copy link
Contributor Author

fretje commented Feb 3, 2022

@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
Copy link
Contributor Author

fretje commented Feb 6, 2022

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
Copy link
Contributor

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants