Roadmap for v1

[patrick91]

Hi everyone, I think it is time to start talking about a roadmap for version 1 of strawberry. I've been using the library on a few side projects and most importantly on PyCon Italia's new website. That has helped a lot in fixing bugs and making sure the API is nice and consistent. Also, we have had contributions from many different people (thank you so much!)[1].

In addition to that, we might start using Strawberry at my current job, Pollen, which means me and/or my coworkers will have time to contribute new features and fix bugs. I recently added @mtszsobczak and @msobas to the core team. Now we have 5 people being able to review and merge PRs 🎉#244, which should be enough to keep the project moving forward (the other 3 are @marcoacierno, @jaydenwindle and me).

We never really had guidelines for how this project should evolve, and now that it is becoming a bit more popular, I think it is time to discuss what we want to see in the future. I have my own ideas, but this project has always been meant to be a community project, not my own :)

I'll make another issue for v2, but I want to start a discussion to see if we all are on the same page about v1.

For me, v1 should be a focus on stability and ease of use. That means making the library production-ready and finalising the base API.

I think we are close to that, but we have one crucial thing that is missing, documentation. I've worked on the website a few months ago (PR is here:strawberry-graphql/strawberry.rocks#3), so we have that ready, but we need to start writing docs. I'll ask some friends for some help on how to structure them, the end goal is to make them as user-friendly as possible, helping people also understand GraphQL concepts along the way.

So this is the feature set I was imagining for v1:

• Flask support (we have a PR for this)
• Basic Django support (we have a Django view that can be used)
• ASGI Support
• Custom scalar support
• Query support
• Mutation support
• Named union support
• Interfaces support
• Renaming field
• Support for resolver as functions (so not just class method resolvers)
• Support for default values on fields
• MyPy support
• Async support
• Support for Pydantic?
• Dev server (I need to test this a bit more, not sure it is working well)
• Documentation
• Subscription support (this needs to be improved and more tested)
• Internal refactor

For later

• Permission support (Improve permissions support #244) <- deprecate or mark as experimental
• Pagination support (relay)

Am I missing something? There are some things we are currently working on, but not sure they should be in v1, for example supporting Django models, I think that's a great feature we should have, but I'd get to a stable release first :)
We also have PR for federation, which we might need at Pollen, that's probably going to be merged before v1, but it should not affect what v1 looks like :)

What do you all think?

[1] On that note I've been a bit slow on answering on PRs, PyCon and life are taking a lot of my time right now, but I will have more time soon :)

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[denizdogan]

Looks good, I think you should add the #175 pagination support to the list :)

[jaydenwindle]

This is great @patrick91!

I definitely agree with focusing on stability and ease-of-use for v1. I think writing comprehensive docs is the biggest lift right now. Do we have a plan for what we want to document? I've started to work on some basic docs for queries and mutations, but it would be great to have a list of all of the areas we want to cover.

The other thing I'd really like to land for v1 is full subscription support. This is something that I find is really lacking in the Python/GraphQL world right now. It would be great to have out-of-the-box subscriptions for all of the framework integrations we support too. I'm happy to take the lead on this.

[patrick91]

I definitely agree with focusing on stability and ease-of-use for v1. I think writing comprehensive docs is the biggest lift right now. Do we have a plan for what we want to document?
So in my head I'd love to have the docs as user friendly as possible, maybe even teaching users some GraphQL concepts while reading our docs.

I need a bit of time to think about this, maybe we can open an issue for docs, but I guess what I'd like to see is:

1. getting started
2. tutorial
3. query
4. mutation
5. subscription
6. integration with django/flask
7. permissions
8. tips (how to make queries fast, debug issues)
9. pagination

and more probably!

I've started to work on some basic docs for queries and mutations, but it would be great to have a list of all of the areas we want to cover.
HERO!

The other thing I'd really like to land for v1 is full subscription support. This is something that I find is really lacking in the Python/GraphQL world right now. It would be great to have out-of-the-box subscriptions for all of the framework integrations we support too. I'm happy to take the lead on this.

I'd love to have full subscription support, I have some ideas/demo in mind, but not enough time at the moment.

[cprinos]

this looks like a promising start. I would take a look at Pydantic too as you may get some ideas (or direct use) in in the way the base model classes are defined (like how FastAPI use it for REST APIs)

Here's a starter Glitch project people can use to play with strawberry -- Python GraphQl server with Strawberry

[patrick91]

@cprinos oh wow, didn't know Glitch supported python 3.7! THAT'S AWESOME! Thanks for the link!

