Why not a flask plugin

[rchacon1]

Does the work being done to decouple connexion from flask mean we will use it just like any other flask plugin?

If connexion is still presented to the user as its own framework instead of a plugin then I'm afraid it won't be immediately clear that flask's docs, testing tools and other plugins are still relevant.

I wrote a quick POC to demostrate - master...rchacon1:convert-to-plugin

[vimalloc]

I too would like to see this. For one thing, it just feels more proper. I still need access to the underlying flask app for other extensions, and grabbing it out of connexion then using it just like a normal flask app feels strange. Secondly, there have a been a few times when I needed to actually subclass the flask app I was using (in order to tweak logging behaviors), and that would be easier to do if this worked more like a flask plugin.

That said, this app has been wonderful to use! Many thanks to the authors who created this! <3

[nmusatti]

I'd say it's a question of which is the framework and which is the plugin. Is Connexion to be seen as an add-on for Flask, or rather Flask as one of possibly many engines for Connexion? In an API first mindset maybe the latter makes more sense.

[rafaelcaricio]

There is a current effort moving towards the direction of Flask being one of possible engines of Connexion. You can follow the progress by following the development of #380.

[rchacon1]

Why would one ever choose a flask engine over a django engine or vice versa?

[rafaelcaricio]

@rchacon1 This question is completely off-topic, please follow up this discussion at https://www.reddit.com/r/Python/comments/560gov/flask_or_django/?st=j0i5u0vp&sh=7bccdfdd.

[rchacon1]

I was hoping to understand why you think having the ability to swap flask with some other WSGI framework is worthwhile. To me it only makes sense if you already have a flask or django (just using it as an example) app or you need some specific functionality from either one of those frameworks. But if its just an engine why do you care?

[rafaelcaricio]

You might have more experience with framework X and would like to use Connexion because your development cycle do API design first using OpenAPI specification. Another potential usage can be in existing applications, as you mentioned, to migrate to an OpenAPI specification based development.

[rchacon1]

I think it is easier to utilize your experience with framework X if Connexion were a plugin for framework X.

Consider a developer who has experience with flask and the flask-sqlalchemy plugin. Unless he looks at the Connexion source code he may have a hard time figuring out how to use Connexion with flask-sqlalchemy or may not even know its possible.

We may disagree on whether Connexion should be a flask plugin but I hope we agree that Connexion should play nice with all the flask plugins out there.

[rafaelcaricio]

I am not opposed to having an argument to connexion.App(flask_app=my_own_app, ...) if that is what you are asking.

I agree that Connexion should play nice with most Flask plugins indeed.

My suggestion is that we could make the Connexion code not tied to Flask by providing an API (code) where we can call/use different frameworks engines.

I am not really concerned on how we will call Connexion: framework, plugin, middleware or library. I think the features we find here could be ported to be used in conjunction with frameworks X, Y, Z.

[rchacon1]

I think it is possible for Connexion to integrate with many frameworks but also following this pattern: connexion.App(flask_app=my_own_app, ...).

swagger-node take this approach. It supports API first design and integrates with many node frameworks including Express, Hapi, Restify, and Sails but it doesn't hide which framework you are using.

If you use the swagger cli to generate a project it generates the following. When prompted which framework I wanted to use I chose express:

'use strict';

var SwaggerExpress = require('swagger-express-mw');
var app = require('express')();
module.exports = app; // for testing

var config = {
  appRoot: __dirname // required config
};

SwaggerExpress.create(config, function(err, swaggerExpress) {
  if (err) { throw err; }

  // install middleware
  swaggerExpress.register(app);

  var port = process.env.PORT || 10010;
  app.listen(port);

  if (swaggerExpress.runner.swagger.paths['/hello']) {
    console.log('try this:\ncurl http://127.0.0.1:' + port + '/hello?name=Scott');
  }
});

Notice how the express app object is readily available to me because it is passed into SwaggerExpress.

In the case of Connexion, if I pass in the flask app to the Connexion initializer I have the flask object readily available to me so I know how to use other flask extensions (I was previously calling these plugins) - http://flask.pocoo.org/extensions/

[jaitaiwan]

In the case of an extension, it would probably be better off to implement connexion as a wsgi middleware. That way you can do the following and have a theoretically unlimited number of middlewares:

app = Flask(__name__)
app.wsgi_app = ExampleMiddleware(app.wsgi_app)
app.wsgi_app = connexion.App(app.wsgi_app)

app.run()