I have got an idea to document my information about my server on my server. I could download any wiki type CMS, but I thought it would be a good practice to make my own application!
I call this application to AtiDocs which is part of my home-made application environment. At the first, I did not shot to the start, I kept my expectations on low:
- Do not make it very complicated as it is 100% sure that I will rework it and add some new features, handle it like a showcase
- No need for authentication
- No need to use normal database software, SQLite is more than enough for this
- It should handle markdown for nice documentation
- Documentations should be stored in a “one-level directory structure”
- Documents and folders should be handled (e.g.: Rename, move, delete, add, change)
Github of the application can be found here.
Short video about the alpha
After publish
After publishing, I installed it as a service on my server. This installation had 2 parts:
- Make a service in systemd for this
- Configure a network for a sub-domain
After publishing, I copied the files into /usr/share/atidocs directory. I made a new service file: /lib/systemd/system/ProdAtiDocs.service. Its content is:
[Unit] Description=AtiDocs instance After=network.target [Service] WorkingDirectory=/usr/share/atidocs User=root ExecStart=/usr/bin/dotnet /usr/share/atidocs/AtiDocs.dll Restart=on-failure RestartSec=30 Environment=ASPNETCORE_URLS="http://127.0.0.1:9007" Environment=ASPNETCORE_ENVIRONMENT="Production" [Install] WantedBy=multi-user.target
Regarding network part:
- I created a sub-domain on my DNS server: https://atidocs.atihome.local
- I also created a prox site in Apache web server
Apache web server site definition:
<VirtualHost *:443>
Protocols h2 http/1.1
ServerName atidocs.atihome.local
ErrorLog /var/log/apache2/prod-atidocs-error.log
CustomLog /var/log/apache2/prod-atidocs-access.log common
SSLEngine on
SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
ProxyRequests On
ProxyPreserveHost On
ProxyPassMatch ^/_blazor/(.*) http://localhost:9007/_blazor/$1
ProxyPass /_blazor ws://localhost:9007/_blazor
ProxyPass / http://127.0.0.1:9007/
ProxyPassReverse / http://127.0.0.1:9007/
</VirtualHost>
Of course, it can run without Apache site definitions, I just simply like use sub-domain instead of tons of port.
Lesson learned
First, I thought it is good idea to use server side Blazor application because, I don’t need to make a back-end server and front-end application, so everything is at one place. But during creation I have met some unexpected problem, all of them has the root cause asynchronous nature due to some stuff was running on server side.
Earlier, I make only client side Blazor (WASM) which used REST APIs at the back-end. Compared this configuration with server side Blazor, well… It may more code to make an API and a front-end webpage, but, in my opinion, it is easier to design and develop too. Due to server-side Blazor, I also had to use more JavaScript that I originally wanted (or I would have used with WASM).
Another point is SQLite. I did not want to use complex database software for this, I thought a lite version is enough. It is light stuff true. But it was strange to me. I don’t like the code-first approach for databases, I am an old fashioned guy. But I made a try. The most uncomfortable thing with SQLite was, that it did not have command line interface, I could not adjust “database” just only with my program.
Final words
Currently, it fulfill its purpose, I will use. It makes its task why I created it. But for further improvements in the future I have some considerations.
When I will go further with this project, where I plan extend its functionality (users, deeper folders, access list, etc.) I will go with separated front-end and back-end projects. This server side Blazor was not a good choice, because this application does not exploit SignalR (because it is not needed) which is advantage of server side Blazor.
And the code-first approach is also not my favorite, but I gave it a chance! I like to design tables, test them and exploits different database features. Thus I will stay at PostgreSQL in the further.
