I'm new in ASP.net MVC Single Page Application (SPA). I want to design a system that using SPA concepts.
However, I have a bit confusing on how a system consider design in SPA concept? Is it the system URL must always same although we perform many activities or don't have back function (browser) as it always in one page because only render the necessary HTML part? I did googling on this, still have no idea. Does anyone can explain in more simple way?
Thank you.
One of the main advantages of having an SPA is that because you only have one page and you load all the data at once (or make multiple AJAX calls in the background to get data on demand) your application gives an illusion that there is no post back to the server, making your web application seem like an app.
Using SPAs can potentially improve the user experience of your application.Site speed can be improved but you might have to make a user wait a few seconds to load all the initial data.SPA's are great for touch screen appications, such as kiosks and touch based Point Of Sale systems where the navigation is 100% controlled by the SPA.
SPAs also have a lot of disadvantages like implementing the back navigation in your site.In traditional websites this is not a problem but in an SPA you would need to make very clever use of javascript libraries such as Backbone.js or Angular.js to mimic this functionality.Also search engine functionality of public sites and analytics may be a problem.If your are writing a huge enterprise type of application, you may encounter performance problems.
I would stronly recommend reading Disadvantages of Single Page Applications before you make a decision on whether to use them or not.
A SPA can still have multiple different URLs.
In this case, the server that is hosting the application needs to be configured to direct all paths for a URL to the main index.html page.
The index.html page will load the initial part of the SPA, and if it sees there is a path on the URL beyond /, then it will load the "component" for that path.
A "component" as described here might consist of HTML, JavaScript, and request any data that is requested from external APIs.
Angular is a SPA framework that has built-in support for loading components based on registered URL paths. There are other SPA frameworks, as well.
Related
We have an existing ASP.NET CORE App with lots of controllers and views (with knockout for 2-way-binding).
Now the requirement is to build new pages (views) with Angular 4 but the rest of the App should stay unchanged.
The management says it should be made like previous knockout extensions which integrate seamlessly in ASP.NET CORE views. This means each page should be a seperate Angular 4 SPA. This requires that routing has to be done with ASP.NET CORE and not Angular 4.
Question: Is this feasible? If yes, how?
Question: Are there better strategies to extend an existing ASP.NET CORE App with Angular 4 parts than this approach?
EDIT:
What I don't understand so far is how to provide routing by ASP.NET CORE in combination with Angular4. In ASP.NET we use _Layout.cshtml for common layout code including a #Html.Partial("_Navigation") for navigation and #RenderBody() for rendering the views. We want to use razor partial views as for the Angular templates. This excellent article describes how.
But how can this be done with ASP.NET routing?
I have found a solution that works for our requirements. For each "mini SPA" I created the necessary files (NgModule, main.ts) to bootstrap them. Then I add a Controller that delivers cshtml-views that contains the load command for the different "mini SPAs". Referencing them in ASP.NET navigation worked like a charm!
One of the key purposes of Angular is to write single page applications (or SPAs). And that does NOT mean what it sounds like. The idea is that the user can seamlessly move from "page" to "page" in the Angular app without hitting the server to ask for the next page. So from the servers perspective, it is providing a single page down to the client ... and then Angular takes over and displays all 10, 50, or 100's of views.
Retaining the ASP.NET routing and rewriting each page in Angular would be pointless.
For a more concrete example, say you have a Product Management application. In Angular you would write every view: Product List, Product Detail, Product Edit, Product History, etc. When the user accesses the app ... all views are downloaded. Then the Angular routing moves the user between these views without needing to hit the server again for another page.
If each of these was an ASP.NET view, then ASP.NET would serve the Product List page. Then if the user moves to view details, they'd have to wait for the server to serve the Product Detail page. Then if the user returns to the Product List page, the user would have to wait for the server to serve the Product List page again.
So my advice is to tell management to take an Angular course (I have one if they are interested) or leave it to the developers to make the appropriate architectural choices. :-)
Seriously though ... it seems like there would be a large expense for very little benefit if you were still planning to serve every individual page from ASP.NET.
And maybe that's the answer here ... ask them what they are truly trying to achieve with a move to Angular.
I have an AngularJS WebAPI application that has a Javascript front-end. The front end makes calls to the back-end WebAPI for data. In the future there may well be more than one front-end making calls to the back-end.
I would like to change this application to use HTTPs and am looking into how to best architect this. The way I see it there are two ways (maybe more).
(1) Host the WebAPI C# application, index.html, Javascript, Javascript libraries and other HTML on the one (or more) web roles.
(2) Host the index.html, Javascript, Javascript libraries and other HTML on a CDN and put the WebAPI C# application on one (or more) web roles at one location.
From a performance point of view are there likely to be any issues with the split solution (2) when I am using SSL. Is there anything that I should consider that might help improve the start-up time (my goal is for this to be as fast as possible).
One more question I have. If I were to use the Azure CDN then would I still be able to address the index of my web site as www.mywebsite.com and if using HTTPS would I need a SSL certificate?
Option 2 is more preferible.
You have to think, that your application is what sits in the backend. The front end is just a suggested set of UI controls and interactions to consume that application you have. Then, if you can host them separately you have some benefits, starting by not creating UI dependency.
The approach would be like creating a thin client.
Since the application is AngularJS based, probably all the UI are static files with HTML, CSS, and Javascript. You can host them in BLOB storage, and scale it through the CDN. You can have a custom domain name pointing to Azure Blob Storage, like `www.yourdomain.com. It has many benefits, including better price and scaling than web roles. Put aside, that you pay for web roles no matter if you are getting hits or not. The only downside is that as far as I know, it would not be possible to use HTTPS, but that should not be a problem, since you are just hosting static content and templates that contains placeholders, no actual data.
On Blob storage, you can attach your own cache control headers, allowing the browser to cache those files locally. Then a user would download those files once, and be recovered from the browser cache next times. Also, you can store the content already compressed in GZIP, and then set the content encoding property to let the browser know it is compressed, therefore enabling a faster content download. Not forget you should bundle your resources. For example, you should bundle all your JS code in one JS file, all your CSS code in one CSS file, and all your AngularJS views should be bundled in the template.js file (also bundled into the unique JS file).
You need to host your backend application in worker/web role instances though. Here you can use HTTPS, and it would be no problem to use AJAX over HTTPS, although the page loaded on HTTP as long the SSL/TLS certificate is signed by a CA recognized by the browser (ie: a valid certificate). If you use a self-signed certificate, there will be no way for the browser to prompt the user to accept it. Keep this in mind if you plan to start with a self-signed one.
So then you would have all the things that are not user/state dependant in blob storage, that is cheap, fast and highly scalable; and all your user data interaction would happen through your worker/web roles through compact data request/response probably in JSON. Therefore you need less web/worker roles for providing the same level of service.
Now, if you have a very asymmetrical amount of massive queries and data changes request, you should consider an approach like CQRS.
The answer to this question is to use the Web Page portlet; however, the way that portlet works does not provide the solution I need. Please read on before suggesting that particular portlet.
The short version is we are transitioning our intranet to a Websphere Portal 7 solution. This means we have several applications on various servers that we'd like to surface in portal. The Web Page portlet does this, but not in a way that meets our needs due to the 2 limitations:
1) Application URLs for the Web Page portlet must be in the same domain. The applications will be local to our domain, but will likely be on various servers.
2) The authentication must be done via a HTTP GET method. This is really quite ludicrous as this would put credentials on the URL. Who on earth would ever want that?
The things this portlet does that do meet our needs are:
1) Allows setting of credentials via field name/value pairs
2) Loads an application in an IFrame
So, pretty much, I need a portlet that gets around these limitations, but loads the application in an IFRAME like this portlet does. It's hard for me to believe a portlet isn't already out there for this sort of need, so any tips or suggestions would be greatly appreciated.
I'm not sure if it fits your needs completely, but the Web Application Bridge uses a reverse HTTP proxy to do a get (or put, etc) request on a url and manipulates it via an iframe in Portal.
Here's the page in the solutions catalog: https://greenhouse.lotus.com/plugins/plugincatalog.nsf/assetDetails.xsp?action=editDocument&documentId=9FAAD6D44DC64231852577EB006F4D9D
I am writing a simple web page for our existing web site that will only be used by the web site admin to delete all images from a certain directory on the server. He would browse to this page from his web browser (not to be consumed by any external services as of right now). I was thinking of creating another ASPX page (obviously not linked from or to anywhere) that implemented this. Is this considered a RESTful API? If not, what would be, and would it be a more elegant solution than what I'm proposing?
I realize this is an extremely simplistic example, but I'm trying to understand what RESTful really means and if it would benefit our existing infrastructure in any meaningful way, so that's kind of the purpose of this question.
Our website is written entirely in ASP.NET 2.0 WebForms.
It depends on your URL structure. a classic REST API call would be to, say:
/images/delete
You would then send a Post as DELETE or just GET or POST to this to do what you need. That's more the RESTful way. REST isn't so much what you are doing with the method as the structure of that method. I hope that makes sense :).
I am trying to implement a service to download a image file. The code does nothing but upload a file to the response with each client request.
There are no SOAP messages involved but I am planning to implement it as ASP.NET web service. It can also be implement as ASP.NET website but since it has no view (forms, html etc) I planned to implement a web-service.
Is this a better approach? Does ASP.NET Website offer better performance that a Web-service?
Which one would be better is this situation?
I'd suggest using an ASHX handler. If you haven't heard of them before, you can think of them as a code-behind file without the ASPX view. Generally speaking they are considered more light weight than a web service.
Well first off, do you need code to handle the image request at all? Is the image processed in some way relative to the request, or is it static? Why do you want to implement this in code instead of simply serving a static image over http? Are there security considerations to be taken into account, e.g. serving images to particular users based on their credentials?
Unless you can give us a little more detail of your requirements it's impossible to make any concrete judgement or recommendation.