1.4. How does Scalatra compare with other Scala web frameworks?
Scalatra isn’t your only choice when it comes to HTTP development in Scala. Other popular frameworks include Lift
and Play. Of these three, why would you choose Scalatra? It comes down to trade-offs in several main areas: application
development style, the aforementioned microframework versus full-stack approach, and deployment.
1.4.1. Scalatra is a lean MVC framework
Let’s consider Scalatra versus Lift first. Unlike the other frameworks, Lift doesn’t use the popular
model-view-controller
(MVC) pattern for organizing code. Instead, it offers a
view-first
approach, which many
programmers aren’t familiar with. Whatever the merits of view-first versus MVC, sometimes familiarity is a big
win, especially if you’re coming from another MVC framework.
Both Play and Scalatra, in contrast, use the more popular MVC pattern. With Play, you get a larger and more featureful
framework than Scalatra. Play favors convention over configuration, so it seeks to decrease the number of decisions
you’ll typically need to make. Stay on the happy path, and it arguably provides more initial development speed
than Scalatra.
But if you stray from Play’s application structure or library choices, you may find yourself wanting more flexibility.
Scalatra gives you the freedom to curate every library choice and be in complete control of your application’s
structure.
The other main thing to consider is how you’ll host your application when it’s built.
1.4.2. Scalatra runs on servlets
Once you build your application, you’ll need to deploy it to a server in order to make it available to the world.
Lift and Scalatra are both designed to be deployed in standard Java servlet containers: Tomcat, JBoss, and Jetty
are popular examples. Play, on the other hand, deploys on newer technology: the Netty network application framework.
Again, there are various pros and cons to consider.
Netty, which uses the new Java NIO APIs, is a relatively fresh technology and is theoretically more performant.
But the subject is complicated, with Netty winning against servlets for some workloads and losing for others.
In contrast to Netty, servlet containers aren’t sexy, but they’re battle-hardened and have great tooling.
Additionally, many people know how to configure them, tune them, and keep them running in production.
One last consideration: many workplaces still mandate servlets for web deployments. In these cases, the ability
to deploy on servlets may be make-or-break for Scala adoption.
We hope this is enough to provide a fair overview of possible choices. Now let’s write some Scalatra code.
How much Scala do you need to know to read this book?
We write this book under the assumption that Scala is a new language and that there aren’t many Scala programmers
yet. We suspect that we’ll need to teach you a bit about Scala at the same time we teach you Scalatra. We know
how daunting it can be to be suddenly thrust not just into the land of Scala, but also into the world of the JVM,
if you’re coming from another environment. We’ll provide a well-lit path for you.
At the same time, Scala is a large language with many concepts that may be unfamiliar to you. Unfortunately, we
don’t have enough room in this book to provide a full language reference. You should get a copy of
Scala in Action
(Manning, 2013) to read alongside this book if you haven’t yet read an introductory book on the Scala language.
1.5. Installing Scalatra
Before we can move on to the rest of the book, you’ll need to have a running installation of Scalatra. You can
find installation instructions in the appendix. It includes full instructions for getting Scalatra installed and
for setting up your development environment. If you haven’t yet installed Scalatra, take some time now to get set
up.
Once you’re ready, let’s generate, build, and run a traditional Hello World example. The first thing you’ll need
to do is generate an application skeleton. How does project generation work?
我的内容管理
展开
