Share how you use the library and why even Go in combination with SharePoint?

[koltyakov]

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.

[koltyakov]

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]

Mine is probably is an edge case scenario - it's more about how to play the hand you are dealt with rather than best tech solution. While working large scale organisations with very rigid IT teams, I find SharePoint is openly provisioned to teams.

I personally build apps in Angular and connect them to data stored in SharePoint to build management reporting type dashboards. This library is great for me as it allows me to setup a dev environment with the proxies point to SharePoint data and automates app deployment to SharePoint for hosting. .

[mavericksy]

I've just begun the integration precisely as @tarundhillon is doing.
SharePoint is an ingrained process at larger companies; most prefer the familiarity of MS, as well as the already well established use-cases of Excel to facilitate data and process capture.
Although any dashboard system is lacking when one has the chops to create D3 dashboards.
Even PowerBI is a dull duck.
This library makes working with SharePoint a breeze, and frankly makes my job easier in terms of data input and capture, because all that is well-done in SharePoint, and this library just makes it even more fantastic.

[koltyakov]

@mavericksy you mentioned that "even PowerBI is a dull duck". I recently shipped CloudQuery plugin for SharePoint with this library under the hood: https://github.com/koltyakov/cq-source-sharepoint. The plugin allows sync SharePoint data to almost any external target, maybe it will be also helpful for the dashboards.

[mavericksy]

@koltyakov That is a fantastic plugin :) you have made my day.

[f0oster]

I experimented with Gosip a little previously and used it to build a small internal tool to map out all the site memberships across our (very large) SPO environment of about 560k sites with great success. We use this data to detect access/sharing sprawl, and also use it to drive SP clean up for our staff offboarding processes.

Following that, I noticed that there's not really any free or open source auditing tools for SharePoint, so it got me curious enough to start tinkering with the idea of trying to build out a basic SharePoint auditing tool using Gosip as my SharePoint API client.

It's very far from being anywhere near finished but it’s been a fun to work on.

Just a disclaimer, I'm not a professional software dev, and this is easily the largest project I've undertaken, so it might be quite a confusing mess :D