Yes, we'll consider Pydantic support! I'll create an issue for that!

We also have a discord channel if you want to join: https://discord.gg/ZkRTEJQ

[lostb1t]

Pydantic support would be a killer feature.

[playfulpachyderm]

Any plan to have support for SQLAlchemy models?

[patrick91]

Any plan to have support for SQLAlchemy models?

Maybe, but not for v1, we did some work for pydantic which might be useful for adding support for sqlalchemy too.

With sqlalchemy you could map strawberry types to tables though: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping-with-dataclasses-and-attrs

that might be a better alternative, what do you think?

[playfulpachyderm]

Hm, this looks interesting. It might be what I was looking for-- I'll have to experiment a bit. Thank you for the tip.

[matclayton]

Would love to see some inbuilt support/best practice for Relay (relay.dev) and the node lookup + connections api. Seems like this is boiler plate which would be required for any Relay user.

[hf-krechan]

Hm, this looks interesting. It might be what I was looking for-- I'll have to experiment a bit. Thank you for the tip.

@playfulpachyderm Did you make some good experience with the "declarative mapping with dataclasses and attrs" in combination with strawberry?

[davidroeca]

Any plan to have support for SQLAlchemy models?

Maybe, but not for v1, we did some work for pydantic which might be useful for adding support for sqlalchemy too.

With sqlalchemy you could map strawberry types to tables though: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping-with-dataclasses-and-attrs

that might be a better alternative, what do you think?

Tried my hand at this as well, and came up empty handed. A more feasible approach may be the imperative alternative for dataclasses. However, my main issue is that strawberry types may contain additional information that is not relevant to the sqlalchemy types, so I would require a third intermediary class that contains the shared structure shared between strawberry and sqlalchemy. This also would require me to refactor my models which are currently written using the declarative model pattern.

The more promising lead I see here is to not require any particular pattern from the sqlalchemy models themselves and to instead just rely on the mapper inspection to generate the strawbery types, which I will look into if I have the time.

Edit: thinking more about this last approach... runtime inspection may be a stretch if a requirement is that the types are available at type checking time 🤔

[Cobular]

FWIW I would need some kind of sqlalchemy model import for me to really be able to use Strawberry, as I'd really prefer not to re-describe all my data models, so I'm throwing in a vote to prioritize that! In a lot of other ways, this seems to be a far better library than Graphene and I really hope I'll be able to use it soon

[aryaniyaps]

FWIW I would need some kind of sqlalchemy model import for me to really be able to use Strawberry, as I'd really prefer not to re-describe all my data models, so I'm throwing in a vote to prioritize that! In a lot of other ways, this seems to be a far better library than Graphene and I really hope I'll be able to use it soon

+1 . This is the one factor which makes it really hard to switch from other libraries like Graphene to SQLAlchemy.
Also, in my opinion, support for relay is another factor.

[HealYouDown]

Any plan to have support for SQLAlchemy models?

Maybe, but not for v1, we did some work for pydantic which might be useful for adding support for sqlalchemy too.
With sqlalchemy you could map strawberry types to tables though: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping-with-dataclasses-and-attrs
that might be a better alternative, what do you think?

Tried my hand at this as well, and came up empty handed. A more feasible approach may be the imperative alternative for dataclasses. However, my main issue is that strawberry types may contain additional information that is not relevant to the sqlalchemy types, so I would require a third intermediary class that contains the shared structure shared between strawberry and sqlalchemy. This also would require me to refactor my models which are currently written using the declarative model pattern.

The more promising lead I see here is to not require any particular pattern from the sqlalchemy models themselves and to instead just rely on the mapper inspection to generate the strawbery types, which I will look into if I have the time.

Edit: thinking more about this last approach... runtime inspection may be a stretch if a requirement is that the types are available at type checking time 🤔

I tinkered a little bit with runtime inspection of SQLAlchemy models to create strawberry.type classes. If you're interested, you can check it out here: https://github.com/HealYouDown/sqlalchemy-strawberry-mapper-proof-of-concept

I doubt it will be any useful, but I got kinda carried away doing it. Maybe its useful to you. 🤔

Really looking forward to strawberry and maybe sqlalchemy support in the future. Would be great to use it instead of Graphene.

[patrick91]

@HealYouDown that's pretty cool! Have you seen https://github.com/strawberry-graphql/strawberry-graphql-django?

it would be amazing to standardise on an API and implement official support for multiple ORMs.

Do you think we could do something like strawberry django for sqlalchemy? Like this:

@strawberry.sqlalchemy.type(models.Fruit)
class Fruit:
    id: auto
    name: auto

