joro550 / dotnet-server Goto Github PK

Pie in the sky, but imagin instead of having to edit and manage a crappy json file you could setup the server within the server mind blown if we create an interface and then have people create endpoints via the interface, now that would be cool

We could have a database that gets spun up that allows users to post information which saves and then get that retrieves information from the database, I'm not 100% on this idea, so I'm gonna let this sit for a while. I'm pretty sure we'd have to make quite a few assumptions on the data and maybe this is taking the project a little too far into the CRM world

May want the ability to spin up multiple servers with different endpoints

this was a quick hack - need to make it maintainable

i know nothing about certs right now - will have to do some research but maybe you would want to have the server run on a particular url and have your own cert and not have to have the dotnet cert, this is a big fat maybe right now

Right now you have to close the server edit the file and then restart the server, I wonder if there is a way to deregister the old routes and register the new ones when the file has been saved (I'm assuming we could watch for the file being altered via a file watcher), this would stop people having to stop-edit-start and make things a little quicker overall

Both non ssl and ssl ports

I want to be able to import routes to the application and everytime I run the application I want it to run the routes that I have setup without having to define a file every time

The ability to give a url and an object so that the server can post information back to somewhere.

So that when people call a certain url, if they need that url to post information back to them we can handle it

I don't know how many times I've needed this

Change it to a library application

If you have a bunch of files in a folder then aybe we can think of a way to load the endpoints from the file names and then grab the response from the file contents

Wondering if we could add swagger dynamically to the server so peoplecould inspect the endpoints and actually make requests form the webpage - that would be pretty cool

Expected behavior

Starting the application with a valid configuration file and pressing ctrl + c shuts down the application. As the console output states in line 7.

❯ .\DotNetSimpleServer.exe -fileName:..\..\..\..\..\file-example.txt
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:6000
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://localhost:6001
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\Users\ZZZ\Documents\GitHub\joro550_dotnet-server\src\GlobalServer\bin\Debug\netcoreapp3.0
info: Microsoft.Hosting.Lifetime[0]

Actual behavior

Starting the application with a valid configuration file (as in expected behavior) and pressing ctrl + c does not shut down the application. It prints out Application is shutting down... and stays there.

After pressing another key shuts down the application

• Post
• Put
• Delete

{
    "description": "A GET request to retrieve a thing",
    "request": {
        "method": "get",
        "path": "/things/{id:int}"
    },
    "response": {
        "where": [
            {
                "condition": "id == 10",
                "response": {}
            },
            {
                "condition": "id == 11",
                "response": {}
            }
        ]
    }
}

Maybe this makes sense?

Maybe if the user specifies a file the server can load it dynamically so we don't have to stop and start the server all the time

We could have this as a docker image, if we remove the command line aspect of it (which should be faily trivial), that way you could docker run dotnetserver -e filename and point it at a filename, I think that would be pretty cool

One of the use cases I've com across in the past when implementing a payment provider is that I need an intermediate page where I could input data, so maybe we could

• Add support to go to a url that renders a page
• Add support for some sort of page rendering
• Add support for information being passed back from the page

Again maybe a little too CRM like