search

amalc / rubyzoho

Abstracting Zoho’s API into a set of Ruby classes, with reflection of Zoho’s fields using a more familiar ActiveRecord lifecycle, but without ActiveRecord. Works with Rails and Devise.
MIT License
62 stars 57 forks source link

Thoughts on refactor to allow for other Zoho services #63

Open benknowles opened 7 years ago

benknowles commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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!