Our company has been developing software for more than 12 years. And around a half of our projects are high-load multi-threaded distributed systems. Therefore, our developers use state-of-the-art technologies and latest frameworks in the process.

In this article, we will focus on two recent frameworks mentioned Play, and ASP.NET Web API.



Play Framework

Lately, much attention was paid to Play Framework 2.x. It has already been three years since Redwerk first implemented Play for Java. Having extensive experience with Play, we will try to present you a short but comprehensive overview of all the advantages of this framework.

Play’s developers describe their framework with one phrase: «The High Velocity Web Framework For Java and Scala». Today this framework is considered as a full stack one and consists of several “layers”.

Tools For Deployment And Dependencies Management

Just like Django, Ruby on Rails and other multifunctional frameworks, Play comes with a set of utilities united in TypeSafe Activator, a service for management and creation of Reactive apps. Activator includes simple build tool, quick-start GUI and a catalog of ready-made templates of applications.

Its main features are:

Incremental compilation

Built-in code documentation system

Template and plugin system

Built-in web server for development

Wide functionality of debugging

Excellent framework for Specs2 unit tests creation

Full support of RESTful services development

Management system of code dependencies

Integration with leading IDE

We also want to point out an opportunity to set auto update for chosen plugins in config version of Activator and Scala as well as the great variety of available plugins. Both Scala and Play work on Java platform, so all the external dependencies are pulled from a standard Maven repository. Sure thing, you can add custom repositories too.

HTTP Netty Server

Play developers no longer use JEE model along with servlets but rather opt for Netty which is an advanced NIO network server. As a result, Play represents a web-layer that does not store or share the state (stateless web tier), which is very important for high-load multi-threaded web services. Besides, the framework supports latest technologies like Non-blocking I/O and Real-time communication support (Websockets, EventSource, Comet). Moreover, Play provides a very flexible configuration options including thread pools: a number of workers and parallelism factors.

We would also want to point out that Play represents a full set of tools for reactive apps creation using Akka Framework that is built on green threads concept and has Actor and Future notions at its core. That is why a whole chapter of documentation is dedicated to the method of non-blocking code development. There are descriptions of the main cases of code blocking like DB, 3d party API request, work with files and CPU intensive operations. This is done to help developers minimize the usage of blocking code in his projects.

Data Model

OOB Play has a built-in ORM framework EBean. We used it in our projects several times and were very satisfied with the results. It is much easier than JPA and its realizations like Hibernate both in learning and development. Besides, Play comes with the built-in mechanism of migration DB scheme «Evolutions» that proved to be a fantastic solution. In an app, it automatically monitors the conf/evolutions/ folder concerning new scripts of DB upgrade-downgrade scheme (*.sql files). When new evolution is detected, the framework asks the developer whether a new evolution should be rolled up or not. To help the evolution script work, the developer has just to click on «Apply script». Everything mentioned above ensures data validity, and correspondence between code and data model. It is paramount, since modern development normally takes place in several branches, and one has to switch between them very often.

Note that thanks to module structure, you can easily use outside ORM frameworks like Slick which is top recommended DB library for Scala. Slick is a fantastic framework, since instead of HSQL requests or tons of annotations for working with DB. It uses native Scala code. Thus, a selection from DB with filters is similar to the code that works with a simple collection like List or Map. More details about slick you can find in their official documentation here

Play Web API

When we first started using Play Web API, we expected to see a great variety of filters, tons of annotations, complex routing, XML configs and exceptions with many unnecessary lines like in Spring Framework. But to our joy, it was all different. Leave all your worries behind, as it is all in the past now.

First things first – Play Framework 2.x is written in the Scala programming language which is a huge step already. Just take a look at an extensive list of companies using Scala in the production environment.

Play core is built on two other cutting-edge frameworks: Akka actors and Netty network stack. Both developers stick to the functional development style and leading techniques like state immutability, event-loops, message passing, behavior composition, first class functions. That is why Play is one of the most progressive frameworks thanks to its features and operation speed.

