Howdy. In Version 1, I was able to embed/integrate speckle to work smoothly with my .net applications including identity/sso, giving it a clean product UX flow and “white label” capabilities.
Now with V2 and the new dashboard/workspaces features, the dev documentation on these integration aspects is either very thin or not intended. Can you provide us with some strategic guidance from speckle here so we can plan/evolve our own development strategies.
Where do I find the integration capabilities (with .net at best, or py) of the dashboard and workspaces etc.? It can be a separate app/tab, but I still need to integrate, interact, and “drive” it from my application via API.
If these capabilities are intended and just not yet well documented, so far so good. No problem there, but a confirmation and any pointers for devs on this would be a (highly appreciated) good idea for speckle to assure that these types of platorm developers don’t lose confidence or jump ship due to strategic uncertainty.
Thanks for reaching out! With V2, we’ve prioritised a browser-first approach, which means features like dashboards and workspaces are delivered primarily as web experiences. However, our SDKs, including the .NET (C#) and Python (specklepy) packages, remain fully open source and available in their respective repositories. You can still leverage these to interact programmatically with Speckle, automating tasks and integrating data flows as needed.
While the workspaces feature isn’t open-sourced like other parts of the platform, there are still plenty of ways to customise and extend your integrations. If you can share more about your specific use case, we’d be happy to guide you on how best to achieve it!
It may be that I have completely missed your point about what you are seeking to achieve. Feel free to correct me.
Thank you for answering. Yes, our use-case is conceptually simple: I want to provide services that leverage speckle, but are not limited to or by speckle: speckle as a service/component. To achieve this, there must be integration/interoperability features available. For example, my customers need a single signon, versus separate identity worlds, so I can send them to the worksplace “already logged in” as part of our service and populated/configured automatically by us in the context of our overall usage of specke as a service (Saas :-)) Compare it to something like PowerBI-analyses, or Azure OpenAI, which are huge services that let us (want us) to embed them – including the exposure of their UI-pages – in larger contexts. I don’t see this type of scenario capability documented for the new workspace. However, maybe I am missing something, thus this post. Thanks again!
This is sounds like a very interesting use-case, and I’d like to understand it better: are you planning to self host Speckle or to use our SaaS instance? Are you planning to provide your customers with access to a single Workspace or to multiple ones?
Thanks! Yes, interesting, and the direction many SaaS are going: become part of the ecosystem instead of demanding to monopolize it. With available identity mgmt and api technologies, this is no longer a pipe-dream, and such an open ecosystem is very different (does not compete with or require) from open source. Monopolizing the ecosystem puts barriers up for everybody. The clear boundary conditions (not walls) to your ecosystem is your API which could be OpenAPI or gRPC (faster) etc. One good example of such an ecosystem is GitHub - antoinedeschenes/chargebee-saml: How-to use Chargebee SSO with Azure AD …
To answer your question: SaaS instance for sure. We haven’t had our own servers since 2009, mostly on Azure now. Since the users would be coming in with a clear identity, their access to workspaces should work transparently for you: the identity is still unique for you, the identity provider (IP) is just not Speckle’s in this case, it is another trusted IP (via OpenIdConnect, for example).
In this scenario, it would mean that I can enable SSO to an (e.g. Azure) IdentityManager/ Directory using OpenIdConnect or SAML (established standard, straight forward) or a token-based handshake and let my users SSO-login from my IdentityManager. This would enable me to then CRUD a workspace for this user(s) and deal with with the group memberships (etc.) via the API since I know who is interacting (via my IdenityManagment). As such, your Workspace is still in center stage in a tab, or embedded in a page, but we, and the user, are still in the context of the bigger ecosystem, not just Speckle’s ecosystem. Our application can still push (and pull) user-relevant aspects to the Speckle Workspace via the API and make an overall workflow accross diverse SaaS/tooling easier for the user.
This type of scenario applies universally, of course, not just to our usage. Before I go into too much detail here, take a look at how some other SaaS do it perhaps. Speckle already handles similar aspects with its connectors.
Thanks. Great. OK, so “going” tells me that it is not there yet. Correct. When it is available, I can start testing/using. Please inform of examples (c# or py) or swagger/openapi or documents telling me how to use those.
Thanks again!
I think we’re just 1 week away! In the meantime, you can already start to test our APIs. Workspaces don’t really affect how you interact with projects/models/versions/objects: