Documentation needed

[csillag]

I intend to use this package, because the Meteor/Apollo documentation suggested so:

If you want to use only GraphQL in your app you can use nicolaslopezj:apollo-accounts. This package uses the Meteor Accounts methods in GraphQL, it’s compatible with the accounts you have saved in your database and you may use nicolaslopezj:apollo-accounts and Meteor’s DDP accounts at the same time.

So, my goal is to use this package as a backend for the account system, replacing the default MongoDB-based one. (I don't use MongoDB in our project at all; it's all based on PG.)

Is it feasible to use this package like that? If yes, then some more documentation would be useful.

[csillag]

A few more concrete questions:

• Does this package actually provide an alternate backend to the account system, replacing the MongoDB-based one?
  • If yes, then
  • How do I configure it?
  • Which packages do I have to remove, to get rid of the unwanted MongoDB dependence?
  • If no, then
  • What does it actually provide? (Maybe a way for the Apollo resolvers (and client) to access to user account / session data, which is still coming from the same (MongoDB-based) backend?)
  • Is there a supported way for doing so?

[nicolaslopezj]

The answer is no, it uses the same MongoDB authentication system with other transport layer.

This packages allow people to migrate to a 100% GraphQL Meteor App without change the authentication system

[ilan-schemoul]

Hmmm I've spend days for nothing with this package, I thought we could define by ourselves our resolvers so we could use whatever DB system we'd like to. IMO you should make it clear, or at least write somewhere, that this use only MongoDB. When I see apollo I think that we can define resolvers AND schema not that this package is only to define schemas for account with GraphQL.

[rodcisal]

@NitroBAY the package itself is named METEOR apollo accounts which use by default MongoDB. Meteor is and it's been always tightly coupled to MongoDB. IMO you should read more carefully next time. I've been using this package just fine.

[jshimko]

@NitroBAY The first 2 sentences of this project's README...

An implementation of Meteor Accounts only in GraphQL with Apollo

This package uses the Meteor Accounts methods in GraphQL, it's compatible with the accounts you have saved in your database and you may use apollo-accounts and Meteor's DPP accounts at the same time.

It doesn't directly say it, but nothing about that description implies to me that this project converts Meteor accounts to use any database that you want. And nowhere does it say "define your own resolvers". To me, that description says: "use the Meteor accounts API with GraphQL mutations instead of Meteor methods over DDP"

More importantly, if you were willing to write all of your own custom resolvers anyway, what would this project even provide you? A schema definition? That's hardly a time saver and debatably useful. If you're willing to write all of the mutations, why don't you just do that? That's about 99% of the work anyway.

I apologize for sounding a little harsh here, but your comment comes across like you think your wasted time is the fault of someone who wrote this code (someone who happens to not be on your payroll and doesn't owe you anything). A more constructive/respectful way to say the same thing might have been "I discovered this project and thought it did X, but it looks like I misinterpreted it. Perhaps you should consider updating the docs with X. Thanks for sharing the free code!".

[ilan-schemoul]

Sorry if I was unnecessarily aggressive then. Yet I'm new to Apollo and was willing to learn it by creating a project where I need account so I didn't know a lot of things when I first started to use this package. Then what I thought this package was for is : 1) Bind all internal Meteor methods to resolvers for backward compatibility. 2) Use DDP instead of HTTP. 3) Compatibility with old data could have meant that schemas would have been defined to fit the old ones so one could use MongoDB as resolvers => migrate datas while keeping the schemas =>eventually making the schema evolve by overwriting the schemas of this package.

It may seems stupid or whatever but I was used to Meteor account system and not used to apollo and the points I described above used to seem logical enough, in my mind, for this packages to exist. Finally I'm surprised that 2 comments are written in an issue that's been created months ago, and hasn't been active since then before my comment, only 6 and 7 hours after mine just to write how offensive my comment is but my issue #61 hasn't received help for the 5 days it was opened even though it was on the top of all other issues for the most of the time it was still opened. (yes now I know the answer it was a very very stupid reason, maybe am I stupid ?). EDIT : not to say that with the creator of this package having upvoted your comment that makes 3 people participating to this thread to voice how I triggered them but real issues don't receive support.

Anyway don't be angry at me because I'm voicing my opinion. Thanks for your package, love to all of you and to the great open source community, probably the most incredible and productive on the Internet.