I was observing a new trend in the SharePoint Development World:
“SharePoint as a Backend!”
SharePoint as a Backend
Here, SharePoint is used as a replacement for a SQL database!
All the required tables will be created as SharePoint Lists. Any additional document storage will be managed using SharePoint libraries.
![SharePoint as Backend]()
Figure 1: SharePoint as a Backend
CRUD Code
Here the CRUD is managed using SharePoint REST CSOM code.
Filtering
You can use OData filters for performing filtering on list items.
Other advantages of using SharePoint as a backend
The following are the advantages on cost, time and effort:
- No need of a separate database.
- No need to design SQL tables.
- No need to write CRUD codes.
- No need to manage Scalability.
- No need to write Authorization code.
- No need to write Search code.
- No need to write WCF/Service code.
The advantages are gained once you have an
existing SharePoint implementation with Scalability taken care of.
Issues
Wait a second! Consider the following factors too before making a decision:
- Response Delay: The SharePoint REST API can perform a little bit slower than your WCF services. Ensure your project NFR (Non-functional Requirements) accommodate this delay.
- Skill Shortage: Developers with SharePoint REST API skills can be rare. Ensure you have an expert/trained developer.
Examples
The following are a few examples of SharePoint as a backend:
- Mobile App If you are writing a mobile application, you can quickly manage the data storage by writing REST/OData code to SharePoint using JavaScript/jQuery.
- .NET App: If you are writing an ASP.NET application that requires database tables, you can use .Net code to access the CSOM of SharePoint.
- Document Storage App: If you are writing a document management application, you need not worry about SQL Server tables and BLOB storage. You can use SharePoint REST/OData API for doing that.
Summary
SharePoint as a backend can save you a lot of time and effort. Please do your valuations appropriately.