I have started to work on a greenfield web project which will use ASPNET Core and Aurelia. I cannot find a definitive best-practice approach to structuring this on the client. My current thinking is that each app feature will be be a separate Aurelia application, i.e. when a visitor clicks on the link "Accounts" the browser will make a server request to https://example.com/accounts. This will return a single HTML page which bootstraps an Aurelia app just for accounts. All the accounts interaction will be delivered using Aurelia. Similarly, if the visitor then clicks on "Dashboard", another server roundtrip will bootstrap the "Dashboard" Aurelia app.
Is this a good way of approaching the problem? I have some concerns around application state - in that there will be cross-cutting concerns and data which I don't want to keep round-tripping to the server every time I need it, e.g. audit logs, user information.
I see that Aurelia has the concept of Features - semantically this is exactly what I want as each of these areas of the app will be delivered as a feature. However, I cannot find any good examples of the use of Aurelia features.
Any comments or experiences in similar projects most welcome.
I don't know if it's the 'best' way of doing it but a lot of the applications I build are user / admin type products.
Rather than building an application for each side I take advantage of child routers and structure my application with a page based convention as described here:
https://ilikekillnerds.com/2015/10/how-to-structure-an-aurelia-application/
Related
I want to make a quick, safe and nice application.
For many years I have been programming in PHP and regular ASP. But wanted to go on with .NET and vue.js.
So I have an idea, I wanted to create and plan to do it like this:
I was thinking of using hosting from an external service.
Then I would have three projects:
domain.com/index - Vue.js which will be a SPA, where the user can filter through a catalog, press like and send few api requests (mainly get-requests).
secure.domain.com - Here I will have a .net mvc project where I can use identity. This will make it simple to handle/register users. I will also give the correct session here for authenticated users. And it will affect domain.com/index, where they only are allowed to do some of the things if they are logged in
api.domain.com - This will be the webapi api. Only authenticated users will be allowed to send some of the requests.
I have used several weeks at looking into how to structure this.
But as I do not have much experience with this.
What pitfalls and bad consequences do you see in structuring it like this?
Are there any heads up you want to give me? Or any other recommendations?
I have been trying to melt all of this together in one project, but that has been difficult, because they operate in different ways. So now I have ended up with this, and look forward to
Size of project
It will be a relative small project.
People should be able to register/authenticate themselves (through facebook/google/server login).
Authenticated People should be able to add records(links) to a database. When adding this to the database they may also want to upload files, and choose some additional information.
All people should be able to filter through the catalog of records (5000+) ( Here I am using vue.js/vuex/axios). Here they should be able to comment too on links too.
Webapi will have 8 entities/tables and one view which will GET all the information. 3 tables should be able to have POST.
So it is more or less a catalog, where people should be able to add records and find new ones.
I was planning to use the identity from asp.net core 3.1. It is a "template" where I can easily add 3rd party logins. (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-3.1&tabs=visual-studio)
Additional questions:
Can you tell me how request from SPA will be authenticated in your API? (Jwt or cookie)? Why would you like to have a separate identity service, also Why you would like to use asp.net identity (is it because of ease of setup)?
I have not been thinking about authenticating API requests. Was thinking to only have authenticated users who can send POST-requests. And the rest will be get requests. Limited only from the server. Should I have some additional authentication? Does JWT make web APIs safe enough for my use?
Was thinking of using .net identity because it is simple. And I don't want to use time on setting it up.
Since this is your first project of this type, I would recommend to keep it simple.
Just create one web site. Otherwise you might get issues with the cookies not working for subdomains and you will also get issues with CORS. That is, you will get all problems at the same to time (configuration issues, infrastructure issues and the pain from writing the application itself).
You can still have a clean separation by using sub folders (or Areas in MVC) and by using class libraries for the backend (API) business logic.
Once you have mastered the basics (i.e. writing the actual application) you can start looking at other means of separation etc.
I have just picked up Vue and am trying to figure out the best way to structure this project.
Requirements:
A basic MPA (traditional site) with about 6 pages. This will be static info.
There will need to be a login section where customer will transmit data via form. Payment will happen here as well so will need to be secure.
My question is how should I be using Vue here? (I've already used VueCLI to scaffold out the project)
Should I:
A) use it for some components (Navbar, buttons, forms, etc) and keep structure traditional? How would i build out the User Dashboard to submit form info in this case - just as a new page?
B) or should I build this whole site as a SPA and have the new 'page' info loaded in on click? This would be easier for the login section?
One thing that may be clear on reading this is I don't understand well how the site will recognize users and deal with logins. Would this be easier if it were structured as a SPA? (more secure?)
(Also, I'm using this site to teach myself front-end development, specifically would like to learn more about building SPAs - so I realize I could use a web editor or easier solutions, but want to learn how to do a lot of this from 'scratch')
From what you've described it is entirely up to you. Both SPA or MPA would work fine and either would be totally reasonable given the requirements.
Have you worked with Vue-router before? SPAs don't need to appear as a single page to the user. They can still function as an MPA with different routes, page files, permissions, etc.
If you are hoping to use this project to teach yourself front-end web dev and know you have a particular interest in learning about SPAs, I think that is your answer.
I would go with an SPA and set up vue-router to manage your routes, and pages.
Currently I've been tasked to create a bunch of small-to-medium applications, each of them having some common functionality.
Implement a preapproved boostrap-based graphical design. Therefore, they will use the same assets, images, css and JavaScript components.
Share the same licensing-based mechanism. An application service will be built where it will scan a file or database to get the number of licenses available for each app, thus granting or denying access to users. The only thing that varies is the name of the application instance itself.
Use AzureAD authentication.
Each must use the same authorization mechanism. A claims-based mechanism will be built to retrieve the claims from the database, given a user AAD account.
Each must share the same administration console.This console will be the one needed to populate user information and common catalogs.
A service will be built, to show toast notifications within the apps.
An email notification service will be built, to send emails to users when triggered by business rules.
And some other, less important features, but these are the core ones.
A first, perhaps naïve approach, was to create an ASP.NET Core 2 solution for each application, and implement the shared functionality in a sort-of Core assembly that can be shared by each app. However, while this could work for points 2 to 5, I'd still be repeating the graphical UI design for each app (basically, copying the wwwroot folder as well as the shared razor views five times). So, a change tomorrow in a CSS would have to be replicated five times.
Another approach would be to create a single ASP.NET Core 2 solution, implement the shared functionality and the UI, and then use the "areas" feature o ASP.NET Core 2, each area being a different app. The problem to this approach is shipping the app: if I have to install the five apps in a customer's server, no problem. If I have to install, say, only two apps, then I'd have to ship the five apps anyway and find a way to disable the other three apps.
So, I'd like to know if there is a feature in ASP.NET Core 2 for handling this type of scenarios, or alternatively, what are industry-standard architectural designs that could apply here.
In Windows Presentation Foundation with Unity, I can create a common shell, and then load modules in that shell, within the same shell window. So, using configuration files, I can add or remove modules as I see fit. What I'm looking is something similar in concept. I do not want to create five ASP.NET Core solutions and copy-paste the wwwroot folder and implement the same mechanisms of authorization, notification, email, etc., but rather, find a way to load the core, common features and then load additional features.
Thanks in advance.
I'm embarking in my first spa mvc 4 app and I've watched the Steve Sanderson talk which was great but his final delivery tracker app ends up with 3 views that are all declared in the same view page. This is fine for a small app but how do you manage this on a larger scale when you have different sections of the site that have different data. The site I want to build needs to remain on a single page because I want to keep a chat window open similar to the Facebook style chat and i am going to be using SignalR to push data to the client in fixed sections within the app. Do I just use the #Ajax.actions to load up completely different sections of my site much as I would if I was just creating a non spa site? The plan is to keep the user in a specific section of the I site for a majority of the time, but I will want settings pages and user profile management pages that are defined in separate views.
Any good sample code would be greatly appreciated I'm planning to just use the bog standard spa with knockout and nav.js unless someone can suggest a more mature spa technology for mvc/entity framework that's got some good documentation and is popular.
What I do is poor mans SPA, which is basically make my site like a standard ASP.NET MVC app so I have multiple views, multiple controllers and actions and I have a shell page with a container div which I use as the container for the whole site to load my views into with Ajax calls, so I have lots and lots of jQuery ajax calls, I've somewhat tried to refactor my client side JS and make a generic navigate to Javascript method (among other things) in my shell page, which I then invoke from the child views, so a click on a certain ActionLink in a particular child view and I would call my generic JS page loader:
GoToPage(controller, action, query)
which will use jQuery Ajax to lad the destination controller/action/view into the container div in shell.cshtml. For navigation I use Ben Alman's hashchange plugin to detect hash change events and load the appropriate views into my container div. There are obvious downsides to this approach as you're rally not building a real SPA, you're making a server side app with a SPA facade, and actually the performance difference between this and a proper spa which only gets data from the server (not HTML) is slightly noticeable, however if you're a traditional ASP.NET MVC developer this saves you from having to take up new libraries like Sammy.js and knockout etc. The biggest downside of this is that you'll be writing a lot of repetitive wiring javascript which can quickly become a tangled mess, especially if you have a lot of forms. Though you can take certain steps to re-factor and reuse common code. So in summary generating views server side and retrieving them with Ajax probably isn't the most optimal SPA solution, but for me it had the least learning curve (none actually lol). I've recently been looking at Durandal and I think it finally provides a very viable solution to creating SPAs, I specially like how unlike Sammy.js you don't have to load all views on the initial page load, even if the user isn't going to visit those pages. A nice getting started tutorial is provided here.
I am in the process of converting a web application that has been in play for some time into a Sitefinity 4 managed site. There is plenty of documentation on how to use the software to CREATE a new site, but I've found precious little that describes the process of how to migrate from non-cms to Sitefinity.
So - specifically, I would like some guidance on the process of conversion from non-managed to managed. I've been searching google and the Sitefinity forums, etc. but finding nothing except how to migrate from one version of Sitefinity to another - not what I'm trying to do.
Any leads for web sites to visit or documentation pages to read would be very helpful.
You'll have to bite the bullet and invest more resources at the beginning of your project and not release anything for some period of time. You won't be able to drive your car without fundamental components. The same principle applies here.
Whatever your requirements are, you will either have to hack around the CMS and then fix the hacks later, or do it properly from the very start.
Look at your existing site and break it down into smaller chunks
Consult Sitefinity documentation/partners/freelancers on how your existing content can be migrated onto Sitefinity platform
Task up the migration and start implementing
This is very rough guideline, but so are your requirements.
To summarise, there is no quick way. You'll have to do it properly form the start, or invest more resources later on bug/hack fixing.
If we have Sitefinity at the root of the application, we cannot,
according to Sitefinity, have any pages not managed by SF
That's not entirely correct. Sitefinity allows you to add "external pages", meaning that you can create odes in your sitemap which would like to external pages. Thus, your navigation in Sitefinity would show a complete website page structure, while some of the pages in that structure would actually be linking to external ones.
It would be absolutely easy and quick task to create your page structure programatically.
actually this is quite simple to achieve. Sitefinity is completely dynamic CMS (meaning, no real files). The implementation uses RoutingEngine and VirtualPathProvider to achieve this. What this in reality means is that you have two solid and standard extension points to split the site in "sitefinity managed part" and "custom managed part".
So, a very simple way to do this is to simply register a route (more info here: ASP.NET routing) before the SitefinityPageRoute, as SitefinityPageRoute will throw 404 if it cannot find a page.
So, let's say you register a route "~/mystuff" before SitefinityPageRoute, all the requests that start with "~/mystuff" will first go to your RouteHandler where you can decide to handle them (write to http response) or do nothing and let it fell down to Sitefinity routes.
Another way is of course to implement a custom VirtualPathProvider, however, this may be an overkill if you simply want some pages to be handled differently.
All this being said, it's obvious that pages not handled by Sitefinity will not be handled by Sitefinity :) (so, no page editor, no workflows, no translations, no widgets, no templates, no themes).