I'm using ASP.NET Core 6. I have multiple apps:
uri
user
tech
www.example.com
visitors (landing pages, products, about us, contacts, etc.)
razor pages
api.example.com
-
webapi (to support blazor apps)
app.example.com
customers
blazor wasm
staff.example.com
staff
blazor wasm
I wanted everything in one server app - which is possible, but complicated; I managed to get some of it working. There are many questions (here and in the aspnet repo) for this approach - its popular because deployment seems simple and self-contained (but many people struggle with this, and many questions don't even have working answers).
I realised that even if I succeed, there are many moving parts (the config is a nightmare!), many things that could break in production, and someone else might have to maintain it.
So maybe it's better to have separate (dockerised) apps.
Pros:
simpler implementation
simpler maintenance
easier to scale (especially read-heavy apps, e.g. www and blazor apps, which could even be moved to a CDN)
better division of labour (different team members responsible for different apps)
from personal experience the "www" public website changes more often (sometimes daily) than the "api" web app, so pushing changes to production requires updating everything - whereas if separate then one only pushes changes to individual apps
easier to isolate faults: if something fails or must be taken down for maintenance, the problem is localised and other parts of the system continue to function
Cons:
complicated deployment
more monitoring and health checks
...?
If you've dealt with this, in production, please share your experience. I've no idea what to expect.
I'm interested in the core problem: is serving everything from one server app asking for trouble, or is it a worthy (and maintainable) goal? Thanks!
The answer is yes. While the core web server config is more complicated, you only really have one site.
The razor pages and API are standard server side code that can co-exist on the same site. You can apply whatever authentication schemes to them you wish.
The two WASM sites only need a web server to serve up their startup files. After that I assume it's all API calls back to the server.
There's an answer I wrote a few months ago with a Repo that explains how to set up a server to serve two WASM sites. Create a multiple WebAssembly projects in a single solution
There's also a couple of articles on Codeproject describing how to do it - search "CodeProject HYDRA".
Related
I was given a project in WebForms to make robust and I had so far added several improvements to it. Don't get me wrong, I like WebForms for its simplicity but much of it is I feel like 'grandfather' type of coding.
Here's what I did, just to give you some ideas:
1.) Added VueJS to the frontend
2.) Added Webpack and a bit of ReactJS to on some pages
3.) Used .NET core on running a custom protocol app that triggers from inside the WebForms project
4.) I've added an emailing function (Inbox, Sent Items, Drafts, Trash, Junk, etc.) (from WebForms and jQuery, another one was WebForms + VueJS) to it as well.
It has gotten pretty big. I was just wondering if it will be scalable? Our management is thinking of putting it on the cloud soon but I believe it wouldn't work because of the architecture of our project - we will have to slowly transition it to modern web standards (apply MVC, use WebAPIs rather than WebMethods (static) on CodeBehind files).
I really am lost. What's the best route in improving a WebForms project to modern standards? Something scalable and cloudable (if that even is a word).
Thanks.
(Let me reach for my flame-retardant underwear.)
The big difference between WebForms and more contemporary web design frameworks is that WebForms attempts to layer an event-driven forms management paradigm on a platform that is not built for events. Web pages are not desktops.
In my experience, the efforts to maintain the illusion of web events in a complex application far outweigh the investment in taking the original functional requirements to MVC, or NodeJS, or React, or some framework that is designed for the calls and responses of the stateless servers of the Web.
I vote do-over. You will have to do your own cost/benefit analysis if you want to take that route. If you do go that way, this forum is a good place to post specific questions with code samples related to coding problems that you uncover on your journey.
We want to develop a new ASP.NET Web-Application and if its somehow possible we want to take ASP.NET Core. One of the reasons for this wish is, that we fell in love with ASP.NET Core Identity.. But one problem is, that Identity depends on Entity Framework and Entity Framework Core still has some unimplemented features that we´ll need (https://github.com/aspnet/EntityFramework/wiki/Roadmap).
I´ve found an article in which the author provides possibilities to use Entity Framework 6 with ASP.NET Core (https://learn.microsoft.com/en-us/aspnet/core/data/entity-framework-6). The recommended way of using EF 6 and ASP.NET Core is, creating a new dll targeting .NET Framework 4.6.something and put all the EF-stuff in it. Since this approach is our plan for data-handling in general, the Identity-Data need to be accessed too in some way. And there are many specialized EF-functions for Identity (e.g. AspNetCore.Identiy.EntityFrameworkCore), making authorization/authentication stuff better, easier, faster, handier - what ever.
But using different Frameworks (or even worse different versions of one Framework) for accessing the same database, or accessing the same data twice at two different places with different technologies is not the kind of wiping the slate clean, that we thought of.
May be I am completely stumped and this is pretty clear but I don´t really have a clean way or acceptable approach for this problem right now.
Any ideas?
I would look at Brock Allen's IdentityServer4 if I were you. Here https://github.com/IdentityServer/IdentityServer4 and here http://docs.identityserver.io/en/release/ for documentation.
You will even find some blogs on the msdn site recommending it.
https://blogs.msdn.microsoft.com/webdev/2016/09/19/introducing-identityserver4-for-authentication-and-access-control-in-asp-net-core/
I think you will find its a much more complete solution.
To quote from the MSDN blog;
IdentityServer4 allows building the following features into your
applications:
Authentication as a Service Centralized login logic and workflow for
all of your applications (web, native, mobile, services and SPAs).
Single Sign-on / Sign-out Single sign-on (and out) over multiple
application types.
Access Control for APIs Issue access tokens for APIs for various types
of clients, e.g. server to server, web applications, SPAs and
native/mobile apps.
Federation Gateway Support for external identity providers like Azure
Active Directory, Google, Facebook etc. This shields your applications
from the details of how to connect to these external providers.
Focus on Customization The most important part – many aspects of
IdentityServer can be customized to fit your needs. Since
IdentityServer is a framework and not a boxed product or a SaaS, you
can write code to adapt the system the way it makes sense for your
scenarios.
We have a number of small ASP.NET MVC apps. All are basically a bunch of forms which capture data and store them in a SQL Server database, usually which are then loaded through to our datawarehouse and used for reporting.
We are looking to rewrite all the small applications and apply a level of consistency and good practice to each. All the applications are fairly similar and I think from a user perspective it would be better if they seemed to be part of the same large application so we were considering merging them together in some way as part of the re-write.
Our two currently preferred options seem to be:
Create a separate portal application which will be the users point of entry to the apps. This could have 'tiles' on the homepage, one for each of the apps (which would be registered in this parent app) and could link them through to all. In this scenario all the Apps would remain in different projects and be compiled/deployed independently. This seems to have the advantage of keeping the separate so we can make changes to an app and deploy without affecting the others. I could just pull common code out into a class library? One thing that annoys me about this is that the parent app must basically use hard coded links to link to each app.
I looked into using 'areas' in ASP.NET MVC and have all the small apps as different areas in one big project. This seems kindof cleaner in my head as they are all in one place, however it has the disadvantage of requiring the whole app deployed when any of the individual ones are changed, and I have a feeling we will run into trouble after adding a number of apps in to the mix.
We have a SharePoint installation and someone suggested creating the portal type app in SharePoint... This doesn't sound like the best idea to me but am willing to consider if anyone can point out advantages to this method.
Are there any recommendations on the architecture of this? Has anyone completed similar projects in the past and something worked well/not well?
We have 4 developers and we do not expect the apps to change too much once developed (except to fix potential bugs etc.). We will however plan to add new apps to the solution as time goes on.
Thank you
MVC Areas advantage would be allowing code sharing, by refactoring the repeated redundant parts of each app to use the same infrastructure code (security, logging, data access, etc.)
But it will also mean more conflicts when merging the code initially.
Deployment concerns can be mitigated with a continuous deployment tool (there are many in the market) or if you deploy to an Azure WebApp, then deployment slots can give you a zero down time deployment.
Is it possible to self-host an ASP.NET MVC application and/or OData service in a stand-alone workstation app? Are there any successful examples of doing this?
I would like to create a suite of data-centric applications using .NET that are targeted to EITHER a solo/home user OR a team. Unfortunately, I am the only developer. Comparing front-end technologies of WinForms, WPF, and ASP.NET MVC, I am most proficient with ASP.NET MVC. I would also not like to write multiple implementations of my data service.
(Commenting in lieu of voting down as my profile cannot yet vote down.)
You really need to do some research here. Almost any service-oriented .NET technology can be self-hosted... WCF web services, OData, etc. Your bigger concern should be performance. The more layers you add to your app, and the more times you transform or "serve" your data, the more cycles will be spent processing your data. What you may find is that you users become less happy with the performance compared to a snappy compiled UI hitting a simple business or data layer.
In short, yes, this is possible. However, I would save this type of app for one-off / in-a-pinch apps with either a short life expectancy or very minimal client usage (settings panel, etc.).
We have a ten-year-old ASP application that we are considering planning an update for. We want to take advantage of the new technologies that ASP.NET has to offer, as well as the opportunity to fix some issues with the existing framework (the existing code-base is highly fragmented, nearly impossible to test, let alone debug, and the entire application appears to have been constructed according to the "Farmhouse Pattern".)
To that end, it seems that the time has come to rebuild this application. But, we are a small business, and we simply don't have the resources to either hire out the rebuild, nor to dedicate our small team of developers solely to the task of rebuilding (we've got other tasks on our plate, and can't concentrate on this one particular task for the length of time it would take to fully reconstruct the application).
What, then, are some useful strategies we can employ to help us convert this app, without having it consume all of our limited resources for the duration of the re-write?
Sounds like an interesting challenge. It's definitely not going to be easy, especially if you can't dedicate any resources to the project full time.
If you have a 10 year old application that is working, I would suggest not going for a complete re-write at all. I would start by sitting down and figuring out what you want your end product to be.
Is it going to be an ASP.NET MVC Web Application, an ASP.NET WebForms App, or something else? Once that decision is made, come up with a loose design for an architecture. If you do things correctly, you can build out bits and pieces of the business logic in .NET and utilize it from your Classic ASP code until you're ready to re-write the UI in .NET as well.
I agree with what Justin said; if you have a working application in place, you'll need a compelling reason (i.e., money) to justify the expense in rewriting the application for a new platform.
Although ASP classic and ASP.NET share a similar-looking syntax and some common coding conventions, they are very very different from each other. If you tried to simply copy-paste classic ASP code into an ASP.NET application, you might be able to get it to work, but you'd be missing out of a lot of the advantages of ASP.NET Web Forms or ASP.NET MVC (and their respective frameworks, of course).
You can, however, extend the functionality of the existing site with .NET code through web services or COM interop. We have a 10+ year old classic ASP web site and I've used both .NET web services (.asmx) and COM-callable .NET DLLs to enhance our existing application. In both cases, I wrote all of my new business logic in the .NET component and provided a chunky interface to work with the existing ASP page. That allowed my .NET code to be very easily testable and still use our existing (huge) investment in our classic ASP site.
The only approach that has worked for me is to carve of areas of functionality in small slices, and rewrite. "Converting" first, then refactoring seemed like a good idea a few times, but in the end just became horrible messes of code written in ASP.NET instead of ASP - and that added no value.
If you have a site that has distinct areas of functionality, carve one off and start with that (I chose "contact us"). Write it the way you think it should be written - that is, assume your new part is fitting into the end design of your well-written app. If you have to add "hacks" to interface with the old system, make sure they are isolated and commented.
When working on an update, think "can I carve of some of the functionality here into it's own bit?" - if so, convert it then update it. I found that if you insist on keeping the NEW app clean and allow yourself to add small hacks to the OLD app for communication, you get the best results.
This does mean you'll have two separate apps (two IIS web apps) for a while, and can make cookie/url and session management a bit hairy, as well as adding one more deployment concern. To combat this, make sure that you minimize state in your web app (always a good idea anyway), and share state through something other than Session.
If you do this a piece at a time, make the pieces small enough, and have a good design up-front, this works well - at least in my experience, it's the way that works best. Note that my experience may not match reality.