Questions about Swagger compatibility and implications.

[vmadman]

I found this project during my initial research on practical Serverless implementation and was wondering if any thought about compatibility with Swagger and Swagger specifications has went into it, or if the author is planning on implementing anything of that nature in the future.

Specifically:

• Is it possible to pull or push model information to and from a Swagger specification file?
• Has this project been tested, to any degree, with the Swagger export plugin for Serverless?
• If so, is it known whether or not the two plugins are mutually exclusive?

I would not mind bringing myself and my team to the effort, but I wouldn't want to do that if we're going to be way-off-track from the plugin's core ideals and objectives.

Thanks,

[vmadman]

fyi, I asked the author of the serverless-plugin-swagger-export module/plugin similar questions, here:
kennu/serverless-plugin-swagger-export#1

[HyperBrain]

Thanks for the comments. Currently the plugins are distinct. The purpose of this plugin is to be able to define and upload model definitions along and integrated with the function definitions in an easy way, what it currently not supported by Serverless at all.
As long as models are not integrated into Serverless core it would be hard for the export plugin to use the model definitions.
What I could think of, would be a definitions export command for the models plugin that would export a definitions.yaml that contains all the model definitions in a Swagger compatible #/definitions namespace including transformed local JSON references, but only as export functionality. The exported file then could be just ref'd from a Swagger API definition.
The plugin is designed to work the standard Serverless way, so that s-function.json contains the endpoint definitions and every function is the owner of its endpoints (and also its models). Completely using a separate Swagger API definition would remove this ownership and coupling of function and endpoint deployment.
IMHO the first step more towards a Swagger integration than a Swagger export functionality would be to integrate this plugin into Serverless core. As soon as there is model support in there, the export plugin could just make use of the models. Then the export functionality would be where it logically belongs - in the Swagger export plugin.

[HyperBrain]

After deeper analysis I think the cleanest solution, that would solve the problems at the right places would be:
(1) Integrate the models plugin into Serverless core, so that Serverless has model support.
(2) Make use of the models in the swagger-export plugin (now it should have access to the model definitions)
I will discuss that with the Serverless team and the export-plugin owner.

@eahefnawy @ac360 @kennu What do you think?

[kennu]

It sounds good. In my projects, the master source of data models has often been e.g. Sequelize models. It would be nice to either generate API GW models from them, or the other way round, but I don't know if it's really feasible.

[HyperBrain]

When integrating into core, I would add a S.Project.getModels() and S.Models.addModel(), S.Models.removeModel() and S.Models.setModel() method that your plugin can use to retrieve or store models. Then the function deploy would use them as is with the current models plugin and the export plugin can just grab them and export them in any format.

[vmadman]

Oh, wow, a more involved response than I could have hoped for. Thank you both for digging into this with me.

I may be trying to hard to retrofit components from my previous experiences onto Serverless, I cannot be sure; it is very difficult (for me) to make good decisions while being so new to a new framework. Perhaps I should abandon my ambitions of holding onto Swagger, or maybe its just something Serverless is missing and I should be part of the effort to bring it in.

We're looking to migrate a massive application (~300 tables/models) into Lambda, but as 20-50 microservices. Mainly I am struggling to understand what a Serverless workflow would look like in such an effort.

I will keep digging, but appreciate your insight.

Thanks again,