I’m a big fan of applying the single page application (SPA) to SharePoint applications as well as using just plan old client-side solutions. These solutions are written entirely in JavaScript and run within the context of your browser. While there are plenty of advantages to this approach, there are clearly a few things that you could consider negatives.
One aspect of client-side solutions is the fact that all your business logic is technically unsecure and open to anyone to look at. A savvy user can simply view-source on the page and see your code! Maybe you don’t want to share that specific business process or where you are getting the data from.
Another downside is what happens when you want to execute some long-running process, either one that literally takes a long time to execute or one that requires some external input.
Are you looking to quickly get up to speed on workflows in SharePoint 2013? Later in January I’m presenting a 2-day seminar that’s available in person as well as live, online, on workflows with Critical Path Training: Office 365 & SharePoint Deep Dive into Developing Custom Workflows!
In these two cases, including a custom workflow within your application and using the SharePoint 2013 CSOM to communicate with the workflow is just what the doctor ordered! In the first case, the business logic can be expressed in a declarative form with workflow activities or they can call some external custom web service that you’ve written. In the second case, you can have your workflow start a workflow or communicate with it while the workflow is running.
Let’s say you want to have your application start a workflow. The easiest way to see how to do this is to create a custom initiation form for your workflow & examine the code that’s stubbed out… it does everything you need to start a workflow from JavaScript… if you aren’t familiar with creating forms you can see my post about it here: Creating Custom Forms for SharePoint 2013 Workflows.