Sealed clients

[WebDucer]

Hello.

Is there a reason, why all clients are sealed? With sealed classes it is realy hard to extend the clients with own implementations (e.g. labels of groups or pipeline).

With not sealed classed it would be fine to test the new function with extended classes and all works as expected, perhaps make an merge request with the changes to the origin client.

[nmklotas]

Hi,

Probably it would make sense for us to make them not sealed, to allow more different ways to use the clients, but then we would need to make protected/public constructors for them and library consumers would depend on clients internal dependencies, I want to keep them internal to be able change them without breaking the library compatibility.

        internal GroupsClient(
            GitLabHttpFacade httpFacade,
            GroupsQueryBuilder queryBuilder,
            ProjectsGroupQueryBuilder projectsQueryBuilder, 
            MilestonesQueryBuilder queryMilestonesBuilder)
{

to remove the dependencies from the client code, we would need some trickery to pass them for ex. into GroupsClient not using constructor dependency injection + protected methods to be to add more methods to GroupClient without knowing GitLab's logic, this would increase complexity of the library.

If you need some more methods for this library contribution to this project is an option :)

[WebDucer]

That was the intention. But normally I like to test and develop by extending the libraries. And if all looks good, I contribute the changes to the origin projects.

At least I plan to extend your great lib with the Client for pipelines.

[nmklotas]

Ok, Client for pipelines would be really useful. Not sure what you mean by class level extension though, perhaps there are some scenarios I'm not aware of you want to accomplish using the extension points?

[rgomez90]

Maybe creating interfaces for the clients would be another option.

This way a consumer can implement the given interface using the built-in client and add wished features.

This is the way octokit.net works, which is the most used lib for GitHub API in .NET.

[AndreaInglese]

I haven't deeply reviewed all the code, but maybe it would be enougth to expose the GitLabHttpFacade on the main GitlabClient class? maybe throught an interface without exposing the internal implementation class.

With that it would be very easy to manually build a http request to gitlab:

public Task<JObject> Compare(string projectId, string from , string to)
 {
	//GET /projects/:id/repository/compare?from=master&to=feature
	return _httpFacade.Get<JObject>("projects/"+ projectId + "/repository/compare?from="+ from + "&to="+ to + "");

}       

(trying to solve the same as https://github.com/nmklotas/GitLabApiClient/issues/95)

(please do not use this in production :smile:)