Thoughts on refactor to allow for other Zoho services

[benknowles]

Hi, I'm playing around with allowing the ability to use other services besides CRM. It seems that there are several other products that use the same structure like Sheets, People, Recruit.

My strategy is to turn configure() into an OpenStruct and allow API keys, etc. to be defined for each 'service'.

RubyZoho.configure do |config|
  config.recruit.api_key = "XXXXXXXXXXXXXXX"
  config.recruit.enabled_modules = %w[Candidates Clients JobOpenings Events Interviews]
end

And then any service that is used dynamically sets up that module (RubyZoho::Crm) and its classes.

These are high-level structural changes so I don't see anything breaking, but admittedly writing tests is not my favorite thing to do.

Do you have any suggestions and/or requirements to merge this into master down the road? We could potentially make the config backwards compatible and show a deprecation warning.

[amalc]

Yeah, its something I was thinking about as well since the beginning and originally thought that perhaps separate gems would be the way to go. But I think your idea is far superior.

[amalc]

The tricky part of testing this gem is the rate limit of the API. I've tried to get Zoho to respond to give us an account to be used strictly for testing this gem, but no joy. Writing the tests for this is a real pain. Because debugging the test can easily trip the rate limit. I was up at around 95% coverage before the tests broke.

[amalc]

Being backward compatible for the config I think is important and deprecate that after sometime. Will think about testing this and take another run at Zoho to see if they can give this project an account with high limits. Or perhaps you have more pull with them?

[benknowles]

I think the problems with the rate limiting are universal. I have an enterprise-level account for one of my clients, and I got so fed up dealing with it I ended up throwing together a cron to bulk copy the data into MongoDB every hour (https://github.com/benknowles/zongo). There are certain API methods that simply stop working once you go over 3000 records in a module. Zoho support is usually of no help or they give you the run around and say it's on the TODO list.

I have a plan for the backwards compatibility, that shouldn't be a problem.

There are some minor differences between the different API endpoints, so we could have a boilerplate class that services can override. That way if someone is missing a service they can create a new file with optional fixes and submit a PR.

[amalc]

That sounds like good idea, the boilerplate class. I need to take a look at getting the tests to run properly again. Just checked out zongo! That's clever!