Creating libs/util/git that holds all the functionality of git and git provider instead of amplication-git-utils

[abrl91]

Creating libs/util/git NodeJS library that holds all the functionality of git and git provider instead of amplication-git-utils.

The amplication-git-utils package is written in NestJS for no reason:

• It doesn't have controllers/resolvers
• it doesn't use any complicated functionality in the app.module.ts
• it only has some services, types, DTOs that are exported from 'src/index.ts` file

export { GitModule } from "./git/git.module";
export { GitService } from "./git/git.service";
export { GithubService } from "./git/github.service";
export { GitServiceFactory } from "./git/git-service-factory";
export { EnumGitOrganizationType, EnumGitProvider } from "./git/git.types";
export * from "./git/dto";
export * from "./types";

I suggest creating all our git logic related in libs/util/git. This library will be written in NodeJS (and not NestJS) and expose utils functions.

• As for the provider implementation, we can hold a Map or a simple JS object that points to the relative provider set of functions.
  We get the provider from the 'args' and then can trigger the function that we need from this Map by the provider that we got.

• We that implementation each provider will be able to use it's own terminology, such as organization for GitHub and workspace for Bitbucket (the table name will remain the same, and the keys of the object should be the same)

• The functions' parameters and the returned value are different between git providers. For example, GitHub uses installationId as it uses the GitHub app, and Bitbucket only has an OAuth app for installed applications, so it's actually token and not installationId

gitProviderMap = {
  GitHub: {
   getOrganization,
   createRepository,
  },
  BitBucket: {
   getOrganization,
   created repository,
   getProject,

 }

}

[overbit]

@amplication/amplication what do you think?

[overbit]

I completely support the idea to keep the library as much framework-agnostic as possible to keep it light in dependencies.

In terms of actual design, I would recommend to keep a consistent approach (OOP) with the rest of the monorepo trying to define a common interface with all the git providers we need to support.

[abrl91]

I understand your statement, but - we also have the code-gen-types util lib that exposes functions and in general, it is written in a functional way and the plugins are consuming it from JS classes.

taking as example this function from amplication-server/src/core/git/git.provider.service.ts

  async getReposOfOrganization(
    args: RemoteGitRepositoriesWhereUniqueInput
  ): Promise<RemoteGitRepos> {
    const installationId = await this.getInstallationIdByGitOrganizationId(
      args.gitOrganizationId
    );
    return await this.gitService.getReposOfOrganization(
      args.gitProvider,
      installationId,
      args.limit,
      args.page
    );
  }

We get the git provider from the args (from the client via graphql) and we can change the above code to something like this:

  async getReposOfOrganization(
    args: RemoteGitRepositoriesWhereUniqueInput
  ): Promise<RemoteGitRepos> {
    const installationId = await this.getInstallationIdByGitOrganizationId(
      args.gitOrganizationId
    );
    return GitProviderMap[args.gitProvider].getOrganizationRepositories(arg1, arg1, arg3);
  }

[barshimi]

First of all, I think this idea is great and necessary. it always better to use vanilla over framework when we're talking about utils or functionality. I support that... I would like to offer an alternative of creating libraries inside our code and introduce a util plugins. It will allow us to expend our utilities without having a mass of code. The utils plugins will be installed and added before the regular plugins and will expose functions related to the generated code or plugins. it will be loaded by categories or dependancies to user selection or use of plugins. When I think of the DSG, I see it as a multiple small and big services that can be combine together as Lego that can produce endless options of code. This methodology can be manufactured many flavors of node.js structures and also libraries (serverless, utils etc...). So... your idea of distributed version control system (git, bitbucket etc...) can be as part of this separation and the first step of segregation the DSG

[yuval-hazaz]

@abrl91 thanks for raising this discussion.

I think we should separate the efforts into two:

1. creating a library in the correct place (or moving the current library), and using the right tech for that ( no nest).
2. Talking about the inner structure and design of the git service.

For the first one, I am in favor of doing it, but I think we should look at it separately.
For the second one, I think it should be part of the current effort you are already making.

I agree with @overbit about the interface.
This is what I have in mind:

• git.service.ts

  • createOrganization()
    • calls gitProvider.createOrganization()

• github.service.ts implements gitProvider

  • createOrganization()
    • Call GitHub API with its internal terminology ( in this case, "organization")

• bitbucket.service.ts implements gitProvider

  • createOrganization()
    • Calls BitBuacket API with its internal terminology ( in this case, "workspace")

• gitlab.service.ts implements gitProvider

  • createOrganization()
    • Calls GitLab API with its internal terminology ( in this case, "group" or "sub group" what ever we decide)

[abrl91]

Of course, we can separate it into two "unrelated" efforts, although I see it as something that can be done in one go.
As for the implementation itself - I agree and I don't have any strong opinion about the functional way that I suggested.