Fenix can be used by anyone that needs a local web server on their localhost. For example, someone developing a web app can use it to serve their site locally. Before you say, "But I can just open the
index.html file in the browser". You can. Then, with a real web app that sends queries to the server, these requests will fail because of security restrictions. In many cases (especially on Windows), people wil install XAMPP just to get a "server" running. Many people don't need all of the functionality of a "real" server. Fenix solves these problems by providing a lightweight HTTP server for your local needs.
Fenix also allows you to open secure tunnels to your local computer. This means that your coworkers or clients can actually connect to your web page or application and see exactly what you are seeing. For many developers, this feature is the primary benefit of using Fenix. Yes, there are other ways to accomplish the same thing, but they are generally more painful.
Since I develop on a Mac, someone might say, "Just use Python's SimpleHTTPServer or the Mac's sharing feature". I could do that. In fact, that's exactly what I've been doing for many years. However, this solution has some of it's own problems.
First, I found that in many cases, I could overload the SimpleHTTPServer. When developing for Kids In Touch, I found that many of my files would 404 even though they really exist.
SimpleHTTPServer also has a problem with build processes. If I start the SimpleHTTPServer on say port 8000 in the actual public folder of my grunt build process and then run my build script, SimpleHTTPServer can no longer serve files. Why? The grunt process "cleans" the public directory - essentially deleting it. Then, it re-adds all the resources in the the directory. If I reload port 8000, I get the server not found page because SimpleHTTPServer isn't really serving that directory anymore even though it has tied up port 8000. Because of this I get tons of errors, ugh!
So, after the grunt process, I have to Ctrl-C to kill the server, then issue this command
cd ..; cd www; python -m SimpleHTTPServer 8000 to get the server running again. It's just a bit of a pain.
Along comes Fenix to the rescue. With Fenix, I simply add a new server via the GUI. This just consists of telling it a server name, the directory path, and an appropriate port:
Next, I click the Start button to get the server running:
Now, I can serve the production ready Kids In Touch web page. Any time I run my build process again, Fenix doesn't have trouble with the reload. It just works.
Here's Kids In Touch being served outside of my localhost from a secure tunnel - it's free!
Yes, I know there are other solutions to the problem I just described. However, Fenix is just so simple to use. On the occasional side jobs I do, it's great to let my designers see the website in their own browsers. They can open the console and pick away at the HTML / CSS on their side. This works so much better than screensharing.
For all of you command line hardliners, Fenix even has it's own CLI for starting, stopping, and listing servers. Fenix also includes the ability to inspect Webhook calls to your application from internal or external sources.
My only real complaint about Fenix concerns accessing the server logs. In the GUI, you can see the logs inside the Fenix window. Unfortunately, they are just too cramped.
Now, admittedly, you can FullScreen the Fenix app to see the logs more easily. Unfortunately, when I tried this, it really messed up. After Cmd-tab to another app and then back to the Fenix app, no GUI shows up. So, this is clearly a bug. I had to try access the Window menu item several times to get the GUI back. I also simply hate Full Screen apps. So, I'd really like to see a way to copy/paste the logs or open them in a text editor.
Fenix has one more little feature up it's sleeve. It allows you to server local Markdown files. I'm not sure which "flavor" of Markdown it uses, but it works for most of my needs.
Hopefully, this post shows your some benefits of using the Fenix Web Server. Try it out and see if it fits in your workflox.