Discussion about this post

User's avatar
Matthew Poer's avatar

Going to cause a lot of pain for developers. There's already a SugarHttpClient or some such but it had a lot of limitations, too. This solidifies my conclusion that all integrations of a certain size should just be handled in a middleware, either some off-the-shelf ETL or a fully bespoke microservice, the latter being my preference. No rules, just treat Sugar and other systems as untrustworthy targets and build in proper error handling, retries, credential handling, etc. Not always an option, but when it is it's a winner.

Expand full comment
John Boyes's avatar

This is bad. It means that I cannot update any existing packages using curl without rewriting those packages. Clients are not going to like that.

Deprecations need to be sent out well ahead of time so it can be communicated to the client and they can be asked how they would like to handle it. Maybe this one was, but we need a more direct communication path rather than the SugarCRM log file like was done with the recently deprecated "link_file".

Expand full comment
1 more comment...

No posts