Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
asgs115634yNot the first time I'm reading something similar
What makes it such a pain to work with? -
Try salesforce......................................................................................................................................................................................................
-
Honestly, every time someone says I need to interact with a service and they tell me "just use this existing client" or, worse still, especially in the case of SOAP services, "just have your IDE gen a client for you", my reaction is "FUUUUUCK THAT!" and I code up a dirt-simple HTTP client (Java for me, so almost always Apache Commons HTTPClient) and I'm done. The argument is usually "yeah, but when the service changes, you gotta re-code your client", and I'm like, "look... first... if your service changes and it breaks existing clients you've ALREADY fucked up... and second... if you DO change your service like an asshole, guess what? My client is dirt-simple code, I can change it in a few minutes... faster than it'll probably take me to integrate your disgusting client or the disgusting IDE-generated code with the rest of the project". So, yeah, basic HTTP clients for life!
-
sariel85314y@NoToJavaScript fuck Salesforce with a God damned rusty fork.
Salesforce: There is no God here
I would love to ask a Salesforce developer what in the actual fuck their management forced them to make, because it sure the fuck isn't a framework.
Don't even get me started on lightning.
😤 -
foniho304y@asgs The docs are incomplete. Parts of the docs in are Java, some in Javascript, some in Php. There are also some gaps that leave the developer to guess what should be there.
There are also multiple ways to implement OAuth in their docs, but provides no clue which part of the OAuth process they are solving. So doc A will tell you to do A, but doc B will tell you to do B instead.
Instead of all this crap, they should have just published the basic request entity in the docs from start to finish. The client libraries gives no clue what is being called either. Also, as I said about those libraries -> needlessly complex for no reason.
Related Rants
Google OAuth docs is such a pain to read... I have implemented OAuth multiple times and understand the flow. Its never been a problem, but man, their docs is such a pain to read.
Their Java client library is also painful. Its needlessly complex that I just ended up implement good old HTTP rest to handle it.
rant
google
oauth