3

I'm working with Swagger to generate the API of my application. Swagger is an API specification language that can be used by a code generator to generate code stubs for your application. Obviously you have to complete these stubs with some business/controller logic.

Given that the code generation is an iterative process as new services are added or there are changes in parameters does anyone have any best practices for working with this code. An obvious idea is to externalize all the user written code and just add a method call to this logic but are there other ways of handling this? The target system is Java/Spring.

5
  • 3
    What happens if you re-run the code generator after you have filled out some of the stubs from the previous run? Commented Nov 8, 2016 at 11:22
  • 2
    The possible ways of handling this depend on the gory details of the specific code generator. If that is what you are after, you will probably get better answers at Stackoverflow.
    – Doc Brown
    Commented Nov 8, 2016 at 11:43
  • I thought about posting on Stackoverflow but they don't always like these more generic type questions. Basically if I rerun the code generator it regenerates the stubs and I then have to reintegrate this with existing code. I'll probably cross post to Stackoverflow as you suggest though. Commented Nov 8, 2016 at 12:56
  • 1
    @DavidGeorge: of course, when asking on Stack Overflow, you should tailor your question specificially to the Swagger code generation features.
    – Doc Brown
    Commented Nov 8, 2016 at 14:05
  • @DocBrown Yes you are right and I will bear that in mind Commented Nov 8, 2016 at 14:10

1 Answer 1

2

As far as I know, the solution you describe is a very common pattern. It works essentially because OOP languages have mechanisms for separating the implementation from an abstraction of this implementation, which is exactly the problem you are facing.

So typically, with Java, interfaces are generated and developers manually creates classes that implement these interfaces, in such a way that, when the code is automatically generated again, and as long as the interfaces has not been modified, it can exploit the classes without any extra manual changes.

In particular, this is how Yakindu proceeds for generating applications from state charts. The fact that Yakindu relies on interfaces it generates (and therefore controls) greatly facilitates the diagram/code base (co)evolution.

1
  • Yes I'm kind of thinking along your lines now. Although the Swagger editor generates both interfaces and stubs I think the stubs should be used as a starting point only - we'll assume the API is more or less done at this stage. Then if regenerating just update the interfaces and other boiler plate and fix any API changes if they occur. In other words rather than merging any user written code into the generated code take the other direction. I'm going to take a look at Yakindu and then revisit this question. Commented Nov 9, 2016 at 10:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.