koltyakov
commented
4 years ago Let me also describe briefly how we use Go apps with a combination of SharePoint internally in the company.
Currently, it's mostly workers and queue processors. It's edge applications, which are intended for dealing within the cloud and on-premises scenarios and being mostly agnostic to the environment. Many acts as a glue connecting multiple SharePoint environments within larger business processes.
Queue processors are subscribers of messaging queues executing different heavy lifting activities with corresponding actions in SharePoint. As a simple example, ECM extensions which process documents images (recognize barcodes, split PDFs, etc.) and route produced entities. Another sample is streaming migrations from one environment to another with ETL elements. We found it's easier, for us, to do such tasks in code as an orchestration layer. Also, it's tremendously cost-efficient and in times faster than any other alternative (of course if you don't spend lots of time writing and debugging a worker).
Another type of workers, which can be named as the ever simplest scenario, is the schedule-based jobs. Once started a job uses a state dumped somewhere and executes an activity regarding the predefined business logic. This can be any timer-based actions: data preparations, synchronization, notifications, etc.
A dedicated use-case is line-of-business services. In such scenarios, a service always keeps running on the background. Service reports its heartbeat to a registry, so peer services can be managed and load-balanced (sounds like microservices, doesn't it). The service(s) maintain some complex business process activities actions and orchestration. Such usage requires specific discipline and following rules to be kept under control, though.
We also use the subject in dev pipelines. Assets upload could not be faster and simpler than in a concurrent flow. Managed concurrency and parallelism sometimes act as provisioning orchestrator making continuous delivery to multiple targets in times faster (like as a difference of an hour deployment shrink to 10 minutes deployment).
That's the major use-cases types we currently cover. Plan more, but all comes step-by-step.
tarundhillon
mavericksy
SharePoint mostly was a void in Go lands before Gosip, IMO. Of course, a DIY option was always there, but realizing that SharePoint has so many authentication ways and that SharePoint APIs have so many gotchas can be painful. It can be discouraging fighting "how to deal with the API or establish an auth" but not solving actual problems and business logic and automation. As I know some SP-nuances a bit and fond of Go I considered using them both together around a year+ ago and make it reusable and simple for others.
When somebody hears "Go+SharePoint" they ask two questions "Why?" and "How?". Fair enough. I have the answers here. Yet, the goal of the ticket is to let others say how they use or going to use the library and why. That would be great feedback and a chance to hear from you. I know that current consumption is tiny and mostly done by myself, our company pipelines and code aggregators:
But anyways there should be somebody in the wild or in the future. Your help can't be underestimated.