Add ability/config to generate Service classes as interfaces

[crizo23]

First off, let me say how great this library is. We've heavily researched/implemented similar libraries such as swagger-to-ts and dtsgenerator. There are features in this library that would justify a switch.

Our use case is a bit different though; we're writing server side endpoints that auto-wire these controller/service classes automatically in a KOA framework. From the server-side perspective, I can extend the Service classes generated and write my own implementation, but what would be fantastic is if there was a config option to make these Service classes interfaces instead which defined the operation methods (from the spec). Then, I simply implement the generated Service class and I'm good to go. Other than that, we can use all other features of this library.

[ferdikoomen]

@crizo23 i'm not following you :-) You want to make the service class interface and implement the service implementation yourself? You can use --exportServices false and just write your own? That is the best i can offer you for now.

[crizo23]

Yes, exactly, I'd like the config option to do the implementation myself. We have an OAS framework that uses koa-oas3 to wire up routes per OAS operation endpoint.

For example, consider the ComplexTypes operationId with tag Complex in your test spec. Your library would create a Service that uses the OAS tags, so perhaps ComplexService with a method called ComplexTypes.

Today, we have custom code that extends Classes/methods based on OAS operations/tags. If the Service you created could be an interface, our custom code would extend it. In the end, we're generating lots of code from an OAS spec. As developer creating a service that backs an OAS spec all I do is extend the Service and write the business logic. I hope this explanation helps.

I think providing a new --exportServiceInterface might open up your library to new use cases, and not just client side.

I'd like to help contribute if I get some time.

[ferdikoomen]

@crizo23 thanks, i think i got the general idea. So instead of exporting this:

export class SimpleService {

    public static async getCallWithoutParametersAndResponse(): Promise<void> {
        const result = await __request({
            method: 'GET',
            path: `/api/v${OpenAPI.VERSION}/simple`,
        });
        return result.body;
    }

    // etc, etc.

}

You would just like an interface like:

export interface SimpleService {

    public static async getCallWithoutParametersAndResponse(): Promise<void>;

    // etc, etc.
}

And we can export that using --exportServiceInterface, correct?

[crizo23]

@ferdikoomen yes, you have it exactly right. Thanks for considering!

[ruiaraujo012]

Any updates on this?

For now, I have forked this repo and I changed the template for the services. It looks like this:

{{>header}}

{{#if imports}}
{{#each imports}}
import type { {{{this}}} } from '../models/{{{this}}}';
{{/each}}

{{/if}}
import type { CancelablePromise } from '../core/CancelablePromise';

export interface {{{name}}}{{{@root.postfix}}} {
	{{#each operations}}
	/**
	{{#if deprecated}}
	 * @deprecated
	{{/if}}
	{{#if summary}}
	 * {{{escapeComment summary}}}
	{{/if}}
	{{#if description}}
	 * {{{escapeComment description}}}
	{{/if}}
	{{#unless @root.useOptions}}
	{{#if parameters}}
	{{#each parameters}}
	 * @param {{{name}}} {{#if description}}{{{escapeComment description}}}{{/if}}
	{{/each}}
	{{/if}}
	{{/unless}}
	{{#each results}}
	 * @returns {{{type}}} {{#if description}}{{{escapeComment description}}}{{/if}}
	{{/each}}
	 * @throws ApiError
	 */
	{{{name}}}({{>parameters}}): CancelablePromise<{{>result}}> 

	{{/each}}
}

Since I only need node, I removed all other options for clients like angular.