updating documentation

docs/source/comments.rst

@@ -55,5 +55,47 @@ The :class:`musicbrainzapi.api.lyrics.concrete_builder.LyricsConcreteBuilder` cl
 
 If other ways of filtering were to be added (as opposed to the current default of just Albums) this class would be useful in constructing our :class:`musicbrainzapi.api.lyrics.Lyrics` objects consistently.
 
+Additional functionality to the lyrics command
+-----------------------------------------------
 
+The command could be improved in a few ways:
 
+Different aggregations
+^^^^^^^^^^^^^^^^^^^^^^
+
+The ability for the user to specify something other than album or year to group by. For artists with large libraries, it might be useful to see results aggregated by other types of releases.
+
+Multiple artists
+^^^^^^^^^^^^^^^^
+
+Searching for multiple artists and comparing is certainly possible in the current iteration (click provides a nice way to accept multiple artists and then we create our ``Lyrics`` objects from these) this wasn't implemented. There are rate limiting factors which may slow down the program and increase runtime considerably.
+  
+Speed improvements
+-------------------
+
+The musicbrainz api isn't too slow, however, the lyrics.ovh api can be. 
+
+One solution would be to implement threading - as we are waiting on HTTP requests this suggests threading could be a good candidate. An alternative to threading (if we are dealing with many requests) could be asyncio. 
+
+This wasn't implemented primarily because of time - but threading could be implemented on each call we make to the API.
+
+An alternative, and I beleive an interesting solution, would be to use AWS Lambda (serverless).
+
+There is a caveat to this solution and it is cost - threading is free but adds development time and increases complexity. AWS isn't free but allows you to scale the requests out.
+
+A solution would be to use a module like `Zappa`_. I have used this module before and it is a great tool to create lambda functions quickly.
+
+If more control was needed one solution could be:
+
+- Generate UUID of the current instance
+- For each request to the API, dispatch a lambda function (using ``boto3``) which will run against the api. This function should take the UUID from before.
+- Once finished either
+
+    + Save results in DynamoDB with the UUID
+    + Send results to SQS/SNS (not desirable, the lyrics size could be large)
+
+- As soon as the lambdas have been dispatched, the script could either poll from a queue, or read the events queue of the DynamoDB to retrieve the results. Processing the lyrics could then begin.
+
+This requires the user to have an internet connection - which is a current requirement. Requests to the api could be made simultaneously - without adding the complexity that comes with threading. This would not solve any API rate limiting - we are required to provide an application user_agent to the api to identify the app.
+
+.. _Zappa: https://github.com/Miserlou/Zappa