helidon-io / helidon

Java libraries for writing microservices
https://helidon.io
Apache License 2.0
3.5k stars 567 forks source link

client and multi-module support with starter/archetype #4911

Open arjav-desai opened 2 years ago

arjav-desai commented 2 years ago

Currently, we support generating server app only. It would be nice if we can expose an option for end user to choose, if they want to generate client/server/both.

If they choose client, then we can think of offering options as SE - Webclient MP - RestClient

If they choose both, then we will have to generate a multi-module project i.e. one for client and one for server.

trentjeff commented 2 years ago

+1

romain-grecourt commented 2 years ago

Would this be valid outside of an OpenAPI context ?

How would you fit that in the archetype input flow ?

trentjeff commented 2 years ago

For this usecase it would be outside and independent, to keep projects decoupled.

I do agree, however, that we should have a way to do this in the OpenAPI generator (i.e., "empty spec" module, build server and build client modules from spec).

romain-grecourt commented 2 years ago

Let's be clear, we are talking about a new option like the cli mockup below, right ?

Select an Application Architecture
(1) server        | Server Application
(2) client        | Client Application
(3) client-server | Client and Server Application

Disregard "Application Architecture" ; it's just there to illustrate.

How would you fit that input in the current archetype input flow ?

romain-grecourt commented 2 years ago

I meant OpenAPI context in terms of archetype input option.

I.e. Is the client / server split only something that is valid when OpenAPI is selected in the archetype ; or is this something that we want to have as a top level input. See the cli mock above.

arjav-desai commented 2 years ago

We should ask user a question if they want OpenAPI integration, but not ask to upload their spec and rather generate a default one which matches the application type that they have selected. This basically means that we will create a new OpenAPI yaml in say specs folder along with targets in pom.xml to generate server or client (or both) based on this file using our OpenAPI generators (with some default options).

We don't want to invoke those targets to create artifacts based on this OpenAPI yaml when we generate project but rather document in generated README to invoke targets as needed (or may be make them part of build phase of maven?)

So the flow would be like:

  1. Flavor: MP/SE
  2. Application Type: Quickstart, Database, Custom
  3. Application Architecture: server, client, client-server
  4. Application Design? : API-first, Code-first OR OpenAPI Integration: Yes, No
romain-grecourt commented 2 years ago

Intersecting openapi with all app types seems too challenging. Wouldn't it be easier to have openapi be another app type ?

Same thing with the architecture. What does it mean do have appType=quickstart&arch=client ?