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

Drop rest-client template ? #113

Open
iocanel opened this issue May 26, 2024 · 3 comments
Open

Drop rest-client template ? #113

iocanel opened this issue May 26, 2024 · 3 comments

Comments

@iocanel
Copy link
Contributor

iocanel commented May 26, 2024

I think that now that we have a more concrete yet generic enough example (the chatbot) that shows how to consume an api, maybe we should drop the rest-client template.

@cmoulliard
Copy link
Collaborator

As the goal of the rest-client template is to:

  • Generate a quarkus application using the extensions
- io.quarkus:quarkus-rest-jackson
- io.quarkus:quarkus-smallrye-openapi
- io.quarkus:quarkus-smallrye-graphql
- io.quarkus:quarkus-hibernate-orm-rest-data-panache
  • Add some maven
          dependencies:
            - groupId: io.quarkiverse.openapi.generator
              artifactId: quarkus-openapi-generator
              version: 2.4.2
            - groupId: io.quarkus
              artifactId: quarkus-rest-client-jackson

but without the skeleton of an application AND using only the quarkus starters
then it don't really bring more added value

@cmoulliard
Copy link
Collaborator

cmoulliard commented May 28, 2024

I think that it is time to think about how we design a new Quarkus Application template.

Should we copy/paste an existing one and change the code with the risk that we will duplicate many common resources: Tekton, ArgoCD, Helm, etc, increase the maintenance cost when changes should be propagated to x template folders, etc

or instead

Should we try to create a generic Quarkus Application template able to deal with different examples such as ChatBot, TODO, REST server/client, etc and where the examples are handled under their specific skeleton folder but selected using an enum. Here is an example where the CI skeletons are selected using enum, etc - 

@iocanel @aureamunoz

@aureamunoz
Copy link
Collaborator

It depends on if we have deadlines that might favor a quicker solution or how often we will need to do changes on the template but in general I think the second solution is the better long-term solution despite its initial complexity. This approach makes maintenance easier because centralizes common functionality and can reduce duplication than copy/pasting and dealing with existing code.

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

No branches or pull requests

3 participants