[
https://issues.apache.org/jira/browse/S2GRAPH-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319158#comment-15319158
]
Jong Wook Kim commented on S2GRAPH-85:
--------------------------------------
I have mixed feelings about this. While Play! is indeed heavy and brings a
bunch of dependencies that we're not using, it is a mature and stable framework
with massive community support and the best documentation. Other than having
lots of jars that have to be carried around, Play! should be fine for serving
JSON API just as well as any other lightweight frameworks.
Furthermore, we can also benefit from the community support, e.g. the upcoming
HTTP/2 support should be done with minimal code change.
That said, the following are my opinions about a few alternatives of Play!.
* Spray.io - production ready, servers built upon akka.io.Tcp. But the
development team (Mathias Doenitz) moved to akka-http.
* Akka-http - can be considered as spray 2.0. Should be the choice if we want
to stick to Akka ecosystem.
* Lift - I don't see much reason to move to another full-stack web framework
* Scalatra - clean and easy microframework, running on embedded Jetty server or
as a servlet.
* Finatra - not so lightweight per se because it pulls all finagle and Twitter
stuff, but should be rock solid and fast, and support from Twitter will be
good. Annotations feel Java-esque, and some might not like it.
* Collosus - fairly minimal, only dependent on Akka and joda-time, developed by
Tumblr
* http4s - relatively new, but adheres to Scala idiom; comes with a DSL called
rho.
* JAX-RS - advantages of being Java EE standard for REST web services,
scala-java discrepancy presents.
* Raw Netty 4.1 - most complex to implement and there are scala-java
discrepancy, but we have the maximum flexibility and guaranteed performance (if
we do it right), can immediately support HTTP/2.
However, I think decoupling play-json is a more urgent issue than the play
itself; the JSON juggling like
[RequestParser|https://github.com/apache/incubator-s2graph/blob/master/s2core/src/main/scala/org/apache/s2graph/core/rest/RequestParser.scala]
is not pretty and should be replaced with an automatic object mapper and
validator.
As far as Akka is concerned, I think version conflict should not be the sole
reason to ditch Play!, since S2Graph's Akka usage is pretty small and standard
so it should be easy to migrate between versions, and we can always shade the
dependency as needed.
> Remove play framework dependency.
> ---------------------------------
>
> Key: S2GRAPH-85
> URL: https://issues.apache.org/jira/browse/S2GRAPH-85
> Project: S2Graph
> Issue Type: Wish
> Reporter: Daewon Jeong
> Priority: Minor
>
> `Play` is a full stack web framework.
> It has many features like handling cookie, handling user session, migrate
> database, integrated DI and so on. But `S2Graph` only need HTTP RPC layer.
> I think Play is to heavy framework for HTTP RPC layer
> and both S2Graph and `Play` has `akka` dependency.
> It can conflict.
> So, i suggest S2Grpah sould remove dependency with `Play` framework.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
