search

Vincit / objection-graphql

GraphQL schema generator for objection.js
MIT License
307 stars 34 forks source link

Is this project still maintained? #36

Closed nasushkov closed 6 years ago

nasushkov commented 6 years ago

There were some PRs in December regarding mutations and no feedback by now. I just wonder if this project is still actively maintained or I should fork it. Thanks!

koskimas commented 6 years ago

Not actively maintained, but not abandoned either. I just haven't used this library myself in a while and there doesn't seem to be that many users. It's hard to find time and motivation to develop this at the moment.

mikefowler commented 6 years ago

@nasushkov not that I can make this decision for @koskimas, but would you be interested in helping on this project as a collaborator? I think it would be more beneficial to the community if we brought on active maintainers rather than the code being forked.

nasushkov commented 6 years ago

Hi @mikefowler sure, that would be nice!

koskimas commented 6 years ago

I can transfer the ownership to someone, but then I'd probably never work on this again since there is no guarantee the future direction is something I intended for this project.

No offence to @nasushkov, I just know nothing about you or your skills in API design or maintaining an OSS project. In #31 you suggest adding an argument for the build method when everything else is configured using a builder method. Don't you think mutationType should be provided using a mutations (or similar) builder method? Also #31 has no tests.

I can transfer the ownership to you since I clearly have no time for this, but I'll wash my hands from this project.

koskimas commented 6 years ago

And that was not directed to @nasushkov. I'll wash my hands anyway if I give someone push rights, since I have no time to actively review pull requests. But it's better to have someone maintain the project than it to die out.

koskimas commented 6 years ago

Done.

nasushkov commented 6 years ago

@koskimas Thanks for the invitation and I'll check #31 for a better API consistency and will also add tests

nasushkov commented 6 years ago

Hi @koskimas. Could you also give me a permission to publish new versions of this package on npm? Right now it is locked for me. Thanks

nasushkov commented 6 years ago

Hi @koskimas. I don't want to seem intrusive, but could you, please, add me as a collaborator to npm, so I can publish the last update with mutations support, or you can do it yourself if it's not feasible.

koskimas commented 6 years ago

Done

timhuff commented 6 years ago

If you guys need help maintaining this, I'd be interested in coming on as a collaborator. I'm, likewise, a bit of an unknown but I've been utilizing my fork of the library for a while so I'm fairly familiar with the codebase. I also recently incorporated this into a project for my B2B software and that project is quickly becoming one of our central offerings. If it does well in that capacity, I'm likely to continue using it in a similarly on future projects, so I have a financial incentive to keep it in good shape. A vast majority of the code I produce is private and the public work I've done is mostly as a minor contributor for something I needed added to a library, but I'm a pretty prolific programmer and have been the lead developer of fairly large codebases for about 8 years now. I don't have much experience with maintaining open source software but I've contributed to a number of projects. Let me know if I can lend a hand.

nasushkov commented 6 years ago

Hi, @timhuff I can take a look at your PRs during this weekend. Unfortunately, I didn't have enough time for any side project during the last couple of months. I think it's a good idea to add you as a collaborator, as it will help to grow this project. The only thing is to agree on the strategic direction/roadmap for this project, which features need to be added as a core functionality and what should be implemented as an extension or at least can be replaced with a custom solution. As for me, I would prefer extendability rather than an opinionated monolithic library. Btw, I also use this in production for some of my projects. Here is my vision for the roadmap:

What do you think?

timhuff commented 6 years ago

@nasushkov I don't see anything here I disagree with.

As far as the PRs go, some of them are just "rough draft PRs" that might need testing, etc. but that I put out there as a "should I bother making this community-worthy?" (when I modify my fork, I'm only concerned about my work, so it takes me a lot longer to make a feature for public release). That said, I do feel that many of them would be a big benefit to users. Most of them are just superficial helper functions and the like. Or, for example, exposing the GraphQL types and generating their equivalent Input types so that users can consume them for mutation/subscription implementations. The most audacious of them is easily the .extendWithModelMutations one and I feel it could be made a lot friendlier with some small changes.

I'm with you on the extensibility/un-opinionated aspect of it. It seems to me that this should more or less be a toolbox of relatively disjoint tools that are easily replaceable. I tend to favor things that make you go "oh, hey, that's convenient" over things that make you go "what sorcery is this!?". And I feel that the nature of the library is well-suited for that goal.

Judging by what you've written, I think we're more or less on the same page. I think the best end-result for this / the direction I'd like to move in is for it to be a very flexible and comprehensive querying interface for objection models and to leave the mutations and subscriptions largely for the users to implement. Perhaps provide them some convenience functions and stuff like that to make creating and organizing them easier but leaving those as optional niceties rather than there needing to be a buy-in.

nasushkov commented 6 years ago

@timhuff thank you for a detailed response and it's great that you're joining