tartiflette-starlette vs tartiflette-aiohttp

[florimondmanca]

Both tartiflette-starlette and tartiflette-aiohttp pursue the same goal: provide an HTTP transport layer for Tartiflette.

Currently, the Tartiflette docs and repo officially recommend tartiflette-aiohttp.

While I think tartiflette-aiohttp is pretty cool, I have some doubts about its potential as far as integrating into other systems. It seems to me aiohttp applications are "proprietary" and don't rely on a widely accepted standard (maybe I'm wrong, please correct me if that's the case). On the other hand, ASGI is now a standard — it's used everywhere in the Python async web ecosystem and it allows libraries to integrate with one another using a single unified language.

For this reason, I would be fine with (if not in favor of) gradually shifting to tartiflette-starlette as the official recommendation for Tartiflette-over-HTTP — once it reaches a stable enough state.

If we were to do this, I think we should reconsider the decision we took to rename it from tartiflette-asgi (see #4). IMO this name (tartiflette-asgi) better reflects why this library was built and why users would want to use it, instead of how it achieves that goal (i.e. using Starlette).

@tsunammis @abusi Happy to discuss this with you!

[tsunammis]

Hello @florimondmanca

On the other hand, ASGI is now a standard — it's used everywhere in the Python async web ecosystem and it allows libraries to integrate with one another using a single unified language.

👍 You're right, ASGI is more interoperable than aiohttp.

History

At dailymotion we use aiohttp for a while (~3 years), a majority of our Python applications are asynchronous, mostly with asyncio. When we decided to start over a new GraphQL Engine, based on our experience and legacy code, aiohttp was our defacto choice. Recently, we were confident enough with our tartiflette-aiohttp implementation that we decided to open source it. It currently runs a huge traffic load at dailymotion.

Now

The aiohttp community is quite big, with a lot of contributors, currently bigger than starlette, uvicorn... It will be great for the tartiflette community to chose between both, either tartiflette-aiohttp or tartiflette-starlette. According to me, there is no tartiflette-starlette vs tartiflette-aiohttp but rather tartiflette-starlette and tartiflette-aiohttp. There are places for both of them.

Future

Based on your contribution of tartiflette-starlette, I started to work on a Tartiflette HTTP Specification which will expose the minimum feature list needed for both startlette and aiohttp implementations to be actively supported (and featured on the website).

For instance, I will be delighted to expose an equivalent and consistent set of features on both tartiflette-aiohttp and tartiflette-starlette, for instance:

• Be able to specify a different endpoint for GraphiQL Playground and GraphQL.
• Be able to specify an advanced configuration for GraphiQL -> e.g on tartiflette-aiohttp.
• Use the same name to expose the request and application, even though they don't have the same signature. -> e.g on tartiflette-aiohttp
• Provide a simple DevExp to create easily a tartiflette HTTP instance, with small code, and an advanced way to inject a Tartiflette Engine without a tightly-coupled link between tartiflette and tartiflette-(aiohttp|starlette).

Regarding the documentation on tartiflette.io, when the tartiflette-starlette API will be stable enough, it will be interesting to feature 2 tutorials at the same level on the website: One about tartiflette-aiohttp and a second one about tartiflfette-starlette.

[florimondmanca]

Thanks for the historical point of view @tsunammis.

There are places for both of them.

Absolutely. More tools for people to choose from!

I started to work on a Tartiflette HTTP Specification which will expose the minimum feature list needed for both startlette|asgi and aiohttp implementations to be actively supported

Great idea — gives a clearer roadmap as to what should be featured to provide the Tartiflette experience for both current and future maintainers of transport-specific libraries.

When the tartiflette-starlette API will be stable enough, it will be interesting to feature 2 tutorials at the same level on the website: One about tartiflette-aiohttp and a second one about tartiflfette-startlette.

Sure! Good idea to have documentation on the Tartiflette website for both. Where should we track this so it's visible and we (I, in particular) don't forget about it?

[tsunammis]

Great idea — gives a clearer roadmap as to what should be featured to provide the Tartiflette experience for both current and future maintainers of transport-specific libraries.

I'll keep you posted ;-)

Sure! Good idea to have documentation on the Tartiflette website for both. Where should we track this so it's visible and we (I, in particular) don't forget about it?

If you are interested to work on, let me know. To build together this double documentation.

[florimondmanca]

If you are interested to work on, let me know. To build together this double documentation.

Sure! I can try and draft an equivalent of the current aiohttp-based tutorial — which would probably highlight which parts are still to be implemented here.

[tsunammis]

Sure! I can try and draft an equivalent of the current aiohttp-based tutorial — which would probably highlight which parts are still to be implemented here.

The documentation takes place in the tartiflette repository. There are explanations about "How to contribute to the documentation" on the README.

👍 To be "mergeable", I would like to provide an equivalent feature set both on tartiflette-aiohttp and tartiflette-starlette, some part are missing on tartiflette-starlette:

• Query, Mutation, Subscription WebSocket subscriptions #5
• GraphiQL with configuration like on aiohttp (endpoint, default_query , default_variables, default_headers ).
• Provide a simple code sample on top of the README, that the developers can copy/paste and run it quickly. e.g on tartiflette-aiohttp

[florimondmanca]

Hey @tsunammis, I'm taking a look at this today. In your previous comment, you wrote:

Query, Mutation, Subscription

What do you refer to with "Query" here? Users are already able to specify a Query type via the SDL string of the engine object, and use resolvers. Am I missing something?

Edit: I have the same question about mutations actually, because that seems to be a generic Tartiflette feature which is not specifically implemented in tartiflette-aiohttp.

[tsunammis]

Sorry, I think that my message wasn't clear enough.

To be consistent with tartiflette-aiohttp, tartiflette-starlette must provide a complete integration with Query, Mutation and Subscription. Currently, this project is compliant with Query and Mutation as they don't require anything to work with the transport layer.

But this is not the case for the Subscription which needs a specific integration with the transport layer to work that's why I consider that tartiflette-starlette must support these 3 operation types to be "mergeable". (FYI: subscription operation type is supported by tartiflette-aiohttp).

[florimondmanca]

Okay, so we agree that of query, mutations and subscriptions, only subscription support is missing. Thanks!

[tsunammis]

You're right 👍

[florimondmanca]

I laid the roadmap out in #20, and also opened tartiflette/tartiflette#230 for the documentation updates. I think we can close this issue now! 👍

[tsunammis]

👍