I'm currently exploring similar alternatives to Ruby on Rails, and have been considering Playframework using Scala (cuz I'm not fond of Java).
Problem is, even if the default sample of application works very fine, everytime I try doing actual work with Playframework, it end up with it not answering HTTP requests.
It compiles after the first request, but doesn't answer it.
Then it ignores every other request (not even re-compiling when I changed stuff).
It does kick out an user typing an incorrect request, but it never times you out if the request is correct.
What is this ?
I'm using Playframework 1.2.3 with the Scala module. Is there any way to get a better insight at what's happening ?
So it never times out, isn't it? as if it was compiling forever?
If yes, maybe you have problems with the Scala compiler which is slower than Java compiler and requires more stack. Generally if you don't have enough stack, it should crash with a StackOverflow.
YOu can try to run play with "play run -Xss1024k" for example to increase the stack size.
If you get empty answer, it means the problem is somewhere else like routes or bad object returned from your controller.
Anyway, Play-Scala is still young and in evolution so it's not a reliable solution for an entreprise solution if you're not yet an expert in Scala and don't already know Play IMO. It's already robust and stable but not well documented and as complete as Java version.
Finally, you say you're not found of Java and it's something I can understand but you should really give a try to Play/Java since it's completely different from any other Java stuff. I can say that because I'm an old Java developer and find the language getting a bit outdated in its syntax and basic features. I don't really like Java EE web frameworks in general because they are not really productive and user-friendly. When I found Play more than one year ago, it was like a breath of air for me. You get the best of modern web frameworks and the best of the Java world which are all the robust and approved entreprise tools coming from opensource. I've never been deceived by it since this time.
Related
We have narrow down our search between Silex and Slim PHP frameworks for routing our REST APIs on our Apache/PHP/MySQL Server.
Both seem to have good reviews. Silex has probably a bigger community because it came from Symfony. But the documentation seems to be better in Slim.
What do you guys suggests? Any real world experience from production environments?
Sathish
I had the same choice to make, and I choose Silex, here is why :
Silex seems to have a bigger community than Slim, maybe it's just my point of view
It's based on Symfony components, so with a bit of reflection, you can use tips and workarounds which work for Symfony and apply them to Silex.
As it's based on Symfony it has a better integration with other bundle (for example Twig, which is for me necessary)
This Symfony base also garanty that it will be more "Long Term Support" that Slim, which is independent.
To conclude, the main argument is that is based on Symfony which has many advantage.
The Symfony Debug tools are the best thing on earth !!
Now I have two sites made with Twig and I'm really happy !
You can also see that, it's a technical comparison of these both frameworks :
https://michalzuber.wordpress.com/2015/04/02/silex-vs-slim-php-microframework-comparison/
Slim 3 is very light weight and well suited to APIs.
You can optionally inject a container (Pimple by default but any Container-Interop will work) when constructing your Slim app. The Silex app extends Pimple so is a container.
Require slim/twig-view if you need Twig.
Slim's Request and Response support PSR-7 HTTP message implementation.
On January 12th 2018, Fabien Potencier, main author of this micro-framework, wrote that Sensiolabs stops supporting Silex.
https://symfony.com/blog/the-end-of-silex
Quote from Silex official site:
Silex is in maintenance mode. Ends of life is set to June 2018. Use Symfony 4 instead. Read more on Symfony's blog.
Slim is better if you want to create apis as its light and fast. Hence slim provides you the DI and routes it is much more flexible to use your own libraries or plugins from laravel or symfony or any third party.
For example you can use sentinel from laravel for auth
TL;DR Choose Slim 4. "At its core, Slim is a dispatcher that receives an HTTP request, invokes an appropriate callback routine, and returns an HTTP response. That’s it.". That should be it.
Late to the party but nonetheless here's my 2 cents(!) on the topic especially for future-googlers about this topic (even though Silex has reached end of life); I'd go for Slim. Which I already did on my previous 2 projects and it never let me down. Before the "here's why" part I'd like to share my background in a nutshell; I've worked with CakePHP and Laravel (especially >=5.4, <5.8) (and also with Lumen) years and years ago, right before I introduced myself with Node.js. Since then almost all my work runs on Node.js in the cloud. Now there's Golang on the table... but that's another story. Due to the requirements (or I should say constraints) of the aforementioned 2 projects, I have to write PHP. Since all those years past with Node.js I suddenly realized that I've forgotten about PHP almost completely. But there were 2 things I remember crystal clear; I've suffered. A lot. Because of those frameworks.
Don't get me wrong former is the eldest one and the latter is the hipster of the pack, I respect them, their authors and their community. Everything has a reason to exist. But one is behemoth and the other one is magical (both not in a good way - I mean did you ever try to debug the Laravel with those facades and static methods and stuff?). OK I hear you, they are frameworks and they should do things for you (have you heard of Hollywood Principle), not everything for you. What this does mean to me is that they always whispering to your ear "our way or highway" (sometimes even yells). "Surely you can do this (say push a job to a queue, query your database, send email, etc.) but first do this, and then that" (maybe couple of more steps but this is not that bad). The bad thing about this is (not accusing anyone) I don't know what do they mean to the framework. They must do something meaningful, obviously though, I don't know what it is. Should I know? Yes, of course. I'm writing this application with that framework for God sake, I should know what it does. Version X was easy to grasp, but what about version Y, Z, T... Have you seen the version dropdown on the Laravel's documentation site? I took those steps because I've been told so. Again that's OK, fair is fair, those steps makes me achieve something far greater. But gradually I'm in their (respective authors') control. After that, even small change takes lots of searches on SO, GitHub issues, Google... Sometimes ends up with a success and most of the times don't. Either way the war against the framework must be declared.
In my point of view this is not how an open-source framework should be. I am vendor locked-in in some sense. Maybe I want to adhere PSR (not that because I'm an advisor recommendation freak, because PHP-FIG is a well-known group with standards almost for every aspect of the language - this is important; for the language, not for any framework). Let me ask you something; do you use Composer? If so why? Because it's standard (I'm not sure if it is)? Because everyone uses it? Because the needed package of yours recommends this way of installing? Actually the answer doesn't all that matter, at the end of the day you use it. And you can use it practically for every PHP framework/project. The Composer requires you to have PHP installed on the system at bare-minimum and coincidentally it's the only requirement. This is freedom, and I want that. I want to pick and choose a router or a container for my taste. Today this package, later something else.
Slim gave me that freedom, especially on version 4. It's community is small, it's foreseeable; it does so much less than the other, full-blown frameworks. Actually it's a micro-framework (although I wrote an MVC application and REST API server with it). Other packages' communities are what matters right now. You need a container, composer require php-di/php-di. Now think about it's community, since "your" application (hence the framework) is a part of it. You have a problem? Ask for help specifically for that package. Maybe someone using another framework (or someone using no framework at all - if there's any left nowadays) might help you with your problem. So you've gone framework-agnostic thanks to your setup. Don't you like PHP DI, well find yourself another PSR-11 compliant package. Same applies for almost every part of Slim - except the router (Nikic's FastRouter should ring a bell), although it's already a foundation for other routers I see so far.
Before I finish I should say that too, Lumen and Silex has big brothers. I've been through a handful of frustration moments with Lumen; when I say "I can't do [fill here with a not-so-common problem] with Lumen version X.Y" they say "Use Laravel instead, it is really easy to upgrade". It should be for God sake! They share the same blood. I wasn't ask for that. If I were like to use Laravel I would choose it in the beginning and not use the Lumen in the first place. There were some reasons I did choose Lumen, like there were some reasons the author write it too (which I don't know why, but still...). Lumen should be a lighter weight, micro-framework alternative to Laravel, not a stepping stone.
Choosing Slim has it's disadvantages too but I think it's about the perception. I want to know what's happening on my application given the circumstances. Isn't reasoning about actually that? Even if I'm going to this rocky road at least I know at the end my application will do exactly as I commanded, nothing more nothing less.
Thank you for your time and please excuse me for formatting.
The fact that Silex didn't support PSR-7 (at the time of writing this) a huge let down. It has so many good point already mentioned above. There is a plugin/extension that let you do that, however I don't see the point in adding this overhead when you are looking for a lightweight framework
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.
For a project I'm using both Scala and Riak (two things I have never worked with before ;) ).
Google searches seem to suggest using Riakki. However, it seems like that particular library hasn't been maintained since 2009 and doesn't even compile on my system. There is a more up-to-date fork on GitHub that does seem to work with more recent Scala versions. But Riakki seems to depend on Jiak, which has been deprecated since february of last year.
Seems like the only reasonable choice would be to use the official Riak Java-library from Scala. That's certainly possible, but I'd like to do things the Scala-way as I'm trying to learn the language. Having to interface with a Java-style API might ruin a bit of the fun. Writing my own wrapper sounds like it will be too much work.
tl;dr: I want to use Riak from Scala. What are other people using?
edit: just found Ryu (can't link to it - annoying limit on amount of hyperlinks per question for new users). Doesn't seem all that mature though.
Stackmob recently opensourced Scalariak.
Scaliak is a scala-ified version of the High-Level Riak Java Client w/
a Functional Twist. It is currently being used in production at
StackMob.
Scaliak is currently feature incomplete vs. the original High-Level
Riak Java Client. What is currently supported are mostly features
being used in production (there have been a few features implemented
and subsequently not used).
There is also Raiku which states that it is async.
I'm in the same bucket - excuse the bad pun - although I have some experience with Scala. I'm thinking of using the official Java client.
When you are toiling up a steep learning curve, you don't need to be dealing with incomplete and potentially wobbly API's. In my experience, using Java API's from Scala is minimally painful.
I think there'll be enough delight in playing with our new Raik toy that we'll forget about whatever un-Scala-ish foibles the Java API inflicts upon us. All the best.
I'm the author of yet another Scala Riak client, simply called riak-scala-client. It is based on Akka and Spray, it is not built on top of the existing Java client, and most importantly it is completely non-blocking.
Check it out at http://riak.scalapenos.com and let me know what you think.
I'm curious what's the "best" way to program RIAs with Scala.
I'm new to Scala and would simply like to know where to start learning. It seems obvious that for web-apps Lift is the perfect choice to be combined with Scala. However from what I've seen so far Lift is not really providing the key to great visuals. Certainly there are hundreds of possible frameworks due to the compability with Java but that's not very helpful.
What would you recommend ?
What is a common set-up ?
Among others I found cappuccino, a very impressive framework.
http://www.scala-lang.org/node/7281
It just seems like Cappuccino is designed for a language named Objective-J. That doesn't sound like great compability to me. Yet somehow they can work together.
http://frothy.liftweb.net/
Well, if you are new to Scala you should probably try Play, because learning a web framework and a new programming language is hard.
Play has a big community and seems to be quite user-friendly (pressing F5 in your browser reloads your code and displays any errors which have occured).
Normally any Java web framework can also be used in Scala, but Play seems to be pretty Scala-friendly.
There are quite a few Scala-specific web frameworks too, but I don't know enough to tell you more about them.
Lift is an powerful and impressive framework, but certainly nothing for beginners.
(I assume "new to Scala" doesn't mean "I programmed in Haskell, ML and Scheme for decades").
Of course it all depends. Personally, I have had no problem starting with Lift even though I’d only used Scala in the REPL before and just for some toying around to get to know the syntax.
It certainly helps a lot if you already know how to use collections in a functional way without explicit loops, so you can read and understand other people’s code more easily. But basically, I’d say it is doable learning both Lift and Scala at the same time even without a background in functional languages. It’s just the collections thing you’ll have to get used to and if you happen to know Ruby (or a language with list comprehensions) you’ll easily understand it.
The Frothy integration has not yet been updated to the newest version of Lift and I don’t know of any site which actually uses it but maybe this is a thing to ask on the Lift mailing list. In any case, I think Frothy only helps you connecting a Lift setup with some Cappuccino frontend but does not provide many wrappers to the Objective-J code, so you’ll still have to write code in Objective-J.
At that point you can ask yourself: Why not write the whole thing with Cappuccino and decide afterwards if Lift integration is actually needed.
Considering Lift alone: You certainly can use Lift with some UI Kit like JQuery UI for the visuals. Lift has many advanced possibilities which make it possible to build complicated web applications but you’ll have to care about the wiring for the visuals yourself.
(And arguably, a stateful, non-MVC (‘view first’) framework like Lift might be better suited for a rich internet application than a pure MVC framework…)
I have been working on a project and as I have just started on the webservice I found Lift has been released, so I am curious if there will be much more complication by using Lift over Jax-WS using JDK6.
I am doing this with the Eclipse IDE, but I don't know if I will get much benefit from the IDE on this project.
Lift is written in Scala, so the simple question is do you know Scala? If you don't know Scala but you do know JAX-WS, then Lift will clearly be way more work to get to a working implementation.
Scala and Lift are cool, but unless you are already comfortable with functional programming approaches, they will make your head hurt for at least 6 months. Since they are relatively new they also suffer from a lack of tooling.
You mention that you are using JAX-WS - can you do that with Lift? If you can't do it natively with Lift, can you easily integrate the standard Java libraries for this?
Depending on whether this is a personal project or work-related, your tolerance for taking technical risk can vary widely.