Does anyone know a lot about .net core? (aka asp.net 5)

[Maximilian]

I have two ways of architecting a website and would appreciate some input. I will have a main page at "dotnetapps.uk" and I will host various unrelated webapps at different paths so "dotnetapps.uk/countdownsolver" for example. They are only related in that they will use .net core and probably react.js as well. I basically just want to be a cheapskate and use one domain name for multiple things.

1. I can have different projects in visual studio for each app all under one solution. The thing is .net core bakes the webserver (kestrel) right into the app so each app would have to be on a different port. E.g port 9090 would be the main page "dotnetapps.uk", port 9091 would be "dotnetapps.uk/countdownsolver". They would each have their own webserver. I have nginx setup as a reverse proxy already to deal with multiple webservers on the host computer (the host already has tomcat on it). I have got this approach working, but there might be pitfalls though?

2. I can have one single project and different Areas for each app. Areas seem to be the most common way of dividing up a project into multiple sub projects. Despite not really being separate projects this approach may be simpler. There will still be a need for nginx because of the tomcat servers but it would not be a requirement in the future if the website moved to a different host with no other webservers.

Which approach would be best? They both seem to have pros/cons *insert thinking emoji here* Theres literally every single emoji except the thinking one...

 

[Cogman]

Approach 1 is probably the more scalable solution while approach 2 is the easier solution.

Here is what I mean by that.

Lets say you just bunch everything together. What happens if AppA goes under heavy load? You are pretty much resolved to deploying more servers which host the full cluster in order to solve a problem with a small portion of the app. If they are microservices, it becomes as simple as adding more smaller servers to address the current needs of that portion of the code (nginx supports adding reverse proxy hosts on the fly).

Another benefit is that if you have a code problem with AppA, then fixing that problem doesn't mean you have to redeploy all of your code, you just need to send out AppA.

It also makes it easier to do things like parallel and AB testing. When everything is bunched together, it is doable, but you have to parallel and AB test the entire conglomerate rather than smaller subsystems.

However, for a one-man-shop, it is almost certainly overkill.

Those are just my 2 cents.

 

[Maximilian]

Its always good to see a reply from you Cogman. Cheers for the input!

I don't mind overkill so I think ill probably roll with approach 1. I like how I can fix individual apps without taking the whole site down too that's pretty cool tbh.

I have another question about the URL's the individual servers will listen on though. Ive read this:
https://docs.asp.net/en/latest/fundamentals/servers.html#program-cs

I just want to know if I understand this correctly. From the comments in that code it seems I will want to use "http://localhost:9090" for the main page and "http://localhost:9091" for the first app. Neither of these kestrel servers will be listening for external requests so "http://*:9090" would be the wrong thing to do. Nginx set up as a reverse proxy will be the only server listening for external requests. Is all this correct?

 

[Cogman]

Pretty much.

You'll probably want to have the ports of your apps configurable somehow.

The new hip thing is to shove individual apps into docker containers. Then all the apps can run at the same port (so, 9090, 8080, etc). And then if you want to run them side by side on the same machine, you add a mapping in docker to specify port gets mapped to which port. If services don't need to be externally facing, you can link them together on the same docker box without actually opening up the port to the outside world. Either way, the app doesn't really need to know anything about how it is linked into the external world, that is all provided by whoever maintains the system (even if that is you).

If you don't really want to do that (and I can't blame you, it is a bit of work making everything dockerafiable). The next best thing is simply dropping config files next to the app, reading them, and then setting the port programatically from there.

You definitely don't want to have to manage that in a per app basis, because with microservices, it will get really knarely trying to figure out. ("Ok, port 1234 is reserved for microservice app 1 and 456 for app 2"). It is much easier to be able to just change that on the fly as needs arise.

 

[sao123]

if the apps are unrelated, why dont you just virtualize? Each App can run in its own virtual server, and you control access to each one through DNS... Fully virtualization should reinforce that if there is a security problem with 1 site, they cannot do damage to any of the others... Also that means all the apps can use the same port number.
app1.mydomain.com:9090 app2.mydomain.com:9090

 

[Maximilian]

if the apps are unrelated, why dont you just virtualize? Each App can run in its own virtual server, and you control access to each one through DNS... Fully virtualization should reinforce that if there is a security problem with 1 site, they cannot do damage to any of the others... Also that means all the apps can use the same port number.
app1.mydomain.com:9090 app2.mydomain.com:9090

Im not sure how to do that though. I am using a VM if thats what you mean, each app comes with its own web server built in. This is how it is now:
http://imgur.com/a/wE9K2

Two kestrel webservers (the dotnet run ones) and tomcat. Nginx acts as a reverse proxy to all 3 webservers.

Currently the dotnet apps use port 9090 for app1 and 9091 for app2 but yeah I will look into changing the code so they use the same port that seems like the best idea.