You are viewing limited content. For full access, please sign in.

Discussion

Discussion

v11 SDK Framework, Core, CMIS or Self-hosted API?

SDK Laserfiche API Integrations Self-Hosted Version 11
Updated June 20, 2023
posted on June 20, 2023 • Show version history

Hi team,

A customer is looking to upgrade their LF install and integration code. Assuming the 10.4 APIs follow the same support life-cycle then that code will only be supported until 2026. Will there be a v11 of the SDK? It got me thinking about this and other (hypothetical customers) who might be upgrading or developing new integrations. I'd love to hear everyone's thoughts on the pros and cons.

  • If there's no plan for SDK 11, we could develop against the v11 APIs. If developers are OK playing fast and loose by not using merge modules, and don't need help or samples (because that's how we roll), we could go this route. 
  • .Net Framework 4.8 is supposed the last framework, so developing wtih .Net Core and CMIS or LF Web API might be the best approach.
  • I'm pretty sure .Net Core isn't compatible with  LF Framework Assemblies, or perhaps just Laserfiche.DocumentServices. It's been a while since I last checked. 
  • I like the idea of CMIS but was burnt by ODMA (Open Document Management Architecture) and the limitations on waiting for a consortium to decide what calls I might need. Does anyone heavily use this?
  • Which is more efficient, self-hosted Web API based integration or integrations written using .Net assemblies? How would a doc-migration (between two self-hosted, or private cloud systems) tool compare, for example? Assume perfect network conditions...
  • The above consideration will become a moot point after .Net Framework 4.8 is no longer supported by MS, of course.

 

Thoughts, comments? 

0 0
replied on June 20, 2023

Thanks for you replies guys :)

0 0
replied on June 20, 2023

Thanks for the great response Jason, you are spot on. 

Now that we provide an API for Cloud and Self-Hosted systems, we would recommend building integrations using one of those options.  Our API offers the flexibility to use any programming language in your integration and our client libraries (.NET, JavaScript, or Java) offer additional efficiencies.  Using the APIs also offer some peace of mind when considering possible migrations to Cloud, knowing that your integration will work with both Self-Hosted and Cloud APIs, as they are essentially the same.  Our goal is to provide developers with modern and approachable options when integrating with Laserfiche and we feel that a robust API delivers on that.  We will continue to listen to our Solutions Providers and integrators as we improve our API and developer ecosystem over time, so we appreciate your questions and feedback!

 

Andrew

4 0
replied on June 20, 2023

I get the impression that the goal is to (eventually) replace the SDK with the API, which makes sense considering rewriting the entire SDK and associated libraries in Core would be a significant undertaking and a mature API could fill the same role (and more).

I believe they provide NuGet packages and such to "wrap" the API functionality up so I expect that the goal would be to get the API to feature parity (and more) so it could be used in a similar way as the SDK but without the need for installing the LF libraries.

I'm noticing more products with an "SDK" that is effectively just a NuGet package wrapping up the API functionality so you don't have to code the API calls from scratch; this seems to be the common trend and it makes sense from a standardization and support perspective.

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...