7
\$\begingroup\$

While hunting for my next zombie to take down, I encountered the following question:
Patient Appointment CSV to insert records using simple_salesforce

A question that seemed well written, almost complete, except this part:

from simple_salesforce import Salesforce

Those are not user-defined functions.

Turns out there's a Python REST API for Salesforce called simple-salesforce. Knowing we've had Salesforce questions before I thought I'd put a tag on it, but this is where it gets complicated.

Salesforce is a CRM platform. Salesforce-Apex is a programming language "that allows developers to execute flow and transaction control statements on Salesforce servers in conjunction with calls to the API". Apparently there are also a bunch of APIs in other languages that can talk to Salesforce as well, one of them being the simple-salesforce in the Code Review question.

A platform, a language and a (bunch of) API(s) all under one tag.

, and are synonyms. With as parent. And that's unfortunate, since now I can't put a Salesforce-related tag on the question while it would definitely benefit from one.

I don't think is the correct parent tag. We will get more questions like this and we haven't even talked about the Salesforce lightning framework app-builder yet, which may or may not be the new name for .

I'm looking for solutions to this (potential) mess.

\$\endgroup\$

1 Answer 1

Reset to default
4
\$\begingroup\$

(Note: Mast and I discussed this in chat this is a complete write up of my POV from this)

Salesforce

Salesforce's Developer Tools

I think that Salesforce has three major sections to their developer tools.

  1. A language - Apex [W] [S]

  2. REST APIs [S]

  3. A component framework - Lightning [W] [S]

Tagging Decisions

I do not think we should crate subtags for things like the IoT API, Aura components, etc at this time.

  1. We do not have a lot of Salesforce questions.

  2. The names I'd suggest on these tags can cause problems later on.

  3. I think by creating 9+ tags at once we'd be setting ourselves up for problems later on as I'm bound to make a mistake somewhere.

    Example: there is reference to an Apex REST API but I can't find a link that explains it.

Note: This does not mean that we cannot have these tags in the future. I am just suggesting we hold off this discussion for another day.

Tag Proposal

Generic 3rd Party Interfaces to Other APIs

For languages that are not Apex they will most likely use a library to interact with the REST APIs. The generic situation is "I am using a {library} to interface with {API} in {language}".
For example "I am using simple_salesforce to interface with Salesforce {name} REST API in Python".

At first I'd like to have kept the amount of tags to a minimum. However after short analysis I've decided that it's fine to have tags for language specific libraries.

  • "Only tag with {library} and {language}"
    If someone knowns {API} they'd need to follow lots of tags.
  • "Only tag with {API} and {language}"
    The situation will become complicated and annoying if the ecosystem grows to the point that the libraries are vastly different than the APIs.

And so I suggest tagging with all three tags. Such as .

Example Tagging

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .