How to Deploy Node js Rest API in SharePoint Server 2013 - node.js

I have created REST API for fetching the products details from SQL db. As of now I have only my dbconfig file where I have added the SQL database configuration. Now , I need to deploy this REST API to SharePoint.
My front end - Angular
Any steps to be done ?
In ASP.Net , we used to build the project, get the dll file & deploy that in IIS. But in node js how this can be done ?

First of all, SharePoint architecture and its environment differs entirely from Nodejs. There are many things that needs to be taken care of while deploying Nodejs application.
I assume you've developed some endpoints which you are trying to consume through SharePoint. In that case, the best solution is to create node environment in your on-premise server.
The other way could be deploy the Nodejs application on Azure. And allow access to your local environment only. This will protect your endpoints to get exposed. There are some security concerns that you may have to handle.
Much simpler approach is to deploy on Heroku and try to access from your SharePoint
https://devcenter.heroku.com/articles/deploying-nodejs

In my opinion, the simplest would be to deploy the REST API directly to IIS and consume it from there. If you want it to be more like a deliverable product, so you can still have the wsp file which can be deployed, you should create a WCF Service.
http://sharepointwiththili.blogspot.com/2016/03/create-custom-wcf-service-for.html
This can happily live in an already created solution and it can be deployed directly to SharePoint.

Related

How to publish a SAFE template application to a website/hosting service

I have made a website in the safe template using F# and I am currently attempting to publish it to a hosting service/domain.
I have already uploaded all the project files to the index_html folder using the built in FTP provided by the hosting service. And I am unsure about the next step.
Any help would be most appreciated.
This question is a little wide but as rmunn infers, it's possible your hosting service is designed for a static site.
If I'm making no sense here, I'd head to the Safe Stack docs on Github, read the pages about registering with Azure, then follow the steps to Deploy to App Service. This will give you a much better feel for the sort of hosting arrangement you'll need when deploying the app, and obviously you're not confined to using Azure in the long run. Easiest to start a new template from dotnet new SAFE --deploy azure and get the deployment process working, then retrofit it to your app afterwards I reckon.
Of course if you only need a static website and don't actually have any requirement for an API / DB etc., fable-elmish could work...

Web API & Azure Mobile App, should I keep them separated?

I'm planning a project in which I have a windows service installed in on premise machines (about one hundred of them) which should keep in sync an online azure SQL db with the on premise ones (MS access, third party). That sync happens by calling a Web API.
I then have to build a mobile app which will be used by ~3k users that will access the synced data with Azure mobile app backend.
As for now I've started building a single mobile app backend project which serves both mobile app requests, and webapi2 requests used to sync data.
Furthermore I'll need to add queue/topic section to send realtime notifications from the app to on premise services.
My concern is if is it good practice to keep both "mobile app" and webapi2 in the same project, or should I separate them.
Any suggestion will be greatly appreciated.
Many thanks in advance!
You should, separate them. Based on your description, you should use the microservices architecture, you can read more about it in the links below.
Azure specific:
https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices
https://learn.microsoft.com/en-us/azure/architecture/microservices/
In general:
https://microservices.io/patterns/microservices.html

Creating an custom API using existing API

I am trying to set up a custom API for my application. This is a corporate application that I installed in my environment. The application comes with it's own out-of-the-box REST API, but I'm looking for a way to create my own custom API leveraging the existing one. The reason I want to create a custom API is because of all the customizations that have been made to the underlying database. I'm looking at using Node.js and the Express application framework to create the custom API, but all the use cases I've seen for this are for creating new APIs from scratch. I guess my question would be, how can I integrate my existing web services API into a Node.js (Express) set up. My existing web services API runs an Apache Tomcat web service. This publishes the existing web service endpoints in a format like this:
http://://?fields=,...
I'm looking for tips, pointers or something that can point me in the right direction. If there are any alternate (better) solutions available aside from Node.js (Express) I am open to exploring that as well.

frontend and backend separation in azure

I'm developing a simple site consisting of an Angular frontend and a simple NodeJS backend. I currently see 3 ways to setup the project:
have 1 Web App to serve the static HTML and 1 Web App for the NodeJS backend
serve both REST API and static files using the same NodeJS instance
I read about virtual directories for Azure Web Apps, but wasn't able to find appropriate documentation. Is that even a viable solution?
What's the standard setup to use for Azure? Is there any in-depth documentation I missed?
I would say that this is a type of question for which it is difficult to get an answer, because someone could write an entire book on this topic and a lot of aspects are a matter of personal preferences, approaches and so on.
Before I try to attempt a first answer I would like to point out that I am not familiar with Node.js at all, but I am fairly familiar with Azure AppService and ASP.Net Core MVC.
There is no standard setup in Azure AppService (websites in this case) and in fact all the 3 options that you mentioned are valid. Based on my expperience with Azure AppService I would say that option one is suitable when you have a publicly available API. In that case you could also register your API with Azure Management API.
The second option is, in my opinion, best suitable when your frontend is the only consumer of your API.
The third option is not that common, but 100% possible. Here is a very good article on how to set virtual directories up and how to deploy an application to them using Visual Studio. I am not sure how this would be done exactly with the tooling at your disposal, but conceptually it should be possible. However, deploying NODE.js projects in virtual directories could cause some problems you should be prepared for. More information here.
I would however stick with what I said in the start: I would deploy both backend and frontend to the same web app if my Angular application is the only consumer of the API and I would deploy to 2 different web apps if my API was public.
I'm curious what other might think in this regard.

How do I setup web pages within Azure Service Fabric Stateless Web API?

I am using VS 2017 and have successfully setup to use Stateless Web API. I can see the output of the default controller when I run it.
Now, I want to create web pages within this project and use AngularJS SPA within it to access its own API.
I am unable to find any examples which clearly show how to do this. Note this is ASP.NET Web API - not ASP.NET Core.
Someone please help.
I opened a support ticket with Microsoft and this can be done with the ASP.NET Web API support in service fabric. Web pages can be added to the self-hosted web api project, but each file has to be individually configured for this project - if you have hundreds of files, it does not allow you to configure the entire folder contents for the project, because you have to mark each file to build as content. The example they sent me is an obscure article in a Microsoft blog from a Microsoft Engineer nobody has heard of before.
Not worth it. Use the ASP.NET Core support.

Resources