Wednesday, February 29, 2012

Neo4J with Scala Play! 2.0 on Heroku (Part 9) :: Final

Note

This post is a continuation of this post (which started there), which is the last part of a blog suite that aims the use of Neo4j and Play2.0 together on Heroku.

What have been accomplished so far:

  • install Play 2.0
  • install Neo4J
  • use Dispatch
  • create model
  • create persistence service in Neo4J
  • create views and controllers
Ok, where almost done. Let's see how to deploy the whole app on Heroku.

Heroku, here I come

But wait, who're you?

Heroku is simply one of the best cloud players of the moment, I won't talk too much about it, because i'd have to talk a lot otherwise.

But here are some very interesting features and paradigms followed by Heroku.

Process Centric

Where almost all other cloud providers are binding their services to server instances, CPU flop count, memory usages, and other similar metrics, it is a fact that their aren't easily forecastable and hard to track in development phases (even if I encouraged to do it, though).

Heroku comes with a much more easy concept, that is, Web Dynos. A Web Dynos is simply a process that can handle requests. So, what if the requests are too numerous? Just add Dynos. Note that Dynos are existsing for background process, one Dyno by worker.

Costs are very simple too, you have one free Dyno by month, and the rest is billed at low cost by hour.

Thanks for simplicity.

Remote CLI

We've just ask how to handle more requests in an efficient way, and answered by adding dynos.

So far so good, but how? That's where comes the Heroku remote CLI that is able to operate remotely on a deployed application behavior.

Thus, adding a dyno is doing that in console : $> heroku dynos 1

Now, alerts on performance are quickly resolved.

Thanks for rapidity.

Continuous Deployment

The paradigm followed by Heroku to deploy their app are based on Continuous Deployment.

Having that, you app should define how you app must be deployed using their Procfile.

And it will be deployed automatically when the sources are pushed to the Git repo that is created for each application.

This ensure you to at any time be able to retrieve the sources related to the running instance (for example).

Thanks for debugging ease.

Add-Ons

What to say? A good sdk to create add-ons, a good architecture and service level. It makes a pleiade of powerful add-ons including Neo4J running instances.

Thanks to be open.

Can I Play! with Heroku?

Of course, you can!

Actually, Heroku has already integrated Play! starting with its first version, and has also added the scala support some time ago.

And finally the Play 2.0 wiki is explaining how to do...

Ok, let's Go then.

Getting started

First of all, you must have been registered too Heroku. Hopefully, it's free and fast. So go on, and create your account here

Having your account, you can now install the Heroku toolkit belt. This will gives you acces to your Heroku CLI that can manage your account, apps, and app configuration.

When you're done with the installation, you just have to login using the console command: $> heroku login

Play! app side


What is needed for your app is to have a Git repo and to contain a Heroku process description file.
Since everything is already explain there, I won't go into deep details.

Create Heroku app

Since we are using Play! and scala, we need a JVM, that stack at Heroku is called Cedar.

So, to create your app, open a shell and do the following:
heroku create my-playing-app-with-neo4j --stack cedar

Now, you have an up and running environment to setup and deploy your application. And the application will be named my-playing-app-with-neo4j.

Neo4J add-on

Ok, but I've to use a Neo4J database, not embedded (too heavy for a cloud). Do I have to install it somewhere and host it myself. Na!

Neo4J's team is actually working on an integration in the Heroku platform, and a beta test add-on is available at the time writing.

That says that to have a running database that we can use, we just have to open a shell (in our app folder) and drop the following command: heroku addons:add neo4j 

You don't believe it, huh?

Since you'll need to retrieve the database url and credentials, either you go to the Heroku site and...
Na, just keep your shell and do: heroku addons:open neo4j 

Ta da!

App update

In my previous post, for the sake of simplicity I left the Neo4J database hard coded to localhost:7474.

But now, we have to update this to use our deployed Neo4J instance and credentials.

