Writing an API can be as easy as taking the results of some database query and presenting it to the user. A more advanced one can often present the data in one of multiple formats. The user can then specify which format they want.

JSON is currently the most popular format for new APIs. XML is another common one and was certainly king before JSON hit the scene. An API might choose to make an HTML format of the data available, whether in some representation of the data or to render documentation about the API itself. Of course there are many others.

Mojolicious believes in Content Negotiation, as it is called, and supports it throughout the stack. Mojolicious makes it easy and convenient for users to pick a format they would like. Similarly it makes rendering the different formats easy on the site author, as you would expect.

Continue reading Day 10: Give the Customer What They Want...

Ok so it is a bit of a click-bait headline. But that doesn't mean I don't believe it.

Test::Mojo is a test framework for websites and related technologies. While its true that there are many such tools, this one gets its power comes from combining so many of the tools that Mojolicious provides. A full non-blocking web server, including websockets, an event loop, an XML/HTML DOM parser, JSON parser and emitter, and more all come together to make incredibly detailed testing simple. Further, with the recent additions in support of roles (which will be discussed in a future post), Test::Mojo is becoming an extensible testing platform.

In this article, I'll give a quick overview of how to use Test::Mojo and some of its methods. Rest assured you'll see more of it as the series continues.

Continue reading Day 9: The Best Way to Test...

One of my applications is a pure-JavaScript UI for a JSON API. This UI is an entirely different project that communicates with a public API using an OpenAPI specification.

Our public API is huge and complex: To set up the public API, I need a database, sample data, and three other private API servers that perform individual tasks as directed by the public API. Worse, I would need to set up a lot of different test scenarios with different kinds of data.

It would be a lot easier to set up a mock public API that I could use to test my UI, and it turns out that Mojolicious makes this very easy.

Continue reading Day 8: Mocking a REST API...

CPAN Testers is a pretty big project with a long, storied history. At its heart is a data warehouse holding all the test reports made by people installing CPAN modules. Around that exists an ecosystem of tools and visualizations that use this data to provide useful insight into the status of CPAN distributions.

For the CPAN Testers webapp project, I needed a way to show off some pre-release tools with some context about what they are and how they might be made ready for release. I needed a "beta" website with a front page that introduced the beta projects. But, I also needed the same Mojolicious application to serve (in the future) as a production website. The front page of the production website would be completely different from the front page of the beta testing website.

To achieve this, I used Mojolicious's template variants feature.

Continue reading Day 7: Using Template Variants For a Beta Landing Page...

Everyone has written those one-off administration or check scripts. There are probably a few cluttering your project root or bin directory right now. Those have a problem beyond just the clutter: duplication.

Programmers hate duplication because of skew. If code gets improved in one place, it is unlikely to be improved in all places, unless there is only the one. So that script you wrote a while back, the one with the database connection you hand-rolled, is that still correct?

In the previous article in this series I talked about the built-in commands available to your application. The final command was eval. I mentioned that when combined with predefined behaviors, the command could be great for administrative tasks. That's true, but you need to know what to eval in order to do so.

To formalize that process, we can go one step further: defining our own commands. By doing this your application's administative behaviors can take arguemnts and provide optional switches as well as give usage messages. In this way these administative commands decouple themselves from knowledge of the application's internals and become useful to a broader set of users.

Continue reading Day 6: Adding Your Own Commands...