Niche extractors (plugin strategy)
Closed this issue · 5 comments
I've been working on an Extractor class for Google Analytics. It is all set to the extent that it works fine. I have not been able to think of a way to unit test it meaningfully, but that is all that remains for work to be done.
Initially I had thought that it made sense to contribute here as a new Extractor. But on reflection, I'm not so sure.
It would add a limited-use dependency on google/apiclient that all users would incur, even though relatively few are likely to use it.
I am thinking a separate repo for limited use plugins makes more sense. I wonder what other people think.
Hmm That's an interesting feature.
So if I understand you use a specific client to get your GA data? It does not have any kind of "Google standard"?
The idea of the plugin is quite interesting too. Any implementation thought?
The client is at https://github.com/kdebisschop/php-etl-google-analytics-extractor
It is not specific to my company's data, but it is a specific function that most people will not have. In contrast to JSON, for instance, which nearly every user has seen used as a data source.
My concern is that if a few years down the road we had dozens of Extractors like the GoogleAnalytics one I've written, they would all depend on recommended composer packages or they would always need to be installed leading to dependency issues and bloated deployments. Imagine if we had similar plugins for FoxMetrics, but one required Guzzle 6 and the other required Guzzle 7.
With one or two such plugins, not likely. But with dozens, nearly certain that some such dependency conflict will eventually arise.
But, in reality, as long as the Extractor conforms to the interface, it does not need to be shipped with php-etl. So implementation might be as simple as a list of known components.
In general, I think it's easier for users if standards-based components are just an integral part of this package. But I think plugins that serve a specific function might be better off in their own repositories to avoid that bloat and the possibility of conflicts.
I agree with the fact that including new code relying on too much third-party vendors is risky.
The plugin idea is hence quite interesting and simple... as far I understand it.
So let's assume I am a developer who want to develop its own module.
- I develop it and host it in his own repository.
- To use it, I simply do a composer require of my module.
That's the idea ? No specific dev on our side ?
That's the idea.
No specific dev here. Just an update of the readme to clarify that standards-based contributions are welcome, but 3rd-party vendor integrations generally should be developed and hosted externally. Possibly also some mechanism for announcing compatible extensions -- could be a curated list or could be as simple as suggesting a specific github tag and linking to a search.
Ok nice then !
Let's do something in this way 👍