Info and roadmap about this project

[marconucara]

Hello, I'm very happy to see this project, I will need something similar soon.

I think that a classic usage, documented in the readme, should be more similar to what we see in other existing datasources, where the user extends the datasource class to map his own API (https://www.apollographql.com/docs/apollo-server/data/data-sources/). Apollo datasource rest is even implemented as an abstract class to force you to do this, what do you think?

if you like to follow this path you might even have a more generic and caller-independent TTL configuration, just like in apollo datasource rest.

I also have some doubts about the forced inclusion of bunyan as logger, you shouldn't leave it free to those who use it? But on this I am very inexperienced and just curious about your choice.

Finally, I would be curious to know if you have other changes in mind to improve this project.

Thanks

[perrygeorget]

Hi I just saw your issue. Sorry for taking so long.

You feedback is awesome and much appreciated.

• Documentation: I am happy to make those changes to get it more similar.
• Abstract Class for AWSLambdaDataSource: Not a bad idea at all either.
• caller-independent TTL configuration: I will look into it.
• Bunyan as a logger: Yes, I agree too. I will see how I can make it pluggable in an elegant and standard way

At the moment I don't have any other changes in mind, but I am open to ideas and will give it thought.

I will be working on this issue.

Thank you.

[perrygeorget]

Also, pull requests submissions are always welcome.

[perrygeorget]

Replaced bunyan with console-log-level.