I'm trying to use sockets in my scalaJs code ,I have a real time game and wanted to send messages between tow players does web sockets work with scalaJs?
The short answer is "Yes".
The more useful answer is that just about anything you can do with JavaScript, you can do with Scala.js, so likely all JS websocket libraries can be used with SJS. If you don't find a Scala.js-specific library that suits your needs, you should look for a JavaScript one, and then write a Scala.js facade (which is generally pretty straightforward) to hook it up to SJS.
Related
What I want to do: I want to add communication capabilities to a couple of applications (soon to be jar libraries for Java) in Scala, and I want to do it in the most painless way, with no Tomcat, wars, paths for GET requests, RPC servers, etc.
What I have done: I've been checking a number of libraries, like Jetty, JAX-RS, Jackson, etc. But then I see the examples and they usually involve many different folders for configuration, WSDL files, etc. Most of the examples lack a main method and I don't have a clear picture about how many additional requirements may they have (e.g. Tomcat).
What I am planning to do: I'm considering to simply open a socket on the "server" to listen, then connect with the "client" and transfer some JSON, in both directions. This should be fairly standard so that I can use other programming languages in compatible ways (e.g. Python).
What I am asking: I would like to know whether there is some library that makes this easier. Not necessarily using raw sockets, but setting up some process communication in just a few lines, maybe not as simple as Node.js, but something similar.
Bonus: It would be cool to
be able to use other programming languages (e.g. Python) by using open standards
have authentication
But I don't really need any of those at this point.
I think you need RPC client/server system, I would suggest to take one of these two:
Finagle - super flexible and powerful RPC client/server from Finagle. You can define your service with Thrift, and it will generate stubs for client/server in scala. With Thrift it should be straightforward to add Python support.
Spray - much smaller library, focused on creating REST services. It's not so powerful as Finagle, however much easier. And REST allows you to use any other clients
Remotely - an elegant RPC system for reasonable people. Interesting and very promising project, however maybe difficult to start with because of extensive Scalaz+Shapeless+Macro usage
Honestly if you want something that is cross-language compatible, simple, straightforward, and concise then you do not want to use plain old sockets!
Check out dropwizard. It is amazing and I use it for small and large projects alike! It is usually configured by no more than a single configuration file. It supports authentication too!
Out of the box it gives you really great inter-process communication over JSON (using Jackson) and much much more. There is also pretty decent Scala support for dropwizard.
If you must roll your own then I'd recommend using Jackson for JSON parsing. It's super simple to use and also has great scala support.
If you've got a "controlled" use case where the client and server are on the same LAN and deployed in tandem, I'd (controversially) recommend Java RMI; it's dumb and JVM-specific (and uses a Java-specific protocol), but it's very simple to use.
If you need something more robust and cross-language, I'd recommend Apache Thrift. You write your interfaces in a platform-independent interface definition language, and it's very clear which changes are compatible and which are not; the thrift compiler generates skeleton interfaces for you to use, and then you just write an implementation of that interface and a couple of lines to start the server (as you can see from the example on the homepage). It's also got good support for async implementations if you need the performance. Thrift itself is reasonably standard and cross-platform, with its own binary protocol, or you can use JSON as a transport if you really want to (I'd recommend against that though).
RabbitMQ provides one easy way to do what you want without writing a server and implementing your own persistence, flow control, authentication, etc. You can brew or apt-get install it.
You start up a broker daemon process (i.e. manages message queues)
In the Scala producer, you can use Maven-provided Java API to send JSON strings without any fuss (e.g. no definition languages) to specified queues
Then in your other Scala program, connect to the broker, and listen for messages on the queue, and parse the incoming JSON
Because it is so popular, there are many tutorials online for different patterns you may want to use to distribute the messages, e.g. pub/sub, one-to-one, exactly-once delivery, etc.
I would like to use websockets technology in a GWT web application.
I know that there are some implementations using Commet and Atmospere, but i would like to avoid them as they are actually a long lived HTTP request to the server.
I have my own implementation of web sockets and i would like to know if someone knows a client side library or way that i can achieve to communicate between my client/server with websockets. More specifically, i heard that GWT Elemental package provides this kind of functionality. I researched (googled) about that but couldn't find anything specific.
Could someone point me to the right direction? Any suggestions except GWT Elemental are welcomed as well.
EDIT:
I found out the below link, which is GWT-Elemental interface. I can see that it is a ReleaseCandidate version, but i would be willing to try using the functionality. So if anyone has used that before i would like to know his/her comments/suggestions.
http://grepcode.com/file/repo1.maven.org/maven2/com.google.gwt/gwt-elemental/2.5.1-rc1/elemental/html/WebSocket.java?av=f
Well I haven't used Websockets from Elemental but the FileReader API and it worked fine.
However you have to take into account that Elemental is highly experimental.
Some of the specifications in the IDL of Webkit have changed since the Elemental library was auto-generated and thus won't work.
So you might need to find workarounds, etc.
Working with Elemental is quite straightforward.
You usually use Browser or Window from the package to get an instance of the class you want to work with.
Something like this:
Window window = Browser.getWindow();
WebSocket webSocket = window.newWebSocket(URL);
webSocket.setOnmessage(new EventListener() ....);
websocket.send();
I know Scala. I've used mongoDB, redis, sbt, ... backend stuff.
I know basic HTML, CSS and JavaScript but have never done real web development.
I don't know what AJAX is. I don't really know any frontend stuff.
What should I learn before I start trying to tackle Lift?
If you know Scala, you are pretty much set on the programming side.
On the other hand, Lift requires HTML/CSS templates. In fact, it is completely separate from programming, so that a professional web designer can work on them, while the programmer works on the code. If you can revise your HTML/CSS stuff, it will help.
You don't need to know AJAX -- that part Lift takes care of for you.
So, it seems you are mostly set. I strongly recommend Timothy Perret's Lift in Action, from Manning. Though the book hasn't been released yet, you can get the Manning Early Access Program (MEAP) for it and, as it happens, the whole book has been written already.
If you already know Scala, learn some basics of web development and how Java handles it:
HTTP protocol
Servlets (also know what JSP is)
AJAX
Is there a bare-bones Scala web framework? I basically need the essential features such as:
Routing.
GET/POST/PUT parameter handling.
A simple templating engine (content substitution based).
Serialization (JSON, YAML)
I don't like Lift as it does too much for me, as I would like complete control over the generated HTML, meaning that I want to be able to write 100% of the HTML/CSS/JS code.
Is there such a framework? Or is it possible to use Lift in a way that no HTML is generated behind the scenes? Or would I be better of writing a normal servlet?
Perhaps you'd like something like Scalatra or Unfiltered? On a separate note, you need not give up any control of your HTML/CSS/JS in a Lift app if you don't want to.
You can just use Lift to generate services, such as REST ones, is that more or less what you are looking for? http://www.assembla.com/spaces/liftweb/wiki/REST_Web_Services
If we take a look at What Scala web-frameworks are available? none of them have a great simple templating engine, at least to me it seems that way. SweetScala seems the closest though http://code.google.com/p/sweetscala/wiki/GettingStarted
Peter gave a great answer... I'll expand on it a little.
Lift gives you a ton of control and access to raw HTTP requests as well as providing a ton of abstractions on top of the HTTP level. It's your choice on how much or how little you want Lift to do.
You can built a REST-based application using Lift's RestHelper. See http://simply.liftweb.net/index-Chapter-5.html The advantage that Lift's RestHelper gives you over most MVC/Routing based approaches is type-safety and access control at the very edge of your application. But using Scala's pattern matching extractors, you can insure that parameters delivered to the business logic of your application have already been materialized and checked for access control. Further, Lift's REST support will be as concise or more concise than other web frameworks.
In terms of Lift's HTML handling, you have a ton of control over the creation of the HTML, as long as you want to generate HTML as a valid DOM rather than as a series of Strings.
Most web frameworks force you to emit Strings when you're composing HTML. It's up to the developer to properly HTML-escape Strings. It's up to the developer to make sure that closing tags line up correctly. With Lift, you get this kind of thing for free.
You can serve HTML from Lift apps in MVC style. See https://github.com/dpp/hoisted (this is the code that powers http://liftweb.net)
In the "standard" configuration of Lift apps, Lift does some post-processing of the HTML if, and only if, you use certain construct. So, if you put a <head> tag in the body, the HTML page, Lift will take the contents of that <head> tag and move it to the head section of the page. If you include calls to Lift's Comet support, Lift will insert JavaScript on the page to do long polling. But these features are optional and they only happen if you use certain features in Lift.
I hope this helps you understand the benefits of using Lift.
Two more frameworks for you to consider:
Play is a simple REST framework that is gaining in popularity, and has a nice Scala interface. Its templates translate relatively simply into Scala functions. As of a couple months ago there were difficulties with using JSON packages (like lift-json) that unpack data into case classes because Play has a custom classloader for rapid development. Not sure if this issue is resolved. The Scala company Typesafe uses Play for their site. Play integrates with Akka, and one of the Akka lead developers, Viktor Klang, recommended Play a while back.
A little further off the beaten track, there is Spray. I can't speak to the details, but the Wiki looks intriguing. To my eyes, Spray looks to be elegantly designed around Akka integration. I don't think it comes with a templating engine, but it would probably be possible to interface with Scalate (see the mailing list discussion).
Not a Scala framework per-se, but I've had good luck with Jetty+JAX-RS+Scala+Freemarker. These are all pretty heavily battle-tested technologies, and there's no problems with Scala integration. A small shim is necessary to adapt Freemarker to understand Scala collections and properties, but nothing challenging.
Scalatra is pretty bare bones with the scala goodness. Easy to configure, easy to handle Bare HTTP stuff. It is similar to sinatra of scala.
Scalatra also has good Maven support and coexists well with traditional java servlets.
The modern Scala web framework are: Play (on Akka HTTP), Scalatra (Akka Actors) and Finatra.
https://www.reddit.com/r/scala/comments/743zjv/web_framework/
Has anybody done or seen a deployment of Apache Thrift in an iPhone app?
I am wondering if is a reasonable solution for a high-volume, low(er)-latency network service for iPhones compared to HTTP.
One noteworthy thing I found is a bug report about running Thrift on the iPhone, which seems to have been fixed. But that doesn't necessarily indicate that it's a done deal.
Thrift and HTTP aren't mutually exclusive. In fact thrift now ships with an HTTP transport implementation to use. It's also a really nice way to auto-generate server/client code that avoids a lot of marshalling/unmarshalling boilerplate while still being really fast. Its internal representation is basically binary JSON, so it's very similar to a RESTful web service (except being easier to code and much, much faster).
So... anyone able to answer the original question? If not, I'll dive in myself with thrift's included Cocoa support and see how it works on the iphone.
Just my two cents..
The accepted answer to this question, is an opinion to not use a technology, not an answer of whether it is possible.
Thrift, is an interface definition language, IDL, like Protobuf and Capt'n'Proto. They permit the definition of a client/server/server protocol which is platform agnostic. JSON and Plist don't provide the same level of type conformance.
Having previously lead an iOS team with 10Ms MAU using Google Protobuf v2.5 on iOS, Android, Windows, and server teams, I can attest that IDLs are great on mobile. Apple uses them for syncing iWork content.
My current team uses Thrift for iOS and Android clients, with a mostly Scala backend. I much prefer it to Protobuf.
We send Thrift payloads over HTTPS and WebSockets. Once you have defined (in Thrift) your our wire communication protocol (i.e. frame structure), it's very easy to evolve your APIs.
However, on iOS in particular there are some implementation issues. The current version of the library is quite poorly packaged, and if you hope to make an Objective-C framework (e.g. for iOS 8+), then you will not be able to out of the box with v0.9.2. This is because the library headers include local imports, (#import "TProtocol.h" instead of #import <Thrift/TProtocol.h>) with no umbrella headers. Worst of all, the Objective-C compiler generates very messy Objective-C classes, also including local imports from the Thrift library.
Some of these issues are pretty damning. It indicates to me that while use of an IDL is very much a good engineering decision, not many iOS teams are using Thrift, unless they're huge with the resources to write their own library.
I've always disliked frameworks that use a common interface definition that builds out both server and client code. It keeps both sides too much in lockstep where in reality server API changes must be very flexible in the versions of clients that are communicating with it.
There are helpful libraries that make JSON or PLIST communication over HTTP pretty easy, and decades of debugging and understanding the HTTP protocol and how to use it well. I would ignore that at your peril.
I have used thrift's objective c bindings for a large iPhone app with a few million users. As one of the posters mentioned we can use Http which gets the best of both worlds. However there is no asynchronous HTTP client for thrift. We had to build an event based wrapper to allow non-blocking I/O calls. The underlying layer still issues one call at a time which hit us in a big way because we have one server call that takes a long time but it does not block UI flow and another really fast one that does block UI flow. If the underlying layer is busy with the slow command our fast command just has to wait. I am trying to build asyc http in c++ which can then be used on the iPhone but that is someways off from being ready.
Thrift as an external API doesn't make sense. Use it internally rock and roll.