I new to this concept of RSockets, I wish to build replace a webchat built with WebSocket's in the browser (using vanilla JS) and replace it with Rockets is there anything that can help me to learn and build something better and more efficient, the back end I will use spring boot flux?
Related
I'm working on a project in my University, and we want to use an Apache OpenWhisk service for our student projects. I already set up the OpenWhisk service and add some components like Java, NodeJS and Python, everything works fine. My next step is to set up a webserver, so our students can use this instances to publish their websites (written in HTML, PHP, Java Script). I have already searched for this topic but don't found anything.
Hopefully someone can help me.
There are several ways to accomplish this and it depends on how far you want to go in the serverless direction.
For example this repo https://github.com/jthomas/express_example is a way to package an existing web server inside a function. This is another variation on the same https://github.com/IBM/expressjs-openwhisk.
If you want the students to implement a serverless web application from scratch, then generally every API end point becomes a function using web actions https://github.com/apache/openwhisk/blob/master/docs/webactions.md.
You can use web actions to also serve static content (html, js, css) by inlining those files and returning them as part of the function result. This is not ideal and should be done from a CDN instead. OpenWhisk itself does not offer object storage/CDN support but you can use S3 or Google buckets to accomplish the same.
Some serverless platforms like Netlify or Nimbella might be suitable. The latter provides an integrated CDN + OpenWhisk to implement entire web applications including JAMstack.
I am somewhat new to the domain of web development. I am investigating Play2 and am trying to understand, do you need some kind of JS frontend framework to go with Play2 and Scala?
I notice that Play2 has a template engine, but it seems that it generates the HTML on the server and sends it to the browser. Does this mean that the need for a JS frontend like Angular2 is made irrelevant? Or is there still a reason to use Angular2 in a Play2 application? What instances would it make sense and why?
I have some experience of using Play 2 with AngularJS (currently rewriting frontend to Angular2).
I use Play 2 (scala) only for RESTful JSON backend, which is just great for this purpose and I use Angular for single page application frontend. I find this combination brilliant.
My project is hosted on GitHub, you can check it out here
There are three directories in the root:
restful with all backend stuff, written in scala, using Slick for DB,
taking advantage of Play evolutions and all other stuff.
angularjs-client-deprecated with AngularJS code. I used angular-resource for making calls to backend.
client with Angular2 code. There is nothing there so far except for my experiments, however I've written a simple service for authentication with security token.
To summarise, I've been developing my project for almost 2 months so far, mainly to learn both Scala and AngularJS (now Angular2).
If you're planning to use JS framework for frontend, I would recommend you to use Play2 only for RESTFul Json backend. I don't see a reason to use Play2 html template engine in this case.
Play is more about Server Side templating, which isn't all that useful if you're using Angular. It can be done, but it comes with some overhead. I've worked with Scalatra in the past and it worked really well for me.
http://scalatra.org/
Other options include Spray, which is very similar from the outside, but uses Akka internally and uses non-blocking I/O, similar to Play!
http://spray.io/
With angular it is better to go with simple rest/http api like Akka-IO or spray for data and other stuff. Play will be less relevant with Angular.
As others have pointed out Play2 isn't really the best option for building responsive websites. I have a seed project which can help you get started with Akka Http and Angular 5...already configured to deploy to Heroku in a single web dyno.
https://github.com/jdschmitt/akka-angular-heroku
Check it out. I hope it helps anyone landing here looking for a way to manage back-end and front-end in a single repo for simple projects.
I am new to the Play! web framework, and in order to understand how it works, as well as how it compares with other web frameworks, I would like to be able to trace, in the Play! source code, the request lifecycle from start to finish. I will be using the Scala implementation of Play!.
Because most of my experience has been with PHP frameworks, I am used to starting with an index.php file in a web root directory and reading down through any included config/bootstrapping scripts, dependency injection handling, request routing, action dispatching, and finally view/response rendering.
I have not been able to identify a similar point of entry for a Scala/Play! application, and I would very much appreciate a push in the right direction. A walkthrough of the request lifecycle would of course be very generous, but all I really need is to be shown the entry point.
By default Play framework uses built-in HTTP server (based on Netty). So closest analogy with PHP will be that Play is both Apache and PHP.
PHP uses legacy 'CGI-like' paradigm: to serve single HTTP request, your program is started and after finishing serving request it is terminated. In CGI to serve an HTTP request webserver starts external program -- your script -- and returns its output. Older versions of PHP was designed only for CGI, in later versions other ways to interact with server, because CGI is very slow, but core principle remained the same.
Most of web application technologies use another approach: your web application is started one time then stays running, so one running instance of web application continues to serve requests (and can serve multiple requests in parallel). It does not die after serving a single request, as in PHP. This allows to consume much less resources required for starting application each time, and only just slightly harder to work with, because most of request processing in hidden inside framework, and your app only needs to expose controller methods that are called when request arrive and return response.
It also allows for more flexibility, for example background processing can be started right inside web app, no need for external server processes. Play has Akka library that is very convenient for this.
As more and more web applications use Ajax and REST approach, instead of serving heavyweight webpages each time, it becomes more important. And it is almost impossible to create realtime messaging backend with PHP that will have good performance, regardless of requesting technology (polling, long polling, iframe with multipart).
But if compared to PHP MVC frameworks, from point of view of developer that creates views, models and controllers, Play is very similar. Both in PHP MVC frameworks and Play framework calls controller method or function and this method should return response, views are usually templates and models are usually ORM bindings to relational database.
I think this is the file you mean:
https://github.com/playframework/playframework/blob/master/framework/src/play-netty-server/src/main/scala/play/core/server/NettyServer.scala
Play is a Java application that starts listening at a given port. Listening is done using Netty library which understands different types of network protocols (most importantly HTTP). Once Netty knows whats happening it will give control to the Play framework.
The Play Framework will then use the Global file in combination with the Routes to determine what Action to invoke.
Play is more of a restful framework ( read http://en.wikipedia.org/wiki/Representational_state_transfer) rather than a typical template based frameworks like jsp jsf etc with a request lifecycle concept, although it does have templating support too. The basic idea is too have the interaction with server based on pure data like json and most of the code for update of dom structure is written in javascript and is done on client only which is actually more flexible and a lot simpler and efficent.
In play you just plainly create your methods for sending data to browser by defining a method in your scala class and mapping it in a routes file. Also like in a typical web development process you also place you html files in a public resource folder ( or create a template ) which will typically do a ajax call to that method when executed in browser.
I am developing one application with GWT as client and my server side code written in Java servelt and I am fetching some data from another server. that another server code is in Scala. so the question is how can i push data from another server to my main server and display that data to client using comet ( gwt-comet.jar)
Please help me.
Thanks
Comet is something that your web server must support, via continuations or some other implementation (see this as an example). Usually web frameworks (like Lift) have some wrapper around this mechanism to facilitate using it.
I'm no expert on GWT, but for what you say it seems it has a Comet library. Using it should be as simple as to implement classes following this library specifications and using a server that supports Comet.
For web application development, I've been steeped in dynamic languages such as Ruby, PHP, and Python. Using popular frameworks for these languages, all my knowledge about HTML, CSS, and JavaScript transfers fairly straightforwardly: templates are basically HTML with embedded code that the server executes to generate the dynamic sections of the page.
Lately, I've been thinking about using GWT for building the UI of my next project. At this point, I'm just trying to wrap my head around how development with GWT works, as seems to follow an entirely different paradigm. In addition, it seems there's an unstated assumption that the server-side part of the app is written in Java. Would it be impractical to use something other than Java for the server side?
Related question:
GWT + GAE python: frameworks for COMET & RPC
While not actually impractical I would say that you get the most value from GWT by having the same code on client and server, since it allows for easy code reuse (fx. if your data objects are serializable then you could just send them directly to the client). So I guess my answer would be; yes you can do it and it's going to be more work than just having Java on the server side.
I don't think there's any requirement that you use Java on the server. At the end of the day, GWT compiles Java to JavaScript. You can do all the comms via the RequestBuilder object, you don't have to use the RPC services.
I guess the question is: if you don't like/know/prefer Java on the server side, why would you use it on the client when it's effectively an abstraction over JavaScript anyway?
There is no requirement to use Java on the server side. GWT supports JSON out of the box. Any server side component that can generate JSON ( or other supported serialization methods ) will work. You could use PHP on the server side, or bash shell scripts, it doesn't matter to the Javascript code that is generated by GWT.
Yes, it can be practical. I use Rails as my backend and GWT/GXT as my frontend. I love every bit of it! I couldn't stand worrying about browser incompatibilities, so GWT/GXT was a real joy. Also, I had already started my backend in Rails and did not have much experience with Java on the server, so I stuck with Rails.
You may want to take a look at an appropriate GWT Rest framework, as you won't be using RPC.
As an aside, there is one exception where you should use Java on the server. That's if you want to use Google App Engine.
Feel free to ask me any specific questions and I'll be happy to help you out.
Good Luck.
-JP