-
Notifications
You must be signed in to change notification settings - Fork 828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Commercial support? #813
Comments
I'd love to support Graphene too, both with money and with my personal time, I'm not working much on Python right now, but I'm sure I will in future. @syrusakbary what do you think of a Kickstarter campaign or, maybe, a patreon? |
Hi @leebenson , @patrick91. Thanks a lot for chiming in for Commercial support, this is something I've been thinking for a while. As a way of organizing the different tiers for contributing into the project, I was thinking on doing similarly to Vue.js in patreon and Django Rest Framework
Thoughts? |
I think that's a great idea. For me personally, it's not so much about the reward scheme/publicity link-back, as it is the time investment in features (although I'm sure other/bigger companies would be interested.) If I knew that, say, 50 people paying $50/mo would yield 20 hours of dedicated focus each month and increased traction against bug reports/feature requests, I'd be very happy to contribute. It's specifically about the code, for me. I'd like to know the back-bone of my API server is being supported by someone with a commercial incentive to keep it going. |
I love these ideas. A few more things that could be accomplished with sponsorship that could increase visibility and promote graphql in python:
I'm ready and able to pitch in and make contributions to make this a reality, because I really think GraphQL in python has a ton of potential for a thriving ecosystem. |
I'm working towards what we talked here 😊 These are the most recent changes:
Would be awesome if you could visit the Patreon page, the Graphene support page and write here your feedback ...it would be highly appreciated! Once we are all happy with the model, I will start featuring it in Twitter and other media :) PS: I will update the ROADMAP with your suggestions towards specific issues / features you would like to see in the GraphQL Python community moving forward, so we make sure the funding will enable those |
Thanks @syrusakbary. I've kick-started your Patreon with $50/mo. Once I get my current project off the ground and funding is a little less tight, I'll be happy to bump this up to a higher tier. Hope you reach your goals! |
Can we help @syrusakbary drum up a bit more support? This thread has a bunch of upvotes, but no additional contributions so far. Would be awesome if we could collectively buy a realistic chunk of time to devote to smashing through Syrus's to-do list. |
It's disappointing to see that the campaign hasn't moved in nearly 3 months. Still no further activity on Patreon. This is an incredible library with a ton of promise, but without any commercial backing, I'm not sure how much we can expect to move the needle forward on issues/feature requests. |
Hmmmmm.... |
6 bucks a month... Is Graphene dead? |
@tobiasfeil no Graphene is not dead. There are still a few contributors maintaining the different projects under the graphql-python org. Unfortunately commercial support didn't pan out though. |
I love this lib - thanks so much for your hard work, @syrusakbary!
With that said, I'd happily contribute to paying for more of your time to extend Graphene, and fill in a few missing pieces that would make it more viable to use in production.
Namely:
Error catching, per Solve dependency conflict between Flake8 and Sphinx graphql-core#177, and subscribe breaking change in graphql version 3.3.0a3 graphql-core#202. System exceptions bubble up to user output by default, which a dangerous default IMO. I'd love to see a cleaner way of logging exceptions and controlling error output that could be defined in one place, rather than defensive
try/except
blocks in every mutation.Core improvements / re-factoring. Thread safety (Django relations not traversed #43), resolving promise issues (Assertion errors from promise when using graphene-django. syrusakbary/promise#57), moving to
async/await
per your comment, etc. There are a few core things that are beyond my immediate experience with how things work under the hood, that seem like they have some potential to throw weird/unexpected issues that are hard to diagnose.Documented subscription support/patterns, per Does graphene support subscription now? #781.
Docs synced with releases. There have been a few occasions where trying doc examples has thrown errors, such as Middleware example fails in doc #812 today or passing context to GraphQLView no more supported? flask-graphql#52 which I ran into a few days ago. When this happens, monkey-patched workarounds are usually suggested by the community, which makes for brittler code.
Some more tooling to provide official solutions for Offer a way to calculate and limit the total cost of a query #772, etc. Calculating the cost of queries, parsing the AST tree and preempting query joins that might be necessary, etc. Outside the purview of the core, perhaps, but necessary stuff at scale that would save devs reinventing the wheel.
Closing issues faster. This is just a general thing, but there are issues going back 2-3 years that would be good to get unstuck. Much of it might even be redundant now or have other solutions, but clearing the backlog would make a clearer case for using the lib in production, knowing those same issues are unlikely to resurface.
Obviously, your time is valuable and the fact that you've put together anything at all - let alone something as cool as Graphene - is amazing, so thank you.
But perhaps there's a way, as a community, we could buy more of your time to address some of the above? I'd happily chuck in a few bucks on the reg to keep this lib up-to-date.
The text was updated successfully, but these errors were encountered: