Mojo Wonk Blog.

A semi-offical blog dedicated to the Mojolicious web framework

Day 8: Mocking a REST API

Two crash test dummies

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...

Day 7: Using Template Variants For a Beta Landing Page

Single yellow tulip in a field of red tulips

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...

Day 6: Adding Your Own Commands

Space shuttle Atlantis prepared for liftoff (night)

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...

Day 5: Your App's Built-In Commands

Space shuttle Atlantis liftoff

I mentioned at the outset of this series that Mojolicious applications are more than just web servers. I then showed how you can start a web server using the daemon or prefork commands. In the previous post, I mentioned an inflate command that can help you with growing your app from Lite to Full.

But there are other commands, built right in to your app, that can help you be more productive right away!

Continue reading Day 5: Your App's Built-In Commands...

Day 4: Don't Fear the Full App

Arucaria trees in Curitiba Brazil

One of the most common misconceptions about Mojolicious is that there is a large difference between the declarative "Lite" apps that we have seen so far and large-scale structured "Full" apps. Nothing could be further from the truth. Mojolicious::Lite is a very tiny wrapper around the so-called "Full" app architecture, giving it the approachable keyword syntax.

Because it is much nicer to have concise single-file examples for documentation most of Mojolicious' documentation uses Lite syntax most of the time. It is understandable that people worry about migrating (or as we call it "growing") even once their apps would benefit from Object-Oriented structure; after all the docs seem geared towards Lite apps. However, let those fears go, the transition is easy. And once you understand it, the documentatation examples are trivial to translate.

Plus, Mojolicious comes with two forms of help when transitioning. The first is the Growing Guide which covers everything this post will but from the perspective of porting an existing application (which I won't duplicate here). The second is the inflate command which can even start you on the process by moving your templates from the data section and into their own files.

That said, in order to futher demystify things, I'm going to cover some of the differences and pull back the curtain on the Lite syntax itself.

Continue reading Day 4: Don't Fear the Full App...