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.
Related
We need a restful backend that provides APIs for a mobile app.
We also need a admin website to manage the restful backend.
Right now we have Sails.js as the backend framework, Vue.js as the frontend framework.
I m pretty new to MVC frameworks and I am a little bit confused how should these two frameworks interact with each other:
Should:
The frontend framework lives indepedently (maybe on a separate server), it calls api exposed by the backend framework, or
The frontend framework lives INSIDE the Sails.js, acting as the "views" for the Sails framework
I am not even 100% sure is my question a valid question, I want to know which are the popular ways and is there any pros and cons?
You can do both i.e. keep frontend framework in Sails project as well as separate independent project.
I have done both and I keep following points in mind while making this decision:
If the project is complex enough then its better to create a separate project using some scaffolding tool.
If the project is going to change frequently and evolve on its own then also its better to create a separate project.
If some one time/small view is to be made then I would prefer to keep it part of Sails project
Since you are using frontend framework for admin panel which I think
will be complex, I would recommend you to create separate project on the same server.
You can use yeoman for scaffolding. I have used it for some angular projects and it works great.
Your question is too wide for a single explanation, but the main concept is as per my understanding is data binding.
You can find a lot of free screencasts for starting from scratch, assuming you already know some JavaScript.
I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ
I'm working with NodeJS + Mongoose, writing a Single Page Application, so I need to serve some statics and then all the interaction between frontend and backend is done via XHR. Eventually I'm thinking about writing a native mobile app accessing the same backend. Is there any pattern / best practice I should apply here?, I thought that I may need to extract the API to be exposed via Restify, and handle the requests from the webapp only with ExpressJS? or should I just put all the stuff exposed via Restify? I guess my confusion comes from not being worked with Restify before, so any explanation about how is it different from ExpressJS (specially when talking about a Single Page App) is really welcome.
I am implementing a similar solution, mobile app & website with expressjs and backbonejs. I did not use restify because i did not think i needed the extra complexity, there were not that many API endpoints so expressjs handled everything ok for me.
BTW take a look at this post on restify performance, I just saw it today and have not personally validate the contents.
Benchmarking APIs using PerfectAPI vs Express.js vs Restify.js « « PerfectAPI Blog PerfectAPI Blog http://bit.ly/xrTguB
Restify is packaging DTrace and various handlers that Express doesn't. If you just have one API endpoint and don't need DTrace, it doesn't make sense to run Restify.
Also, you might want to try express-resource
Using Google App Engine SDK:
webpage: http://hwsejk.appspot.com/
I'm trying to make a web server using java and jsp (it is a web server for an iPhone application). I don't know a lot about java so I'm having a lot of troubles trying to construct a server by myself. For now, I have tried implementing cookie, database, and some other methods. Now that I've given you basic information about my web server, I have a few questions to ask.
Is it the right approach to use java and jsp to make a web server like this? the java servlets get and send user inputs to different jsp pages, which contain some HTML and java code. But I've found some posts here that it's a bad practice to use jsp like this. I don't know how else I can make webpages. Could anyone please recommend the right approach to make a web server (like the one linked above)? I would love to know if there is some kind of a template that I can take a look at.
What you are making doesnt seem to be a "server" at all but rather a "web application" or "web site". The former implies you are creating a piece of sfotware to implement a specific protocol like HTTP, FTP, etc. while the latter is making a series of web pages or and application that runs on server.
You can create a web application in any number of languages, not just Java. From the screenshot you shared i would think that using Rails (Ruby), Django (Paython), or Symfony2 (PHP) would probably get you up and running pretty fast as it looks like you dont need much more than some basic model scaffolding with a pretty face.
If you are familiar with Java you might also want to try the Play! framework...
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