We should have (must) define an application configuration property for such paramater, but It is not what I want to illustrate here so let's keep it simple and hard coded.

But we have to add something to the Neo4J's Dispatch url, the credentials. For that we just have to do the following:

SSH key

Just a note, to remember you to add your ssh key to Heroku. This is simply accomplished (after you've have created 'em) using the CLI: $> heroku keys:add

Beginning to love this CLI, no?

Procfile

This is the Heroku configuration file that tells the continuous deployer (if I can say) how the application will be deployed and are its needs.

This file is located at the root of the Play's application folder and only contains one line:
web: target/start -Dhttp.port=${PORT} ${JAVA_OPTS}


This simple line tells that we need a web process for the staging application located under target/start
Actually, this folder will contains the staging Play! application after Heroku will run sbt clean compile stage on it.

Aaaaand Deploy! (push)

Getting closer to the end!

After having added all the necessary sources to the local git repo for your app, (including last update and the Procfile), we can now commit everything and push it to the git repo that Heroku holds for our application.

Actually, when created the Heroku app, the CLI has updated the git local configuration to add the related remote repo called heroku.

So, the only thing that left to do is to push: $> git push heroku master
To test if it is ok: $> heroku ps. This will display the proceses running on Heroku.

If the process is shown, let's open the application in our default brower (leave your mouse alone and...):  $> heroku open.

I hope that I didn't made too many mistakes and you are now able to see your application running and using Neo4J.

At least, here is the one I succeed to deploy: http://scala-plays-with-neo4j.herokuapp.com/.
I've also shared this app on Heroku's GenSen that is meant to share project template on Heroku.


Now, you should love the CLI, but also Heroku, and Neo4J and Play! 2.0 and Scala and Dispatch and arbor.js and...



Thanks for reading, if someone do have ^^.

Monday, February 27, 2012

Neo4J with Scala Play! 2.0 on Heroku (Part 8) :: Scala template+Arbor.js to browse Neo4J via Play 2.0


Note

This post is a continuation of this post, which is the seventh part of a blog suite that aims the use of Neo4j and Play2.0 together on Heroku.

Viewing Neo4J Model Object in Play2.0

Goal

In this post, I'll talk about some functionalities that Play2.0 offers to create web application/site.

The main goal will be to have html views that enable us to create User, Group and link them, but not only, we'll use arbor.js to view what's being created or linked in Neo4J as a... graph of course.

Basically, it will consist into one html page, containing several forms for creating model instance (or link) through AJAX call on Json controllers.

So let's begin by explaining how to define a querying and persisting controllers using Play 2.0 Form.

Controllers

In that case, we'll take basic needs for our use case, that is, to retrieve the users list stored in Neo4J or create a new group.

Get Users

Briefly, Play 2.0 as the notion of controllers to handle server request, such controllers are bound to urls using a route configuration.

So what we have to do here is to create a controller, let's say Users, with a handler named j_all for list of users rendered in Json.

Using what we've discussed in previous posts, such controller and definition are rather simple, check this out:

