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.
Related
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.
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.
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
I have a requirement to deploy multiple version of the same API app where the client older application use the existing and the new clients use the new api app which is got more functionality.
Is there a way to achieve this with Azure API Apps?
I have an article that shows how to do Transparent Versioning using API Management in front of API Apps.
The basic idea is that you have a version parameter in a URL and then use the set-backend-service to change which version of the API to access.
I'm new to Azure Mobile Services so this may be a stupid question, but I like the look of working with the client SDK especially the offline sync framework. (I haven't seen any other offline client sync frameworks in c# that would work with Xamarin)
But unfortunately I am not building the API and instead I'm working against an existing web API which cannot be changed or moved to azure hosting.
Is this scenario possible and has anyone got this working? If so, are there any standards that my API would need to conform to (above a standard asp.net web api with correct http verbs)
Right now, the client SDK is hard coded to only make calls to <mobile service url>/table/, etc. The team is looking at options of letting the client SDK consume other endpoints, but that will be awhile yet.
You could possibly do this using an HttpHandler, and changing any outgoing HTTP request to another URL. (IE. look for /table/tablename and redirect it to your custom path) But that would get pretty messy at this point.
Its also possible to wrap the call to the API from the within the mobile services SDK as well. It will be cleaner than the above, with the drawback of adding another middle man. However if their shape is incompatible with that required by offline, it will be easier to tweak it into the expected format.