It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Spray framework (spray.cc) seems to be a fun and productive way to build REST services using Scala & Akka. I come from Java + Spring school, where everything is well documented, mature and has good community support.
While Spray is fun to play with but it has its rough edges. I am skeptical about using it in a real application.
Has anyone used Spray in production environment? What about the open source community around Spray? Is it possible to get help easily?
UPDATE: How does Spray compare against BlueEyes (https://github.com/jdegoes/blueeyes)?
We are using Spray in a telco middleware application and I would say Spray is production ready and,
lite weight and seamlessly integrates with Akka
Can easily test the services (No need to fire the container or Akka micro kernel)
Well documented comparing to BlueEyes
Marshaling/unmarshaling JSON is simple & efficient
Can get support from spray user mail group.
I think BlueEyes does not have seamless integration with Akka or good documentation. Not sure it can be deployed inside a web container or akka kernel. Spray's some features are copied from BlueEyes too.
-Jestan
Althouh we are not yet in production, we are using spray for Shopolate, a new startup. So far our tests are showing an excellent throughput, and developing with it is very efficient.
We found no bugs so far.
Answers to questions on the Spray forum are coming quite quickly, but it still remains a starting community. I found the documentation to be quite complete and clear. One big plus is the lightweight / eleganc of the underlying design, which makes the spray source code very easy to grasp and extend.
The only downside that impacted us so far is the relative small sets of features, but it is increasing steadily.
I don't know BlueEyes, so I can't answer to the second part of the question.
Spray is a really nice framework with some exceptionally smart guys behind it. It gives you simple code that scales well in terms of both features and concurrent users. If you want to end up with an application that reads well (good structure, easy to find which url maps to which feature etc), Spray is awesome.
Not all is great though.
The tight coupling with Akka is a two sided sword. For simple applications it adds unnecessary complexity. Think carefully if you want to embrace Akka before going for Spray.
At this moment Spray (1.1M4) has very limited documentation for the directives, so you're on your own mostly, reading advanced Scala code, scratching your head.
Backwards compatibility is not taken seriously so far. Expect to touch all your code when upgrading. This is as much to blame on Akka and Scala itself as on Spray. If you don't like this go with something boring and reliable like Spring MVC.
The Scala language constructs used are so hard to parse correctly that most IDE's get lost and you'll have to wait for the actual compiler to do its job before you know what you're up against. I said before that the code was easy to read, but that is only at a high level. You very easily sort of get what is going on, but to actually get what's going on you'll need a lot of stack space in your head.
I'm using Spray in production and sticking with it (probably), but it's not an easy ride. Expect to be frustrated and delighted in equal measures.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I used play2 before with java. It felt a little bit like boilerplate especially if you used akka with java. But that is not the fault of the framework.
Yesterday I read "Scala for the impatient" and I really enjoy the language.
Now I looked at both frameworks Lift 2.5 and Play 2.0.3. I think lift has a higher learning curve and I could not just do something with lift. This is not a con for me. From what I saw, Lift has a very nice and clean design.
But for me it is hard to tell what the main differences are. I think both frameworks are great.
The Views First approach doesn't allow you to code in your templates, instead you have to code in snippets. I like this a lot because it looks more organized to me. It also lets you use a normal html editor.
(I have not much experience, this is just my first impression)
For the security I don't think that is the job of the framework.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Both frameworks are able to compile after you press F5. I like this feature a lot.
Both frameworks are using sbt
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has a ORM mapper for mongoDB. Because I want to use noSQL, this looks cleaner to me.(Again not much experience) Edit There is a ORM mapper for scala mongodb in play2 https://github.com/leon/play-salat
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
What are the strengths of each framework?
Posting this after spending a week or two with Lift doesn't really
serve anybody's interests. However, I want to spend some time correcting
some mistakes and mis-perceptions.
For the security I don't think that is the job of the framework.
You're dead wrong. Security is the job of the framework. It's critical that security
is done by default rather than relying on each developer to understand every
security vulnerability and make sure every line of code takes that into account.
All we have to do is look at what happened to GitHub
to understand that even the best coders using well known technology
can make a critical mistake.
Lift gives a solid security layer on top, so by default, there's no XSS, CSRF, etc.
but the developer can dig down as deep as he wants to the HTTP request and deal
with the bytes on the wire.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Lift is very clear about where you need state and where you don't. Lift can support
stateless, partially stateful, and completely stateful apps. On a page-by-page and
request-by-request basis, a Lift app can be stateful or stateless (for example,
in Foursquare, the venue pages are stateless for
search engine crawls, but stateful for browsers that are logged in.) For
more on the design decisions around state, please see Lift, State, and Scaling.
Both frameworks are using sbt
Lift uses Maven, sbt, Buildr, and even Ant. Lift is agnostic about the build environment
and about the deploy environment (Java EE container, Netty, whatever). This is important
because it make Lift easier to integrate with the rest of your environment.
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has been around for 5+ years and has a lot of modules and stuff for it. The Lift web framework (as distinguished from the modules) is agnostic about persistence, authentication, etc., so you can use anything with Lift.
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift has had Async support for more than 5 years. It's baked into the framework. Lift's Comet support is the best of any web framework because,
among other things, it multiplexes all the "push" requests on a page through a single request
to the server which avoids connection starvation. How Lift does async is a whole lot
less important because one of the core philosophies with Lift is that we remove the
plumbing from the developer so the developer can focus on business logic.
But for those who care, Lift has the best and lightest weight actors of any framework in
Scala-land. We were the first to break away from the Scala Actor's library and worked
to blaze the trail for different Actor libraries that allowed Akka and ScalaZ Actors
to flourish.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
This is part of Lift's commitment to security. It's important.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
Lift apps can be as stateful or as stateless as you want. It's your choice and Lift
makes very clear how to make the decision.
Also, as I pointed out in the Lift, State, and Scaling post, making the developer figure out
how to serialize state in a secure, scalable, performant way
(because virtually every request on a web
app that recognizes specific users is stateful) should be done in a predictable,
secure way by the framework with reasonable overrides for the developers.
Parting note
Play is a lot like Rails: it's quick to get a site knocked together and it's
based on MVC, so a lot of developers understand it. But Play lacks the
depth and breadth of Rails (community, plugins, expertise, talent, etc.) If you
want quick, easy MVC, then go with Rails and JRuby and write your
back end in Scala (they work together extraordinarily well.)
Lift is a different beast. There's a significant unlearning curve (stop thinking
MVC and start thinking about user experience first that flows to business logic.)
But once you're up the unlearning curve, Lift sites are more secure, highly
scalable, super-interactive, and much easier to maintain over time.
To see what can be done with Play (it can be cool), have a look at the TypeSafe Console
To get going quick with Lift, use a template project.
For a sample of using Mongo with Play, look at Factile.
In summary, I don't think you will go wrong with either Lift or Play. Both are active projects, with good communities and good backing from the authors. It really depends on your business problem. If tool support are important to you, then you may want to look at using Play (it's well supported on IntelliJ Idea).
Take note that Play, being part of the TypeSafe technology stack, will have builds up to the latest versions of Scala, so if using Scala 2.10 features are important to you, then you may want to keep that in mind. Lift is currently using Scala 2.9.2, which is fine also.
For my current project I use lift-mapper for ORM (It's great and rock solid), with Spray for REST (which is simply amazing). This approach avoids frameworks altogether, but it depends on what you want to do. Frameworks are quite often the way to go.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I've been doing research on this for the past 2, almost 3 days now. I feel like I've googled everything under the sun on the matter (including these forums) and am almost all tutorialed-out. Before I go into any more details on the question I just want to give a quick overview of the scope and plan for the project to see what will suit it best:
-Large application, non-trivial
-50+ DB tables
-Large user base
-User management/authentication/sessions
-transactions
-security
-MVP (as per GWT recommendation)
-focus on performance and scalability (naturally :), am using GWT after all)
-Prefer to stick with Java serverside
I've also read and watched all of the best practices on architecture for large applications (Google/GWT). In the last talk I could find on best architecture practices involving GWT was back in 2010 by Ray Ryan in which he states that they don't think JavaBeans and property change events work terribly well so it's better to use DTOs for the Model.
The 2 frameworks that came to the forefront in my searching were Seam and Spring.
Sticking with MVP, my domain would for the most part be a data service with a thick client. However, I would still like the serverside to have security and session capabilities since I'd like users to be able to keep state even if they don't use cookies and they end up refreshing for example. I would also like to have an ORM like Hibernate to manage a lot of the transactional aspects. I'd like to still use RequestFactory and have really been considering Spring.
I guess I can narrow my question down to:
Considering the above, what would the recommended application stack be for a large GWT application, specifically for the serverside and integration with GWT?
This is my first project of this scale and the last thing I want to do is head down the wrong path on losing a lot of time and energy. Thanks a lot in advance for your help, I really just want to figure this out so I can get back to coding instead of googling the ends of the earth ;).
-Seth
I've also already looked at Best architecture for applications in GWT which I found might be the closest to this, but it didn't really answer my question and I feel mine is a little more targeted with a more specific use case
I don't have any experience with Seam, however I am working on a relatively large project using GWT on the frontend and Spring on the backend and so far it works really well (RequestFactory, JPA2/Hibernate, PostgreSQL). BTW you can also checkout JBoss Erai
The good thing about using Spring is, that adding new features is quite easy. For example I added support for openid authentication and all I had to do is define an additional dependency in maven and some additional lines in the configuration file and now authentication via google,facebook, twitter account works out of the box.
This layered approach has a lot of advantages.
But if you really stick to the best practices of developing GWT apps (MVP, etc), you will end up with two more or less separate projects. This is a little bit different then when you would develop traditional Spring MVC/Web Flow apps where you have more or a less only one projects (btw: check out Thomas Broyer's gwt maven archetypes which helps you come up with a good project structure).
In addtional to this when you use MVP on the client side your backend will actually only serve as a data service which feeds your GWT client with data. All the flow synchronization will be handled in your GWT app.
So you will probably not use many of the backends functionality (i.e. the MVC part of Spring MVC).
I use RequestFactory for data communication between backend and frontend and for CRUD applications this works really well (it also supported from Android btw).
However if you want to support a more clients you might rather use a Restless approach. Again by using Spring on the backend it is relatively easy to add Restless support to your app and there are a couple of 3rd partys libraries supporting restful services in GWT (RestyGWT, Restlet).
Here are some thoughts on the development process:
Use a dependency management system like maven. It makes it really easy to develop in teams and split up your projects in manageable units/modules (for example a GWT maven app can be split up in a frontend part (GWT), backend (Spring) part and a shared (comong DTO's, etc) part.
Try to do test driven development (TDD or BDD). For example before you create a service function in your Spring backend (i.e. getAllProducts()) write a Unit test for it. This also helps creating a good Service layer because by writing Unit tests you define what the service layer is supposed to do.
"Premature optimization is the root of all evil": Don't put too much time in early optimizations.
Think about buying/using JRebel, especially if you use Spring. A relatively large Spring app can have a relatively large startup time. JRebel helps you to change classes in the backend without a reloading/restarting the application. It saves a lot of time.
Implementing ACL on domain level is not an easy job. There are ACL classes in Spring Security and they work fine for simple use cases however if you have complex use cases (for example filter a list of items based on ACL entries) this can be quite involved if you want to do it efficiently. On the other hand with Spring it is relatively easy to use another library (i.e. Apache Shiro). Futhermore you have to make sure that you display the correct controls on the frontend (i.e. no Edit button if the user doesn't have edit permission, etc). With JSP that is easy because you create the UI (HTML page) on the backend. In GWT you have to do it yourself.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I've been trying to learn GWT for quite a while, I want to build a website that is somewhat advance for my level.
I looked at a lot of documentations/books/blogs/videos, and I just keep getting more confused. Mainly due to facing new frameworks/methods/tools ... etc. in building apps using GWT.
For instance I'm having difficulty answering these questions:
1- Should I use Spring Roo/ SpringSource Tool Suite?
2- What sort of database specification/implementation should I use (JDO, JPA.. I'm a noob when it comes to Java DB issues)?
3- Should I use Google App Engine platform, how easy/useful it is for a start-up project?
4- Should I start coding now, or continue reading and confusing myself (I've started on my POJO data model)?
5- Communicating with the server, RPC or RequestFactory or something else?
Sorry for the many questions, as you can see I don't have much experience in GWT but I'm welling to challenge myself, I just need some guidance.
Thank you.
Taking each question in turn...
To start with no, its extra setting up and its sometimes nicer to be in control of your code and know exactly what is in there.
I would go for JPA with GWT as it is supported by Google App Engine. But bear in mind GAE doesn't provide a relational database and there are quite a lot of restrictions on on what is and isn'ty supported. If you're not using GAE then JPA or JDO are as good as each other.
If you're planning on using Google App Engine then use it from day one and design your app to take advantage of its facilities. If you are going to use this then I would suggest Objectify for your object mapping/"database" implementation as opposed to JPA/JDO as it's a more natural fit.
Yep, start coding now but don't expect the confusion to stop.
I would give the vanilla GWT RPC a go to see what you are dealing with, then try GWT Dispatch or the newer GWT Platform which make the whole RPC mechanism much simpler to deal. RequestFactory is fine too but has some idiosyncrasies that take some getting used to. In the end the choice will largely be personal - they all do the job and do it well.
Other suggestions
use activities and places to control application navigation
event bus for event propagation and to keep your code decoupled
MVP to separate logic/view
dependency injection (Gin client side, Guice server side) to glue it all together
Note: Unfortunately this question was closed, but I'm trying to maintain it for if someone else comes along with the same question.
I've been looking for a good solution to developing a service in Scala that will sit between mobile devices and existing web services.
The current list of viable options are:
Finagle
Spray
BlueEyes
Akka
Play2 Mini
Unfiltered
Lift
Smoke
Scalatra
There are probably more options out there. How does one decide which one to use? What are the traits (excuse the pun ;-) of a good Scala middleware choice. On the one side, I would like to go for Akka, because it is part of the TypeSafe Scala stack, but on the other, something like Finagle has a rich set of libraries and makes plumbing so easy. Spray looks nice and simple to use.
Any advice, insights or experience would be greatly appreciated. I'm sure someone out there must have some experience with some of these that they won't mind sharing.
UPDATE:
I would love for this question to be reopened. A good answer to this question will help new Scalateers to avoid related pitfalls.
UPDATE 2:
These are my own experiences since asking this question:
Finagle - I used Finagle for a project and it's rock solid.
Spray - In my latest project I'm using Spray and I'm extremely happy. The latest releases are built on Akka 2 and you can run it directly with the Spray-can library which removes the need for a web server. Spray is a set of libraries, rather than a framework and is very modular. The Learn about Spray: REST on Akka video gives a great overview, and this blog at Cakesolutions shows a really nice development approach and architecture.
UPDATE 3:
Life moves pretty fast. If you don't stop and look around once in a while, you could miss it. - Ferris Bueller
These days the choice has become simpler. In my humble opinion Spray has won the battle. It is being integrated into Akka to become the next Akka HTTP. I have been using Spray now on multiple projects and can honestly say that it's fantastic and best supported software I have ever encountered.
This does not answer the initial question, but at least gives some indication on why Spray seems like the best choice in most cases. It is extremely flexible, non-blocking and very stable. It has both client-side and server-side libraries and a great testkit. Also, have a look at these stats to get an idea on performance: Web Framework Benchmarks
I personally started with spray a long time ago and tried everything else there was out there for Scala. While Scala, spray, akka, shapeless, and scalaz certainly have a bit of a learning curve, once you start digging in and really learning how you are supposed to use the technologies, they make sense and I immediately saw the benefits especially for the kind of work I'm doing right now.
Personally I think nothing really stands up to spray for building both servers, rest apis, http clients, and whatever else you want. What I love about spray is that they built with akka in mind. It may have been a really early project when I first started using it, but the architecture made sense. Those guys knew what they were doing in terms of exploiting the benefits of using an actor model and not having any blocking operations.
While actors might take a bit getting used to, I do like them. They have made my systems very scalable and cheap to run because I don't need as beefy hardware as in the past. Plus, spray has that spray-routing DSL so making a rest api is relatively simple as long as you follow the rules ... don't block. That of course means don't go and pull in apache commons http client to make client requests from the api or actors because you will be going back to blocking models.
So far I am very happy with spray, typesafe, and akka. Their models just naturally lend themselves to building very resilient systems that come back up on their own if anything should happen and you take a fail-fast approach. The one beef that I have with spray (and it's not spray's fault) is the damn IDE support for the routing DSL. I absolutely despise Eclipse and have always been an IDEA user. When I started using the Scala plugin, everything seemed ok. Then my routing dsl naturally evolved into way bigger beasts. Something about the way IDEA parses that code makes it shit its pants anytime it encounters anything with spray-routing or shapeless. It's to the point where it's unusable (I type 2-3 letters and have to wait 5 minutes to regain control).
So, for any spray-routing or heavy shapeless code, I fire up emacs with ensime, ensime-sbt, and scala-mode2. Now if I could only get a Cassandra library with the quality of astyanax and built using a more non-blocking architecture.
Here you can find a great list of scala resources with a brief description of all the alternatives you listed.
From my own experience, I use Scalatra and it is tiny, simple and effective for things like uri mapping and calling web services.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Out in the dev lang there are many many, frameworks for all types of languages. For instance, javascript has jQuery, which I use all the time without even thinking about it. Then for php there is Zend and CodeIgnitor, Ruby has rails, Python has django. That's just a few off the top of my head.
I have always been the type of person that was against a framework, especially for PHP. I was always under the impression that using a framework would make people conceive you as lazy developer or to have the inability to code in the raw format. However, for a while now I notice large projects are being made in these frameworks.
I am very curious as to what the opinions are of everyone. Does using a framework make you less of a developer then using raw code, also lets add in a variable and say that you don't already know all the ends and outs of the primary language?
I always lived by the idea that it's better to write everything yourself...
... just to see how it works, then throw it away and use stable frameworks :)
While this may sound like a joke, there's much truth here -- rolling up something yourself will teach you a lot. And what you learn will allow you to better utilize what is already available.
See Not Invented Here.
Using the right framework gives you the ability to get actual, real work done. This means, IMO, you're more of a programmer, not less.
A good framework is indispensable in Javascript, to tide you over all kinds of incompatibilities between browsers that would otherwise drive you crazy. In languages where you have more control over the runtime environment, it's not indispensable, but it can supply you with a lot of useful functionality and stop you from reinventing the wheel -- so using the right framework for the task (which may not necessarily be the most popular one, if what you're doing is a better match for a different framework, perhaps a lighter-weight or somewhat specialized one) doesn't make you a lesser programmer, it makes you an intelligent one;-).
Understanding what's going on at (at least) just below the layer of abstraction you're coding to is an excellent idea (partly due to Joel's "law of leaky abstractions"), but that's no reason not to use a lower level of abstraction than available and suitable, except in a "learning and experimenting way" (i.e. not in production work;-).
Not using one makes you sure hell of a lot less productive however!
The only way to use 'raw code' is to write your programs in 0s and 1s. Otherwise, you are using a 'framework' of some sort. C is a layer on top of assembly which is a layer on top of machine code. That doesn't make a C programmer any less or a programmer - she is just working at a different level. In the same way, using a framework on top of PHP means you are just working at a different level. There are good programmer who build Zend (and other frameworks), and there are good programmers who use those frameworks to build business applications. Being an application level programmer is nothing to be ashamed of - it is hard work to do it right, whether or not you use a framework.
Davidmoreen, does using ASCII make you less of a programmer? I say, go ahead and make your life easier.
alt text http://prontiso.com/images/hardcore_keyboard.jpg
No more than using a language instead of raw binary does.
As the complexity of the tasks we are trying to accomplish increase, our only choice is to build on the foundations that others create. The main goal of any programmer should be to solve a business problem in a cost effective manner. If you don't solve real problems in a cost effective way then you definately less of a programmer.
I beleive it's important to understand the fundamentals of your tools and know how they work. THere'll be times when you need to work on the framework itself or just understand and debug what it's doing.
That said do you really need to remember to call session_start() at the beginning of every page load, or include the config files, or establish a database connection, or any one of the other minuetae that a framework will do for you and leave you to get on with creating the "unique" portions of your application?
I disagree with learining and using a framework without understanding the undelying language and concepts, but choosing to use one gives your code structure and makes you a lot more productive.
Being entirely dependent upon a framework makes you less of a developer. Using one as part of your toolkit when the need is there does not.
There is zealotry on both sides of the argument. You have the ones so starry-eyed about one particular framework that they use it for /everything/ (I usually see them in the form of beginner Railers or PHP programmers). Then you have the ones that are "hardcore" and as such "don't need hand holding", which more or less translates to them using last generation's frameworks instead (beacuse, after all, it's turtles all the way down).
It really comes down to knowing your framework. I would posit that using a framework without knowing its strong and weak points does indeed make you less of a programmer (if you are the one in charge of the decision), and should be counted as a cardinal sin. Study the frameworks, study the problem domain, make the informed choice, not the biased one.
Being able to make these kinds of decisions is what seperates good programmers from the... not-so-good ones.