(we want to use this same approach for Pydantic too)

[HealYouDown]

I will look into it, can't promise anything though.

New to working with GraphQL in general, but would like to try working on the sqlalchemy orm implementation. Will see if I can come up with something.

[bellini666]

Hey guys,

I saw that relay support is something planned here and I have created a relay implementation that I would like to know if you would be interested as a contribution.

You might have seen that I posted on discord at django channel about this lib I wrote: https://github.com/blb-ventures/strawberry-django-plus. In it I created a generic relay implementation:

• https://github.com/blb-ventures/strawberry-django-plus/blob/master/strawberry_django_plus/relay.py

I made it really generic and no attached to django at all because, not only I would like to have it be useful to non-django related types, but also because my intention was to either contribute it back to you or create a separated project for it (strawberry-relay maybe?). It is also in a single file for that purpose.

The way I did it, you just implement the Node interface by inheriting at the type you are creating and define at least 2 specific methods, one to resolve a single node given its it, and another one to resolve a list of nodes (optionally given a list of ids or none at all, in which the implementation is supposed to return an iterator of all nodes). There are other resolvers that can be overridden by the implementer, but they have a default implementation already.

With that, one can create a connection with some_connection: Connection[NodeType] = relay.connection(). A resolver can also be passed to that (by argument or by decorating a method) which is suposed to return an interator of the NodeType, and that will be paginated by the field itself. Any arguments added to that resolver will be included together with the first, last, before and after arguments.

There's is a some_node: NodeType = relay.node() which creates a field that expects a global id and returns the node.

And lastly, there's an input mutation field that basically converts all of the arguments passed from the resolver function to an input Input that is automatically created for the mutation, and them converts them back to arguments when calling the function, so for the user it still defines the resolver the same way as a common mutation, without having to create a type for each one and specify it as the single input argument. The only thing I did not do here was to create the Payload type because I did not know how to do that the best way...

So, what do you guys think? I can also create a separated issue for the discussion of this topic or discuss it further at discord.

[patrick91]

So, what do you guys think? I can also create a separated issue for the discussion of this topic or discuss it further at discord.

Let's make a new issue with the proposal so we can keep track of it better 😊

[bellini666]

Let's make a new issue with the proposal so we can keep track of it better blush

It's done: #1573

[TimDumol]

Any plan to have support for SQLAlchemy models?

Maybe, but not for v1, we did some work for pydantic which might be useful for adding support for sqlalchemy too.
With sqlalchemy you could map strawberry types to tables though: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping-with-dataclasses-and-attrs
that might be a better alternative, what do you think?

Tried my hand at this as well, and came up empty handed. A more feasible approach may be the imperative alternative for dataclasses. However, my main issue is that strawberry types may contain additional information that is not relevant to the sqlalchemy types, so I would require a third intermediary class that contains the shared structure shared between strawberry and sqlalchemy. This also would require me to refactor my models which are currently written using the declarative model pattern.
The more promising lead I see here is to not require any particular pattern from the sqlalchemy models themselves and to instead just rely on the mapper inspection to generate the strawbery types, which I will look into if I have the time.
Edit: thinking more about this last approach... runtime inspection may be a stretch if a requirement is that the types are available at type checking time 🤔

I tinkered a little bit with runtime inspection of SQLAlchemy models to create strawberry.type classes. If you're interested, you can check it out here: https://github.com/HealYouDown/sqlalchemy-strawberry-mapper-proof-of-concept

I doubt it will be any useful, but I got kinda carried away doing it. Maybe its useful to you. 🤔

Really looking forward to strawberry and maybe sqlalchemy support in the future. Would be great to use it instead of Graphene.

We've made a sqlalchemy -> strawberry mapper based on similar principles to yours 😀 It's working great in production for us

[yoto555]

@TimDumol
Hi, I saw your basic example and I have some questions:

• does the loader query the DB automatically? if not how should I configure it?
• I missing some explanations on how to add JSON sqlalchemy type for example.
• it would be great If you can give an example for relationship fields and nested relationship fields

thanks for your work

[humphrey]

Hey, just stumbled across this thread as I was curious how getting to v1.0 was going? As a new Strawberry user, it already feels significantly more mature and polished than other projects (such as graphene-django). The documentation for the core project is amazing, so good job!

As graphene-django hasn't had an update in a couple of years, it would be great to have the confidence to spend the time porting our graphene projects over to strawberry, and I think hitting v1.0 would be a good indicator 👌

[patrick91]