Route mechanism in Play is quite simple yet of the highest quality. All the routes are gathered in one conf/routes file. Config format is as follows: controller and its method, URL it binds to and a list of required parameters with their data types. You can also specify unnecessary parameters.

Play Scala templates. Play’s developers did not create a separate language for templates or tag libraries. This allowed them to comprehend and start using Scala templates when developing responsive HTML pages. General principles were borrowed from the ASP.NET Razor technology. We tend to think that it’s better to use a declarative approach to code development for the view. But we have to admit that Scala Templates Engine is packed with powerful and flexible solutions like blocks, implicit form field decoration, and view compositions.

It is also worth mentioning that OOB Play offers JSON and XML content support. JSON support was realized using Jackson library. It’s important that XML support is not as great as that of Spring MVC, so you will have to use outside libraries. XML format is rarely used for communication in new projects, and data is serialized / de-serialized in JSON.

Taking everything mentioned above into account, Play can be called an almost perfect candidate for development of REST API service, small portal or a high-load Web service. In the case of the latter, you can always use Akka Cluster and the necessary number of GCD for traffic maintenance.

We believe that advantages are as follows:

Simple RESTful framework

Module structure with an opportunity of simple dependencies management

Various OOB opportunities: ORM, job scheduler, validation, SMTP mail, JSON and XML support, DB evolution support, auto file upload, SSL support, etc.

Built-in framework for tests

Full support of reactive technologies, stateless controllers

Powerful template framework

uncompromising performance

simple acquisition and configuration

support of several configurations both for development and deployment in the production environment.

But we’d also like to mention a few disadvantages:

Long project compilation process due to rather slow SBT

Poor support of Windows as an equivalent development platform

The experience of using Play Framework has shown that it is one of the most promising and highly-efficient universal frameworks. Java/Scala developers of Redwerk company recommend using a combination of Scala + Play + Slick + Akka for new projects like Rest API service or high-load portal.

ASP.NET Web API

Let’s try to find an alternative way of developing web services based on .NET for Windows. Previously when we wanted to develop RESTful web service using MS .NET tools, we could either go for ASMX web services or implement REST with the aid of WCF technologies. But now after the release of a new version of the .NET platform, 4.5, a developer got a new tool for RESTful services development — ASP.NET Web API. It’s a framework for WEB built upon the HTTP allowing the development of REST services using common conventions and similar software concept in a fast and convenient way. The essence of a new framework is innovational to the .NET platform in general, but it was previously implemented in numerous web-frameworks like Django, Lift, Play Framework, Ruby on Rails, Spring Framework, etc. We also want to point out that Web API is not a universal structural framework like the ones mentioned above. It is customized specifically for REST. That is why we’ll try to compare it to Play Framework in the upcoming part.

Let’s take a closer look at the tech side to see the main improvements. Since the framework is rather small, we’ll give you the examples of code for better understanding.

The General Structure Of .NET Web API Project

Project based on .NET Web API template can be developed via Microsoft Visual Studio menu by adding it into an existing solution. As a result, we’ll get an MVC-project with a standard structure. By default, two controllers will be created. They will be different from regular controllers since they use the basic ApiController class that is not connected to a regular basic Controller class. Controllers can utilize the REST stylistics with the support of GET, POST, PUT, DELETE methods. There are no standard methods of controllers that return ActionResult. Here is an example of an autogenerated code:

