Merge clients sdks

[christinaausley]

Description

Related to https://docs.google.com/document/d/1_iWR1nzSiTZYK2K59YUDz-kLboQMGSuZiej82Ha74XY/edit?disco=AAABXuNNRhk.

Combines Clients and SDKs in sidebar.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support.
• This is already available but undocumented and should be released within a week.
• This on a specific schedule and the assignee will coordinate a release with the DevEx team. (apply hold label or convert to draft PR)
• This is part of a scheduled alpha or minor. (apply alpha or minor label)
• There is no urgency with this change and can be released at any time.

PR Checklist

• My changes are for an already released minor and are in /versioned_docs directory.
• My changes are for the next minor and are in /docs directory (aka /next/).

• My changes require an Engineering review, and I've assigned the Engineering DRI or delegate.
• My changes require a technical writer review, and I've assigned @camunda/tech-writers as a reviewer.

[christinaausley]

@aleksander-dytko @akeller I think this is also an opportunity to talk about what we want to do with community clients, but I have a few questions before I can strongly recommend one action over another:

How attached are our users to the community clients? While every user matters, if this is no longer fully supported we are almost keeping these community clients around in the sidebar as a disservice. For example, Ballerina and Delphi last had changes two years ago., EJB and Ruby almost a year ago, etc. If we do have a large number of users who still use the community clients, we could find a new placement, but I'm not sure this is the case.

If we decide to remove these, I would recommend removing them in next and current, all while adding an admonition to https://docs.camunda.io/docs/next/apis-tools/working-with-apis-tools/ noting the removal of these from the more recent versions of the Camunda documentation. If users still want access to them, they can find these listed in the older versions of the docs, knowing that eventually these versions may be archived. Alternatively, could they be moved to a community resource that is not the docs? I'm not sure. CC @xomiamoore

[xomiamoore]

@christinaausley, great questions all around.

How attached are our users to the community clients?

My understanding is they are widely used by customers, though I'm not exactly sure and I'd have to find data to support that (maybe asking our consultants?). My perception comes from knowing about support tickets and other feedback around community-supported clients.

Are you asking because of the API changes which will make the current versions incompatible? Some clients are incredibly active and will definitely be updated with the REST API, while some inactive ones probably won't. I would be happy to go through and let you know which are inactive ones, but this would be challenging to keep updated at all times, so I agree that this information shouldn't live there long-term.

Alternatively, could they be moved to a community resource that is not the docs?

I have talked previously with the Marketplace team about adding other content, much like we added process blueprints earlier this year. I think this would be the best home for them, eventually, but it's not on the roadmap currently (as far as I know). Then we'd link the relevant docs pages to the Marketplace, with the Marketplace having the up-to-date information.

My preference is to keep them listed in the docs for now, for a few reasons:

1. Discoverability is challenging in GitHub -- it's not built for discovery, and we have 250+ repos in the Community Hub to wade through
2. Kapa.ai pulls from docs, and if they were removed, I don't think the other sources would pull them up

I also think, generally, we should prioritize officially supported content and direct folks to the Community Hub (or the relevant link, if not the Community Hub) for the most updated version of all community-maintained projects. Minimizing the number of pages that Clients have in the docs is totally fine by me, it's a little bloated at the moment.

[christinaausley]

My preference is to keep them listed in the docs for now

@xomiamoore can you clarify which will work with v1 and which will work with v2 APIs, as well as which are active and/or which could likely be removed?

I also think, generally, we should prioritize officially supported content and direct folks to the Community Hub (or the relevant link, if not the Community Hub) for the most updated version of all community-maintained projects.

I can ensure any community clients we keep clearly link to the Community Hub/related link 👍

@aleksander-dytko Does this impact your opinion on where you would like to see community clients placed in the sidebar?

[akeller]

My understanding is most (if not all) community clients are Zeebe-only to address the gRPC-only API we had for Zeebe in previous versions. I would want to be super clear about this until maintainers are able to provide a client surface for all components (likely via the Camunda 8 REST API). In fact, Build your own client is really only for Zeebe too.

I would also like to see us reduce the number of individual community-supported client pages we have to a single page. @christinaausley @xomiamoore WDYT about consolidating the info down to https://docs.camunda.io/docs/next/apis-tools/community-clients/ and just point to the source code. It's easier for us to maintain, but keeps the visibility in the docs.

[christinaausley]

WDYT about consolidating the info down to https://docs.camunda.io/docs/next/apis-tools/community-clients/ and just point to the source code. It's easier for us to maintain, but keeps the visibility in the docs.

I think this is great! I can adjust in this PR.

[github-actions]

👋 🤖 🤔 Hello, @christinaausley! Did you make your changes in all the right places?

These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.6/.

• docs/apis-tools/community-clients/c-sharp.md
• docs/apis-tools/community-clients/index.md
• docs/apis-tools/community-clients/micronaut.md
• docs/apis-tools/community-clients/python.md
• docs/apis-tools/community-clients/quarkus.md
• docs/apis-tools/community-clients/ruby.md
• docs/apis-tools/community-clients/rust.md

You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines.

[christinaausley]

@akeller I've removed the community clients in next -- is this what you would like to see backported? I'm unsure about removing CLI/Go, as we have a folder of content there as opposed to just a link to the source code.

[akeller]

@christinaausley the merge looks good, but I would take it a step further so the structure looks like this:

• Clients & SDKs
  • SDKs
    • keep structure as-is
  • Clients
    • Java client
      • keep structure as-is
    • Community clients
      • Component clients
      • Zeebe clients <- @aleksander-dytko would be the best to answer if/when we can consolidate this and just link to the repos like any other community client.
      • Build your own Zeebe client <- since this is just based on the Zeebe gRPC API, although @aleksander-dytko may want to remove it entirely to focus more on the C8 REST API.

No backporting, as these changes would be for 8.7+.

[akeller]

Since @aleksander-dytko is still on FTO, I'm going to approve this. @christinaausley please sync with him if he has further changes.

[github-actions]

🧹 Preview environment for this PR has been torn down.