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.
Related
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...
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.
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 an MVC front end application (relatively small) with its own DAL implementation using repository pattern. I am thinking of moving the DAL in its own WebAPI project to maintain cleaner separation. The MVC app is hosted in Azure using a cloud service (web role). The WebAPI will only be used by the front end application and would not be exposed to any other external application for now, but even then i would still want it to be hosted as a separate app/web/worker role rather than keeping the DAL in same project.
Would it be a good idea to:
1) Host the WebAPI project within the same Cloud Service as a Web/Worker role or should I create a new website/cloud service for hosting it? Using the same cloud service is preferred keeping the cost factor and n/w latency issues in mind.
2) If I host in same cloud service, what is more advisable to use for web api project - web or worker role?
3) Somewhere i read that I should make use of Service Bus in Azure for interaction between MVC frontend and WebAPI backend. Is this the suggested way of doing it or is there any simpler way of getting it done?
I would suggest you to use the same cloud service. The reason being complexity and failure scenarios, when you split your app into multiple cloud services the problem comes when you are updating them service from your source control
You will need to do two deployments and make sure they are in sync etc.
I would keep the service runtime simple in one cloud service.
Again it is preference and comfort, if you really want to separate them at code level and know they will work fine. The two cloud services should be OK.
From experience, refactoring decision like these add a lot of work in the future. Positive or negative depends on your understand of the problem and the image of the bigger picture you have in your head that cannot be put on paper :).
Happy to Help, Yours Truly -CB
Exist three ways for deploy Node.js app on Windows Azure, web-role, web-site and git-azure (link). I don't know whitch is most efficient for my needs. My app is readability algorithm with RESTful API, whitch parse news sites, simple computing, but highload. Of course, I need transparent horizontal scaling. I hope for your help.
My $0.02.
If your product is only based on Node.js, without many layers and components such as background workers, business logic layer and API layer, Windows Azure Web Site should be the best choice. It's very simple to deploy Node.js application through Git, GitHub, TFS, FTP, etc. It also provides scaling-up (in reserve mode) and scaling-out options. But keep in mind that all applications under Windows Azure Web Site will be running in 32bit WOW mode.
Windows Azure Web Role is similar as Windows Azure Web Site, but you need configure the Node.js environment by yourself. (If you are using the azure powershell tool, it can help you establish the node stuff by using some startup commands.) If you need something working in worker roles, or the caching (not the shared caching), Web Role may be better.
I've never heard about the git-azure but it looks like a tooling that you can host more than one node application on worker role.