As we can see, we have simple call the Model persistence utility object to retrieve all defined User in Neo4J. Which we are rendering directly in Json thanks to their Formatter. And finally, we stream the result in the http response.
Mmmh, simple no ? Here we did:

  1. send a Json request to Neo4J requesting all nodes that are linked to the root using the kind users (found using the User's ClassManifest)
  2. retrieve the Json response from Neo4J and un-marshall them in a List[User] (using the User Formatter)
  3. re-render them into the expected Model Json Format (again using the Fomatter)
  4. generate the String representation
  5. append it in the response body
  6. define the content type as being Json
In one single line.

To test it, roughly, just use this url http://localhost:9000/users.json. This will return a Json encoded response.

Create Group

Now, we want to add the possibility to create a new group remotely. For that, we'll create a controller Groups which defines a create handler.

This handler expects to receive a group name. After what, it creates the group instance and persist it in Neo4J.

To recover such request parameter (in a POST since we are creating something and changing the server state), we use a Play 2.0 construction play.api.data.Form that offers a lot of helpers to parse the body into a map of values (can be embedded).

In the following example, the goup name is extracted form the request's body (url encoded) as a nonEmptyText mapped as name. This is a helper mapping for extracting String that cannot be empty.

As we can see, the Form can be directly rendered in the Model instance by giving an apply and unapply functions after the mapping definition.

Javascript Routing

Using static urls are cool... no ok, let's try to use what some calls Web 2.0, you know Ajax.

The problem comes when you have to deal with Urls within Ajax calls. How to keep track of your urls changes for instances.

Pretty hard, so let's forget about hard coded urls in your javascript and use a routes file that can be downloaded client side. This routes file contains all your controllers' url mapping that you want to be exposed in javascript (if I can say).

How it works is simple:
  1. Use Routes.javascriptRouter to define a javascript object and the controllers to be remoted
  2. For each of them, you must use the following object controllers.routes.javascript..
  3. This object is created at compile time when defining the controller in the route conf file
  4. defines a handler (in the Application controller f.i.) that return the result of the javascriptRouter as being javascript file
  5. route this new controller to what you want (like /js/routes)
Having done that, you are now ready to use the created object in the javascript part.

If we take the controller controllers.Users.j_one (returns a User base on its given id), we'll have in our javascript access to a js function playRoutes.controllers.Users.j_one(id) that can takes an id.

By using this js function, you'll have in return a js object that defines at least two useful properties:
  • url: the formatted url for the controller (having compiled the parameter in the url)
  • ajax(c): a jquery (by default) ajax function that takes a payload object, but already defines the url and the method.
So far so good, but to use all of these stuffs, let's see in a coffeescript (thanks Play 2.0) example:

In the previous example, I wrote the ajax call my-self using jQuery... so I could have simply use the ajax property. But nevermind, I love sometime to be control freak.

C'est chic! No?

Arbor.js

For browsing our model graph, I've used arbor.js as the rendering framework, because it's the best one for graph... that's it. 
Since my intent here isn't to explain it, I'll leave you alone with that part. But I recommend you to browse its site here.

So what I did is simply using Users as nodes, all linked to a central root node. Clicking one them will show you their inter-relationships.

I've also added a select box that helps you showing all users in a chosen group.

Taking that the next post will be on how to deploy the whole stuff on Heroku. I don't have at this time any instance in the wild, but if you wish you can clone (and fork) my repo on github for this posts' suite.

But here is a preview of what has been achieved.
Fun but not so cute  -> I'm not a designer... :'(


Next post, the last, will talk about how to deploy this whole thing onto the Heroku PaaS.

Saturday, February 25, 2012

Neo4J with Scala Play! 2.0 on Heroku (Part 7) :: DSM+DAO+Neo4J+Play


Note

This post is a continuation of this post, which is the sixth part of a blog suite that aims the use of Neo4j and Play2.0 together on Heroku.

Using Neo4J in Play 2.0... and simple DAO

What I'll intent to show is a way to use a Domain Specific Model, persisted in a Neo4J back end service. For such DSM, we'll have an abstract magic Model class that defines generic DAO operations.

For simplicity, we'll try to link each category of classes to the root/entry node. For instance, all the Users will be bound to the entry node by a reference of kind user.

Model

I'll choose the very common use case, that is, Users and Groups. Here is its shape:
  • A User has a first name
  • A Group has a name
  • A User can be in several Groups
  • A Group can contain several Users
  • A User can know several Users
Let's keep the classes definition aside for a few, and stick to the persistence service.

Graph Service

The Graph Service is an abstraction of what is needed for a Graph Persistence Layer. It is bound to a generic type that defines the model implementation and defines traversal and persistence operations of graph's nodes.

Graph Service for Neo4J

Let's update now, the service that has been used in the previous post, for Neo4J persistence, in order to have it able to deal with model instance.

Let's start with the saveNode operation to see what is needed in the model and elsewhere.

In this Gist above, I've enlighted some points that must be found around the Model construction. (A) and (C) are composing a Json Format (as SJson propose), (B) is more related to model abstraction.

(C) has a special need when used with Dispatch, we could have a Dispatch Handler that can do both action parsing/unmarshalling and direct use in a continuation.

Model

Now, we are at the right point to talk the Model, since we've met almost all its requirement. So let's build a Magic Model class that can be extended by all concrete model classes.
Skeleton
That's the easy part, we just define the id property that is an id (part of the Rest Url in Neo4J).
Formatter
Ok, this part is simple too in this abstract Model definition because, a Format implementation must be part of the concrete DSM classes. That is, User that extends Model must define a Format[User] instance, and put it in the implicit context.
So, at this stage we have Model and User like this:

Class -- Relation's kind : F-Bounded
As we saw in the saveNode method needs to associate the concrete class to a relation kind. But what I wanted is to have a save method in Model, that implies that we cannot (at first glance) give the saveNode the information needed, that is the concrete class.

For that, we'll use a F-Bounded type for Model, that way we'll be able to give the saveNode method what is the really class... Mmmh ok, let me show you: But that's not sufficient, the saveNode method will need to use such available ClassManifest to find the relation it must create.

I choose a very common and easy solution, which is having a function in the Model companion that helps in registering classes against relation kind.

Model Dispatch Handler

Now we'll discuss something I find really useful and easy in Dispatch, create a Handler that can handle a Json response from Neo4J into a Model instance.
For that, we have already defined in previous post a way to handle json response into Play's JsValue.

Now, what we need is to use the implicit formatter of all model concrete classes to create instances. And it'll be the way to reach the goal, except that a problem comes from the Json response of Neo4J: the data is not present at the Json root, but is the value of the data property.
So it breaks our Format if we use it directly.

That's why the above definition of the Handler takes an extra parameter which is the conversion between JsValue to JsValue, that is to say, a function that goes directly to the data definition.

saveNode

Finally, let's gather all our work in a simple implementation of a generic saveNode function: As we can see, it's very easy to handle Neo4J response as DSO and use them directly in the continuation method of the Handler.

Usage

having all pieces in places (check out the related Git repo here). We can now really simply create a User and retrieve it updated with its id, or even get it from the database using its id.

In the next Post, we'll create some Play template for viewing such data, but create them also.

Tuesday, February 21, 2012

Neo4J with Scala Play! 2.0 on Heroku (Part 6) :: Dispatch+Play 2.0

Note

This post is a continuation of this post, which is the fifth part of a blog suite that aims the use of Neo4j and Play2.0 together on Heroku.

Using Neo4J in Play 2.0

In this post, we'll create a Dispatch Handler that handles Neo4J Rest Json calls in Play's Json object.
Having this in our hands, we'll be able to create a really simple service for dispatching Neo4J operations and use them in Play's views.

I've compiled the Play app on github, fork me.

NB: we'll use Dispatch but in case you wish to, you could use the Play's WS feature that might help you a lot (check this out).

Declare Dispatch deps

First of all, we have to update our Play app with the Dispatch dependency. For that, we have to update the sbt configuration file in order to add the related line.

Now, that we have updated the project, let update the application by reloading the configuration (if you're already in sbt console) and rebuild our IDEA project.


Play's Json Handler

Our goal is to use the Neo4J Rest Api that returns responses Json encoded.
So here, I'll show how we could have such response directly unmarshalled in Json object. In further posts, we'll use such handling feature to get Model instances directly (which is far more interesting).

What is necessary for that is to create a piece of code that is capable to take a subject and convert it to a JsValue. And since we love functional programming, let us have this method taking a continuation that accepts a JsValue.
In this listing, we see that we use the text parser to consume the response payload, then we ask the Play's Json parse function do its job.
Finally, we use the continuation applied to the parsed result.

Neo4J Service

Let's gather some utility urls to retrieve node, relations. In other words, urls for common usages. This service is left simple for further enhancements (next post). We see that most functions are there to create urls based on ids, but there is also the root one that directly fetches the entry node.

A Controller To Rule Them All

For the sake of this basic usage of our Handler with Neo4J, here are some examples of such requests. (full controller here).
As we can see, all we had to do is to create the correct url by using id, or Neo4J path conventions, then using the Handler operator ( >! ... how it's Play, no ?!), we have the facility to use directly JsValue instance to consume the result.
Okay, it's repetitive and the Json traversal is not shared. Let's us put this aside until the next post.
And before going ahead, I've created a pretty simple and naive view and url mapping. So check the sources on github, play it and tests the /rest et al. urls.

Next post: Enhance the handler and service to manage Domain Object.

Sunday, February 19, 2012

Neo4J with Scala Play! 2.0 on Heroku (Part 5) :: Dispatch

Note

This post is a continuation of this post, which is the fourth part of a blog suite that aims the use of Neo4j and Play2.0 together on Heroku.

Intro

In this suite, we're gonna use Neo4J graph database through its HTTP REST api, which is quickly introduced in this post.
So that, we'll have to communicate with the server using HTTP, here comes the Dispatch scala library.
Neo4J uses Json as the resources representation, we've already discussed this subject in Play 2.0 in this post.
How to stick them together will be discussed in the next post.
Here we'll concentrate on some introduction to Dispatch's DSL for making HTTP requests and on a powerful abstraction of the body parser, that is, the Handlers.

Dispatch

The DSL

Dispatch is a very powerful library for communicating through the HTTP protocol, offering a DSL for making such queries, but also for using their responses.
Where we all know, that response can be of different content-type, the DSL presents easy handler for them.
Getting back to queries, an HTTP request has been given a method like GET or POST, when dealing with RESTful services, we'll see PUT and DELETE in the game.
When data must be provided we'll have to pass some arguments/parameters in the request payload (or url).
Let's see how those actors compose in the Dispatch's DSL.

URL

The url of the HTTP request is basically composed of the host and port, followed by path elements. Here is how to create an url such url http://dispatch.databinder.net/URLs+and+Paths.html

Attributes and Headers

After having build a Request (see above), you now have access to some modifier on it.
The probably best way to learn all of them will to check the source code here.
But here is some examples:

Method

The method is the quite more simple... juste append the name to the request, in order to change the method from 'GET' to another:

Payload

As for headers, you better check the code for know every tools, the library put in your hands. Here is some conventions I understood from the code:

Executors

Dispatch works with executors that execute the queries and accepts handlers for handling reponse.
Such response waiting is configurable by choosing among several implementations, the documentation is well suited on the wiki.
But in our case, what we need is synchronousity, because the RESTful service is also out backend service. So the executor comes with the `dispatch` package, this way:

Handlers (Response's Body)

Here's come the sfun... Handling responses.
Actually, this piece of code comes in the game just before we apply the request to the executor, but ok, let's takle it now.
A handler can also be called the response parser, that said, it is responsible to parse the whole content into a new form.
Some existing handlers are:
Basically, a handler defines an operator, a result type and takes a block that deals with such result type instance.
Some examples of such handlers are made on the wiki, especially for Json or html (here, here and here).
Others handlers exists by default, for redirecting to outstream, to compose or chain handlers.

In the next post, we'll see how to use Neo4J Json Rest Api with Play! framework through Dispatch.

Neo4J with Scala Play! 2.0 on Heroku (Part 4) :: Play 2.0/Json

Note

This post is a continuation of this post, which is the thrid part of a blog suite that aims the use of Neo4j and Play2.0 together on Heroku.

Play2.0 - Scala - Json

I'm about to write a quick wrap up, of some Play20's wiki entries and stackoverflow that were all related to Json in Play2.0.
For that, I'll take some usage examples, but also present the underlying libraries (Jerkson) and the used paradigm, SJson.

Scope

Giving that the wiki pages are really clean and self-explaining, I'm not gonna enter deeply in how Json must be used with Play 2.0 albeit I'll give some prerequesites in order to help you understand how I'll use the Neo4J REST API.

play.api.libs.json

This package contains everything you'll need in order to work with Json in Play 2.0.
It defines important structure like JsObject, JsArray and even some like JsUndefined.
They usage is very easy since they are based on classical scala's Map and List of JsValue(parent type).
Here is an example of creating a JsArray and iterating items. To test it in a REPL, I recommend you to enter the Play console by using play in your repo and the console in sbt (to have all libraries loaded).

For arrays, it's quite easy (maybe wrapping could be annoying but a little of pimping can resolve that).
The Jerkson library powerful comes with JsObject usages. It has defined a very clean DSL for querying Json. Here is an example for querying a property or catch a descendant property.

play.api.libs.json.{Format, Reads, Writes}

Until now, you saw that Json is usable with Play. But, I guess that you hope more than that, since this framework is here to ease the work.
And you're right.
Play is coming with a SJson flavor for serialization and deserialization of DSO.
Three traits come in the game.

Reads

Reads defines a simple method reads:
Having a Reads defined for a type T, we can now extract such instance from Json.
With the object Reads that defines an implicit Reads instance for most common types like Option, String, Short ...

Writes

Writes, like Reads, is very simple and defines a simple method writes:
Obviously, its purpose is to convert a value of type T into its Json representation and is the inverse function reads.
A Writes object is defined too with conversion to common types.

Format

This trait is there to put the pieces together
With the help of this trait, we can now have a serializer of custom domain object from/to Json.
A good practice is to define such Format into the companion object of your DSO, so that it will come in the scope at once when using it.
Here is an example:
Let's see how to use this Format easily to go back and forth from DSO instances.

play.api.libs.json.Json._

This object is an handy one, that defines four convenient methods. Two are here to play with String and JsValue. The other are to play with types and JsValue.
Back to our simple DSO class, we can now do this:

Enhancement

In order to have more control on effects of your serialization, I would recommend you to consider the Scalaz library's Validation construct.
Indeed, it will help you having more relevant information and all at once if you reads is wrong.
Here is a talk about this (but not in Play).

In the next post, we'll talk about the Dispatch library. See it here

Neo4J with Scala Play! 2.0 on Heroku (Part 3) :: Play 2.0/Idea

Play!2.0 Scala and Idea CI

This post is a continuation of this post, where I’ve introduced Neo4J and how to install it. But it requires that you already followed this post.

Goal

Event if the ScalaIDE 2.0 has just been released. I still prefer Intellij for editing Scala, because even it's community edition has a powerful and polish Scala support (after having installed the plugin...).
And while, playing with the 2.0 version of Play! you'll enjoy the use of CoffeeScript to heal your JS head aches, you'll also loved the CoffeeBrew plugin.
Here the goal is to help you create a Play! 2.0 RC1 scala project, update the sbt configuration for sbt-idea, and finally generate the IDEA module.
Having done such easy tasks, you'll have the full IDEA powerfull in your hands.

Create the project

First of all, we need to create the project for what we'll try to do (using Neo4J through it's REST API).
For that, you should have the play executable in your PATH setup, and able to run the following in console.
play new Play20WithNeo4J Which will prompt you some questions, that you'll answer the following (no color question, don't worry but a little remark later if you're using Windows ^^):
What is the application name? >
Play20WithNeo4J
Which template do you want to use for this new application?
1 - Create a simple Scala application
2 - Create a simple Java application
3 - Create an empty project
> 1
OK, application Play20WithNeo4J is created.
Have fun!
Basically, it asks you the name of your app, and it's language (note that we've chosen the scala way).

Setting sbt-idea

Play! in the new 2.0 version is using sbt to configure the project and run tasks (such as deploy start/run and so on). The sbt version in used is the 0.11.2 at the time writing, and is embedded with the install.
So that, you can already launch the sbt console by either run play or play console to have all Play! deps on classpath.
Before running any command, let's modify some sbt conf files to have sbt-idea being able to create an IDEA module for our project.
Play 2.0 comes with a default configuration for sbt, so that, those files are already present under the project folder:
  • Build.scala : contains the app information
  • build.properties : contains the sbt version 
  • plugins.sbt : contains default resolver and play 2.0 RC1 Snapshot deps
Starting from there three actions are required in order to import sbt-idea.
Create build.sbt
We have to create a new file name built.sbt in which you'll add the TypeSafe (Scala company) as a searchable repository.
resolvers += Classpaths.typesafeResolver
Update the plugins.sbt
Add the needed reference to the plugin sbt-idea and add it to the plugin list of sbt.
resolvers ++= Seq(
    DefaultMavenRepository,
    Resolver.url("Play", url("http://download.playframework.org/ivy-releases/"))(Resolver.ivyStylePatterns),
    "Typesafe Repository" at "http://repo.typesafe.com/typesafe/releases/"
)

addSbtPlugin("play" % "sbt-plugin" % "2.0-RC1-SNAPSHOT")

resolvers += "sbt-idea-repo" at "http://mpeltonen.github.com/maven/"

addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "0.11.1-SNAPSHOT")

libraryDependencies += "play" %% "play" % "2.0-RC1-SNAPSHOT"
Update the Build.scala
Add the sbt-idea plugin repository in the resolvers' list.
import sbt._
import Keys._
import PlayProject._

object ApplicationBuild extends Build {

  val appName = "playbasket"
  val appVersion = "1.0"

  val sbtIdeaRepo = "sbt-idea-repo" at "http://mpeltonen.github.com/maven/"

  val appDependencies = Seq(
  )

  val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(
    // Add your own project settings here
    resolvers ++= Seq(
      sbtIdeaRepo
    )
  )

}

Create IDEA module

Now everything is quite simple. Get back to the project root and use play. When entered the console, the module will be build by simply running idea.
Having the iml created, all you have to do is to open Idea, create a project and import the module file right after.
Note, if you're encountering problem with the scala environment (that happens at first time). You'll have to create another module (short-lived), then add it the Scala facet where you'll be able to configure the Scala compiler.
When done, you can delete the module, and getting back to the original, you'll be able now to refer to the Scala compiler/libraries.

Let's move to Json and Play

Neo4J with Scala Play! 2.0 on Heroku (Part 2) :: Neo4J

Neo4J

This post is a continuation of this post, where I've introduced for what is dedicated this suite.
In the current post, we'll talk a bit of Neo4J and why I've considered it as a back end service for storing data in one of my later spikes.

Some works on Graph DB

A graph database is a kind of NoSQL, that stores neither data as KVP nor as Column even nor as Collection of document, but as... Graph.
Ok, ok, it's quite obvious but what to say more, maybe that it's querying is very interesting because it relies on a notion of traversal, that would require joins on joins in classical RDMBS.
The main purpose of such graph storing is high dergeed inter-connected data, as Social data are.

Neo4J

I quickly fall on this product for handling my test domain model that figures the social network use case, where users are connected to users, and participates in groups.
Neo4J is written in Java, where a lot of NoSQL database are C++ based. Moreover, where most of NoSQL databases requires standalone installation to work, Neo4J is able to create Embedded databases running instances (look like the jetty revolution for servlet containers).
Finally, my choice was arrested when I saw its RESTful interface; still in working status but which is promising, with url patterns auto-discovery using the service root response.
Final Finally (I promise), I saw that Neo4J community was huge, that Spatial was already taken into account (GIS has highly inter-connected data, and it'll be probably my next spike). But also, it offers good usage of Lucene as back end indexing provider.

Install It, Start

Quite simple, and I wouldn't expand my self to much on the topic rather than pointing the extractable http://neo4j.org/download.
Drop the extracted folder wherever you want, and set your PATH to target the Neo4J/bin folder where is located the neo4j executable.
When it's done two choices are up to you:

Sanity check...

The server will run listening on your localhost:7474/. Using your browser you'll directly be redirected to the webadmin interface.
Since I can talk further on this web admin, I'll introduce some features I loved.

... WebAdmin (is your friend)

The Neo4J web amin interface offers a way to query your graph very easily through a simple string using tags (like Lucene query string) in order to match nodes, relationships, paths, indexes and so on.
So far so good, and? Ok it presents you the result in an editable table...
Mmmmh exiting... Ok and you can see your graph using their arbor.js based viewing tool. Ha ha!
The other tool I like is the web based console for trying Cypher or Gremlin queries or even to try the HTTP REST interface.

Let's create the project and configure IDEA

Neo4J with Scala Play! 2.0 on Heroku (Part 1)

Neo4J with Scala Play! 2.0 on Heroku

In this new posts series I’ll try to gather all steps of a spike I did building a prototype using scala and a graph database.

Chosen Technologies

Play! Framework as the web framework, in its 2.0 version built from sources.
Neo4J as the back end service for storing graph data.
Scala for telling the computer what it should do...
Here is an overview of what will be covered in the current suite.
  1. How to install Play! 2.0 from Git (or download the last version that must be > beta)
  2. Install Neo4J and run it in a Server Mode. Explain its REST/Json Interface.
  3. Create a Play! project. Update it to open it in IDEA Community Edition.
  4. An introduction of the Json facilities of Play! Scala. With the help of the SJson paradigm.
  5. Introduction of the Dispatch Scala library for HTTP communication.
  6. How to use effeciently Dispatch’s Handler and Play!’s Json functionality together. Create generic Neo4J nodes using the result. 
  7. Enhance the previous work to create a persistent service that can re/store domain model instances.
  8. Create some views (don’t bother me for ‘em … I’m not a designer ^^) using Scala templates and Jquery ajax for browsing model and creating instances.
  9. Deploy the whole stuffs on Heroku.

Play 2.0 Framework

This post intent is not to explain how powerful is Play framework (2.0) is. For that I'd recommend this wiki page.
However we'll explain all needed steps to build it from sources.
When I first wronte this post, the released version wasn't suficient for what I needed to do with Neo4J. But now you could just download the RC2 and unzip it somewhere, find it here.

Prerequesites

In this section, we’ll assume that you’ve already setup your scala and git environment (oh yeah and the JDK as well, and not the JRE only! we’ll need javac). If not please refer to those sites:

  • http://www.scala-lang.org/node/201 
  • http://help.github.com/set-up-git-redirect

G[e/i]t sources

First of all, open your preferred Git tool and retrieve the sources (warn: choose a unix like path, otherwise you might encountered problems with spaces for instance).

Use git clone git://github.com/playframework/Play20.git. And wait for having all sources downloaded.

First step in sbt

Seconds later, open a console and do the following to run the built tool used by Play 2.0, that is sbt.
cd Play20/framework
build

This will launch the embedded sbt (0.11.2) which needs some libraries automatically fetched.

Build and fetch

While being in the sbt-console, you can now ask sbt to build the framework and fill in the local Ivy repository with needed libraries (Play2.0 runtime deps).

Enter build-repository in the console and hit enter.

Minutes later, you”ll be able to quit the console by CTRL+D, and to check what happens in you Play20 folder.

Actually, aside the framework folder, you have now a folder named repository that contains every needed deps (includind play).

Let’s check by listing all files in play: ls Play20/repository/local/play and find libraries such play, anorm, template for the scala 2.9.1 version.

Done!

Great!

You’ve just finished the Play2.0 installation.
You can, for convenience, update your PATH to point to the Play20 folder (where resides the play executable)

Let’s move to the Neo4J setup