Hey, just stumbled across this thread as I was curious how getting to v1.0 was going? As a new Strawberry user, it already feels significantly more mature and polished than other projects (such as graphene-django). The documentation for the core project is amazing, so good job!

As graphene-django hasn't had an update in a couple of years, it would be great to have the confidence to spend the time porting our graphene projects over to strawberry, and I think hitting v1.0 would be a good indicator 👌

Hi @humphrey! thanks for the kind words. I've been meaning to update this roadmap issue (or create a new one). At the moment we are treating the library as if it were a v1.0, expect for some small things we've been trying to deprecate features instead of removing them directly for example 😊

I'll see if I can make some time to update this issue in the month or so, but some of the things that we should do before 1 which are on top of my mind are:

1. re-start the monthly meetings, we used to have monthly meetings on discord as a way to discuss things with the community
2. review, merge or close some old PRs, there's very good PRs that have been stale for way too long
3. get a new website and improved docs, our docs are nice, but we can do much better, we don't have any API reference and some of the docs are lacking information, we haven't documented Generic types yet for example
4. Have docs for Strawberry Django
5. Finalise how create custom types (unions, scalar and so on), we have functions that create those types, but they don't work well with type checkers. I think this is the one we should do first, since it will affect long term usage.
6. Finalise the internal API
7. Remove the code duplication for the HTTP integrations

And probably other things that I can't think of at the moment

[humphrey]

Awesome! Thanks for the update :) It sounds like most of those things are internal, and won't majorly affect usage which is sweet! So I'll treat it like a 1.0.

Have docs for Strawberry Django

Yes, this was one of the big things I noticed was missing. I did dig through the source code and worked out a few things, and created my own couple of helper functions to help me tweak it to my liking (as I wanted to use Django forms for validations and cleaning up of user data).

But the core library is great, and I wouldn't necessarily not launch a v.10 without Django docs. You could always release a 1.1 with full Django support :)

[whova]

Hi Patrick @patrick91 ,

It is really exciting to know that v1.0 is coming.
Is there an estimated timeline for the v1.0 release? Our company is looking to adopt GraphQL in production, and strawberry seems like the top choice after comparing a few existing libraries. Any information on the timeline would be appreciated! Thanks a lot.

[patrick91]

Hi Patrick @patrick91 ,

It is really exciting to know that v1.0 is coming. Is there an estimated timeline for the v1.0 release? Our company is looking to adopt GraphQL in production, and strawberry seems like the top choice after comparing a few existing libraries. Any information on the timeline would be appreciated! Thanks a lot.

Hey @whova! I don't have a timeline just yet! I'll see if I can make some time to make a clear timeline during DjangoCon sprints 😊

In any case we are trying to treat v0.x as v1, trying not to have breaking changes without doing any deprecations first. Maybe I can drop some of the requirements and make the release of v1 earlier. I'll think about that in the next few weeks!

[whova]

Thanks for the info, Patrick! Appreciate it.

I registered your tutorial at DjangoCon. See you there soon!

[jkimbo]

IMO a couple of things to add to the list of things for v1:

• Extension: Use context managers for lifecycle hooks #1864
• Add support for implicit UNSET as a type annotation #872
• Guide on how to migrate from Graphene (Migration from Graphene to Strawberry #1042)
• Adding return_type to strawberry.field as an alternative to annotating the resolver
• Also improving the docs would be very helpful
• Field extensions (Custom field API discussion #2168) and the deprecation of permission classes in favour of extensions

Also I don't think the internal refactor is important for v1 and we should just focus on API changes.

[XChikuX]

Would be nice to get First Class Pydantic Support for field validations #2181 before v1
Marketing as a full pydantic supported graphql endpoint would be juicy for so many devs.

Right now, if we advertise with the experimental support. Devs would swarm in and then be dissappointed that its not first class.

[patrick91]

@XChikuX I'd say we do that for v2 😊 It's a big undertaking 😊

[cpontvieux-systra]

What is really missing to make a version 1 nowadays?

Is the first comment of this issue still up to date?

Maybe there is a roadmap elsewhere that I missed. If so, please enlight me.

[brunodantas]

What is really missing to make a version 1 nowadays?

Is the first comment of this issue still up to date?

Maybe there is a roadmap elsewhere that I missed. If so, please enlight me.

I have the same question @patrick91

[patrick91]

@brunodantas I'll make an effort to make a proper list by end of this weekend 😊

But there's a couple of things top of mind:

• Check if we can type scalars better
• Add support for using enum values as names (optionally)
• Remove deprecated things (and maybe define a deprecation policy)