Love Localhost
Develop Locally… and love every minute.
Despite the abundance of tools on the market for making web design and development easier, there are still fundamental challenges. All developers, experienced or otherwise, must deal with obstacles in their journey to a product release state.
The first barrier many people face is the act of setting up and maintaining web infrastructure. At some point in the design/development life cycle, web products must run on a real web server (i.e. over HTTP). To do this, developers traditionally recreate the web server environment on their own computers, often starting with the installation of Apache, Microsoft IIS, or NGINX. While these are powerful and robust web servers, they’re also massively overpowered for most needs and far more complex than necessary to configure. Translation: time suck.
For those who want to spend less time managing infrastructure and more time coding, there is a way. It’s called Fenix.
Fenix Rises
Fenix is free desktop software that provides simple web serving capabilities with a great workflow. Named after the mythological phoenix creature, developers can fire up and kill web servers as often as necessary. It’s simple by design, focusing primarily on static web content like HTML, CSS, and JavaScript. A handy installer makes it easy to get started with the software. Most importantly, it’s visual. The most complex configuration in Fenix is a matter of filling in a form, not editing XML/config files.
Fenix has actually been around since early 2013, starting life as a side project. In April 2014, the original version was retired in favor of a much simpler, lighter, and easier Fenix 2.0 (shown above).
The Importance of Workflow
There’s nothing more frustrating than a halt in an otherwise productive day. What was budding enthusiasm quickly turns to dread. This sentimaent may resonate with many developers. The thought of configuring “one more server” can be summed up with “ugh”.
Fenix makes web serving much easier to do with a simple installer, a visual interface, one-click collaboration features, and insights into web traffic (including webhooks).
Using a web server from the start of development can reduce stresses, especially when prototyping HTML/JS apps. For example, like any web server, it inherently provides CORS support. Serving a JSON or XML data file to a jQuery page won’t cause the browser to complain about cross origin policy restrictions.
Of course, visual interfaces often make life easier. Color coded status bars identify online/offline servers, errors, and warnings. Animations highlight important activity. If you use growl or growl for Windows, Fenix uses it to keep tabs on itself without annoying the user. There’s even a logging feature to help identify how browsers are attempting to access site resources.
Collaborative Workflow
Developing web products is rarely a one-person effort. Design and development is commonly separated into two roles. Even when it’s not, it’s still useful to privately review your work with others before publicly releasing it.
Fenix features the ability to share local sites immediately, securely, and temporarily. With one click, SSH tunneling will proxy your local server to a privately assigned (HTTPS) URL. There’s even a copy link that can be sent to collaborators. Presto! Your laptop is now a public web server. Possibly even a few if you share multiple sites at once.
All of this can be seen in action on YouTube.
Beating Web Flow Woes
These days, the line between client-side and server-side development is blurred. It’s hard to do one without the other in some capacity. Fenix web servers simplify client-side workflow by providing more power on localhost, but what about server side development?
In the same way Fenix focuses on relieving some pain in client-side development workflow, it also relieves some pain in server-side development with it’s webhook handling capabilities.
The native “Request Browser” allows inspection of real data payloads:
Fenix receives webhooks from cloud providers, but a key workflow feature is the ability to “unshare” the request browser. For the “wears-every-hat” developer that’s responsible for end-to-end creation, this means you can produce your own webhooks locally and inspect them without requiring an internet connection. The spotty-wifi train ride into work can now be more productive.
There’s a short video walkthru available if you want to see this in action.
Why Webhooks?
The overwhelming abundance of cloud services has introduced a fantastic but often “puzzling” approach to developing web products. Many web applications are a collection of different backend cloud services carefully pieced together to form a whole, all wrapped up in a nice looking design. Many cloud services use webhooks as a way to stitch services together.
For the unfamiliar, a webhook is just an HTTP request. When you type a domain into your favorite browser, you’re actually sending an HTTP GET request. There are other kinds of HTTP requests, like POST, PUT, DELETE, and more. Webhooks are an automated way of creating one of these requests, but instead of sending from a browser, they’re sent between servers.
Webhooks are commonly generated by cloud providers when their system completes a task. For example, a credit card transaction service may send an HTTP POST request to your server when a customer’s card is charged. The webhook acts as a signal, indicating the cloud service has completed its task. What your server does with the information it receives is up to you.
Cloud providers are not created equally. Documentation can vary substantially from service to service. Even the best services sometimes struggle to keep documentation up to date. As a result, it can be tricky to know exactly what format or data a webhook is actually delivering. Fenix shows you exactly what is being sent.
Get Geeky on the Console
Fenix CLI is an add-on that brings management capabilities to the command line. The utility is merely an effort to simplify workflow for those who spend a lot of time on the console.
Launching a new server is as easy as:
$ cd /path/to/site$ fenix startOR$ fenix start /path/to/site
Of course, there are many other options as well, including all of the major “push button” actions found in the primary Fenix application.
There’s another video walkthru available if you want to see this in action.
You can read up on all features of Fenix atfenixwebserver.com or check out the project on Github. File issues or suggestions in the issue tracker.
