I like what I read about Lift, and I like the concept of Dart, but have little experience in both to be able to decide if thinking about using them in the same project is even making sense.
I want both writing structured client side code, and not having to worry about the OWASP top 10 as much
Can they work together? Does it make sense at all? Did anyone try?
I have integrated Dart with Lift using REST services together with Dart's XmlHTTPRequest and liked the result. I would say that any web framework that makes making RESTful services as easy as Lift does is a perfect match for Dart. On the other hand web frameworks such as JSF which requires components to take part of a advanced life cycle are probably not a good fit.
That being said, having the same language on the client and the server side is definitely a win, so when the Dart VM matures a bit more and starts to include RESTful functionality similar to what Express does for NodeJS then I would probably use that instead.
Already now baby steps are being taken for including HTTP support in Dart semilar to what Node provides on V8. Another important point for Dart is that it allows the browser and server to share rich objects, like what GWT does for Java, and this should further ease building advanced web applications with Dart.
Related
Let's suppose I was going to design a platform like Airbnb. They have a website as well as native apps on various mobile platforms.
I've been researching app design, and from what I've gathered, the most effective way to do this is to build an API for the back-end, like a REST API using something like node.js, and SQL or mongoDB. The font-end would then be developed natively on each platform which makes calls to the API endpoints to display and update data. This design sounds like it works great for mobile development, but what would be the best way to construct a website that uses the same API?
There are three approaches I can think of:
Use something completely client-side like AangularJS to create a single-page application front end which ties directly into the REST API back-end. This seems OK, but I don't really like the idea of a single-page application and would prefer a more traditional approach
Create a normal web application (in PHP, python, node.js, etc), but rather than tying the data to a typical back end like mySQL, it would basically act as an interface to the REST API. For example when you visit www.example.com/video/3 the server would then call the corresponding REST endpoint (ie api.example.com/video/3/show) and render the HTML for the user. This seems like kind of a messy approach, especially since most web frameworks are designed to work with a SQL backend.
Tie the web interface in directly in with the REST api. For example, The endpoint example.com/video/3/show can return both html or json depending on the HTTP headers. The advantage is that you can share most of your code, however the code would become more complex and you can't decouple your web interface from the API.
What is the best approach for this situation? Do you choose to completely decouple the web application from the REST API? If so, how do you elegantly interface between the two? Or do you choose to merge the REST API and web interface into one code base?
It's a usually a prefered way but one should have a good command of SPA.
Adds a redundant layer from performance perspective. You will basically make twice more requests all the time.
This might work with super simple UI, when it's just a matter of serializing your REST API result into different formats but I believe you want rich UI and going this way will be a nightmare from both implementation and maintainance perspective.
SUGGESTED SOLUTION:
Extract your core logic. Put it into a separate project/assembly and reuse it both in your REST API and UI. This way you will be able to reuse the business logic which is the same both for UI and REST API and keep the representation stuff separately which is different for UI and REST API.
Hope it helps!
Both the first and the second option seem reasonable to me, in the sense that there are certain advantages in decoupling the backend API from the clients (including your web site). For example, you could have dedicated teams per each project, if there's a bug on the web/api you'd only have to release that project, and not both.
Say you're going public with your API. If you're releasing a version that breaks backwards compatibility, with a decoupled web app you'd be able to detect that earlier (say staging environment, given you're developing both in-house). However, if they were tightly coupled they'd probably work just fine, and you'll find out you've broken the other clients only once you release in production.
I would say the first option is preferable one as a generic approach. SPA first load delay problem can be resolved with server side rendering technique.
For second option you will have to face scalability, cpu performance, user session(not on rest api of course because should be stateless), caching issues both on your rest api services and normal website node instances (maybe caching not in all the cases). In most of the cases this intermediate backend layer is just unnecessary, there is not any technical limitation for doing all the stuff in the recent versions of browsers.
The third option violates the separation of concerns, in your case presentational from data models/bussines logic.
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
First off, I've never used GWT before. I have good experience in HTML/CSS/JS/JSP.
I'm looking for people's opinions on the suitability of Google Web Toolkit for a brand new web app I'm developing.
A big requirement is that the UI is attractive and well designed (Does not look like a clunky Java/Swing App).
It should look like any typical HTML/CSS/JS based modern website.
It is an internal company application so no SEO is required.
JSF is not an option.
The web app frameworks used will be Spring Webflow and Spring MVC. It will use lightweight controllers to communicate with a service layer.
Would Spring Tiles combined with JSP be an easier or more flexible option than GWT for what I am trying to achieve?
Advantages/Disadvantages of GWT and other options welcome.
Thanks
Advantages of GWT
You don't really need to know any JavaScript, since all your client side code will be in Java
This is usually the main reason people go for GWT. They're backend developers who know Java but don't know Javascript, and they don't really want to learn it. Still, you should be careful about this. GWT is a very complete and complex framework with many concepts that are specific to GWT. Even though you'll be coding in Java you will still have to go through many tutorials and documentation before you can build a clean GWT app
Ready to use widgets, like date pickers, dynamic tables, layout panels, popups
It's not really specific to GWT. Other front end framework, like jQuery or Dojo or whatever also give you these. You can have a look at the GWT Showcase to see what GWT has to offer.
GWT takes care of a lot of complex and potentially dangerous stuff for you.
Stuff like Cross-Browser Support, Internationalization, Image and static resources bundling, Front end security, Ajax communication with a server, Events and MVP (just like MVC) framework support. Have a look at the documentation, it is very well done and very thorough.
Debugging is easy
GWT has two different 'modes'. When you're building your app for production, gwt will compile all the java code for the front-end that you wrote into javascript. This javascript will be executed in your clients' browsers. But when you're developping, you can run your app without compiling your java code to javascript. This lets you use a debugger to debug your interface. It's a very good tool.
Disadvantages of GWT
As I said before, GWT is a full framework, with concepts specific to it. Don't think that just because it's in java and you know java that you won't have to learn new stuff.
Interfacing GWT with back end frameworks is not easy
The most common way for your GWT client code to communicate with a server is by using GWT RPC mechanism. It means that you will need to have servlets that implement specific interfaces. You should definetly read the docs on client-server communication to see if that fits well with Spring. A search on SO or Google should give you pointers to setup your application.
I need to interface a SOAP web service and, for demonstration purposes, I also need to show the API functionality in a graphical user interface.
I would like this interface to be simple, sleek and nice looking.
What's the best technology to create this UI? I'm familiar with Java, Javascript, CSS, HTML, XML, PHP, etc..
Well, there is are a bunch of different options. You can create an application from scratch using the technologies above.
I personally recommend the playframework at http://www.playframework.org, it provides a lightweight and easy to use Web Service API.
See http://www.playframework.org/documentation/1.2.4/libs#WebServiceclient for details.
PHP is also a very good option, but I think you will get up to speed faster with Play.
Node.js is another excellent option...
Not sure how far you need to go with your UI, if it's just a matter of showing the message being sent and the answer, SOAPui may be enough, there is osx SOAP Client and REST client for mac.
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