Home Ticketing #5 – Server environment

Before, I would explain the program, I would like to describe the environment and the way, how it is deployed. It is good to know, as it will self explain some launch settings in the API.

This article is part of a series. Other already public articles:
Home Ticketing #1 – What my back(end) at home!
Home Ticketing #2 – High level overview
Home Ticketing #3 – Tables and relationships
Home Ticketing #4 – Handle data – EF setup

Most of the ports are usually closed on my server. If I would like to reach any application there, I am using a proxy to achieve it. I use Apache web server for this purpose. In this section, I will explain this application related settings what I have implemented on my web server.

Explanation of different instances

I would like to keep 2 instance on my server for this application: one is a development instance and another one if for production instance. A third environment can be also count as sandbox, what I call when I run the API or Blazor Webassembly behind IIS web server with my Visual Studio.

Table above means, I always start any change implementation in my data handler (if related to it). Then I expand it to my REST API if required. When new function or a patch is implemented onto data handler and/or REST API, then I make a publish. I make a deploy to the development environment. After, if needed changes in webassembly, I implement it. In this phase, Blazor project use the Development instance of REST API. If it is fine, I deploy Blazor to the development instance. If development instance is fully done, I run some test: I use those scripts and commands what are sending information to the development instance to check that it still works. If everything is done and works, I deploy both API and Blazor to the production instance.

Apache configuration

As sandbox is technically my local development machine, I need 2 instance: one development and one production. I will show development environment only, but it is same for production instance, only the port numbers and log names are different. Figure can be seen about it.

Apache server is listening on port 81 via https. Apache server receives every network traffic. If the URI beginning with /api for example /api/something then, Apache forward the request to http://127.0.0.1:9005/something address, then send back the answer of the REST API. Every else request will be take care by webassembly files.

You can see an Apache site configuration about this instance. Base of the file was the Microsoft provided settings, I just put some extra next to it: settings for https, use HTTP/2 instead HTTP/1.1 and proxy rules.

<VirtualHost *:81>
    Protocols h2 http/1.1
    ServerName atihome.local
    DocumentRoot "/var/www/hometicket/dev"
    ErrorDocument 404 /index.html

    AddType application/wasm .wasm
    AddType application/octet-stream .dll

    <Directory "/var/www/home-ticket">
        Options -Indexes
        AllowOverride None
    </Directory>

    <IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/css
        AddOutputFilterByType DEFLATE application/javascript
        AddOutputFilterByType DEFLATE text/html
        AddOutputFilterByType DEFLATE application/octet-stream
        AddOutputFilterByType DEFLATE application/wasm
        <IfModule mod_setenvif.c>
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4.0[678] no-gzip
        BrowserMatch bMSIE !no-gzip !gzip-only-text/html
    </IfModule>
    </IfModule>

    ErrorLog /var/log/apache2/home-ticket-error.log
    CustomLog /var/log/apache2/home-ticket-access.log common

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/apache-selfsigned.crt
    SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

    # Home Ticketing - Development instance
    ProxyPass /api http://127.0.0.1:9005
    ProxyPassReverse /api http://127.0.0.1:9005

</VirtualHost>

Possible improvements

Originally, I have begun to use Apache instead of ports directly, because I did not want to memorize port numbers and remember for URIs are simpler. Most of my other application are proxy reversed via 443 (official https) port with different URI. But for these, I wanted to a separate path to avoid any conflict.

My first idea was using subdomain. My server domain is atihome.local, it could be very handy to use sub-domain (e.g.: dev-home-ticket.atihome.local). I also did it, but I use Apple devices too (iPad and iPhone) and I could not adjust /etc/host file there (a jailbreak is not worth only for this). my idea is to implement a dnsmasq on my router, but is far for completion. So, thus I stayed with dedicated port.

Final words

I explained it, because during development I will use different settings in the code based as where it is actually running and after to know this settings some launchsettings.json option can make more sense for people.