public class NumbersController: ApiController { // GET api/numbers public IEnumerable < string > Get() { return new string[] { "number1", "number2" }; } // GET api/numbers/5 public string Get(int id) { return "number"; } // POST api/numbers public void Post([FromBody] string newNumber) {} } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class NumbersController : ApiController { // GET api/numbers public IEnumerable < string > Get ( ) { return new string [ ] { "number1" , "number2" } ; } // GET api/numbers/5 public string Get ( int id ) { return "number" ; } // POST api/numbers public void Post ( [ FromBody ] string newNumber ) { } }

Routing In Web API

Since class methods are mapped to relevant REST request types with an indication of HTTP method, URL format, and content type, routing along with controllers are not standard. A list and definitions of routes for Web API controllers can be found in WebApiConfig.cs file in the App_Start folder.

Let’s have a look at an example of such file:

public static class WebApiConfig { public static void Register(HttpConfiguration config) { config.Routes.MapHttpRoute( name: "MyNewWebApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } } 1 2 3 4 5 6 7 8 9 10 11 12 13 public static class WebApiConfig { public static void Register ( HttpConfiguration config ) { config . Routes . MapHttpRoute ( name : "MyNewWebApi" , routeTemplate : "api/{controller}/{id}" , defaults : new { id = RouteParameter . Optional } ) ; } }

As you can see from listed above we defined one route. The first parameter is the name of the route, second one is the controller mapping, the third one is a specific object id (3rd parameter is optional in this case).

Additional Web API Features

To demonstrate all possibilities of the framework, let’s take a look at an example of a more complicated controller:

public class BooksController: ApiController { [Queryable] public IQueryable < Book > Get() { return new EnumerableQuery < Book > ( new Collection < Book > { new Book { Id = 1, Title = "Tittle1" }, new Book { Id = 2, Title = "Tittle2" }, new Book { Id = 3, Title = "Tittle3" }, new Book { Id = 4, Title = "Tittle4" }, new Book { Id = 5, Title = "Tittle5" } } ); } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 public class BooksController : ApiController { [ Queryable ] public IQueryable < Book > Get ( ) { return new EnumerableQuery < Book > ( new Collection < Book > { new Book { Id = 1 , Title = "Tittle1" } , new Book { Id = 2 , Title = "Tittle2" } , new Book { Id = 3 , Title = "Tittle3" } , new Book { Id = 4 , Title = "Tittle4" } , new Book { Id = 5 , Title = "Tittle5" } } ) ; } }

You can see from the code above that now we can return a collection of instances from the controller. Moreover, IQueryable class and controller method attribute [Queryable] is a part of a new OData library. Application of this library lets us create requests with a type collection filter.

http://localhost/api/books/?$skip=25 http://localhost/api/books/?$skip=25&$top=10 http://localhost/api/books/?$filter=(Id gt 20) and (Id lt 50)&$orderby=Id desc 1 2 3 4 5 http : //localhost/api/books/?$skip=25 http : //localhost/api/books/?$skip=25&$top=10 http : //localhost/api/books/?$filter=(Id gt 20) and (Id lt 50)&$orderby=Id desc

I believe there is no need to explain what the first request does.

However, unfortunately, as it often happens with Microsoft, apart from numerous syntax goodies and great innovations, there is a tiny flaw. For now OData library does not contain count parameter in response, therefore, it’s problematic to build fully functional pagination based on UI. Developers will need to adjust several library classes according to their requirements. You can find how to do it here.

Conclusion

.NET Web API framework is an excellent tool for .NET developers. This framework allows them to create more flexible services and much easier application architecture, and at the same time utilize all the .NET platform advantages in the code. It also simplifies the development and testing of the REST apps in general.

Comparing the opportunities of Play Framework and .NET Web API, you get to see that the first one is more powerful and implements all the leading technologies of the asynchronous request processing. Play Framework is a structural framework, so it contains various features for all intents and purposes. .NET Web API framework in its turn is tooled specifically for REST structure but also allows to use all the .NET platform features.

Talking about the efficiency, Play Framework with Netty server is several steps ahead of most frameworks including .NET Web API. Among other advantages of .NET Web API, we would like to point out wide opportunities of OData library OOB – request parameters that ensure data filtering and data collection navigation.

It’s up to you to decide what technology to use. Redwerk employees have decades of experience in development and maintaining projects both for .NET and J2EE platforms. So, whatever technology you would choose, our specialists can guarantee the highest quality of work within the reasonable timeframes.

About Redwerk

Redwerk is an outsourcing IT company which has been delivering high-class software products around the world for over 13 years. Our offices are full of outsourcing software developers highly experienced in working with various mobile, web, desktop and cloud technologies, with Scala software development as one of our main directions. And our ASP.NET development experts implement client-server solutions of any complexity. Contact us if you can’t decide which technology you want to use for your project. We will help you create a custom product regarding all your requirements.