I currently have a Kotlin app that I'd like to expose with a REST API server. I'm finding really hard to decide for a web framework to build around it.
My background is Node.JS with express and I'm trying to find something at least similar to it at the level of middleware and modularity. But since I just started learning Java recently the getting started part is the major entry-barrier.
What striked me as appropriate was Spark but I can't find a way to separate my routes between different files and have local-per-file middleware.
I considered Play but it seemed that it needed a very big level of setup for a new app, even more if it's an existing one.
While my app ain't that big I plan on evolving it so I need something that can scale appropriately. So I'm asking what options do I have? I'm really looking forward on working with Spark if I can tackle those 2 issues previously mentioned, any help about them is appreciated.
Try one of these:
https://projects.spring.io/spring-boot/ (lots of libs, quiet complicated, but powerful)
http://restx.io/
Jersey2
Resteasy
Related
I've been using java + spring on tomcat for the past 2 years and my app is getting notably huge. Start up time is now almost 3 minutes and it consumes a lot of resources during the development.
So I am interested in ideas how to make developing a software fun again. I've looked at Spring DM/Gemini blueprint to make it a modular but the experience was not convenient.
Now more modules are about to be added, thinking about developing it another web application and use Spring integration for messaging. Apparently, this will be a very painful experience to develop it on one desktop computer.
Has anybody any experience with cloud development? How do I improve all these time and resource consuming tasks? Will developing in the cloud help me?
It is very common problem with typical java+spring web apps. With age they start getting bloated and Context Loading starts becoming painful. I can suggest a few pointers to mitigate the issue, but only you will be able to judge best for you depending on the what exactly goes in your app.
Don't depend heavily on server while doing development. Write Unit tests and run them outside the servlet container. Spring has excellent support for this.
Split you business logic in Rest/Soap web-services (judiciously and carefully). This gives you freedom of developing and testing the UI independent of core business logic.
If using maven/gradle, try jetty plugin. It can keep scanning for changes and reloads the webapp automatically (I think tomcat plugin can do the same). It has ability to store session between restarts, so you are not affected by restarts. Please see this for more details How can I speed up Maven and Netbeans
[Paid Option] may try JRebel.
Use CI server, that keeps on integrating/testing/deploying your app, taking some load off your developers machines.
First, take care of the bottlenecks. They have a tendency to creep into projects as they grow. The original design has been compromised again and again to meet insane deadlines and now bloat has killed a once lively application.
Do not guess at the problem but use real data to determine what is making you app slow. Use a profiler such as jProfiler: http://www.ej-technologies.com/products/jprofiler/overview.html
Next, use what you've learned to make the new modules more efficient. The bottom line is changing technology is not a fix all, as all technologies can present bottlenecks. You must find the reason behind the problem and fix that.
Once you fix the bottlenecks, you could create some test projects on a new technology to see if it is faster, easier, does what you need. But, chances are just fixing the problems on your current stack is all that is needed.
I've been asked by a client to develop a server heavily based on web services and web interfaces (HTML + Ajax GUIs). Now before I start googling, I'd like to hear from you all, what do you recommend for such a task. My goals:
Work with Spring + Hibernate (This is a basic requirement). I know there is Spring-WS, but it seems a little bit complicate. More it doesn't seem to integrate with Eclipse or Netbeans web service generation functions.
Be very very simple, to the level that every newbie can get into that easily and even seasoned developers, that are not so sparkling with new technologies, can work with it.
Ideally I'd like it to be easily assisted by IDEs like Netbeans or Eclipse, or Both!
I'd like if it is possible to have the same application serve J2EE webpages and the services
REST or NOT?
I don't want to implement nothing by myself, but I want to rely on existing solutions. I mean, I've been thinking of using JSON-RPC, but I've seen around that it is poorly supported on many platforms, plus I'd have to write certain parts by myself. I'd like proven technologies that work.
And eventually I'd like it to make coffee for everybody... no okay I'm kidding about this :)
check apache CXF. it is pretty simple and supports spring
http://cxf.apache.org/
Regarding REST it depends on the type of service you are trying to implement.
If the information you are returning would fit well in a tree structure then a REST service will map it very well and clients can get the granularity they need.
If you can't really 'drill down' into your data then maybe REST does not fit.
We are occasionally in a position to take over PHP based projects, but as we are a Java-house we are searching for ways to turn a PHP-project (or codebase) into a Java-project.
The approaches we came up to work in a mixed Java/PHP context are :
PHP in frontend and Java in backend with separate front (PHP+JavaScript) and back (Java+SQL) teams
using both technologies in a Java webapp, for example via Quercus with one or multiple teams
migrating everything to Java
We haven't tried any of these approaches as we've been lucky enough to have enough Java-only projects to work on.
Do you see other approaches, or have you tried any of the described approaches?
I've used Quercus. I think that if it supports something like Drupal then it's probably fairly mature. If your PHP app works out of the box, then it offers you a very gradual upgrade path to Java since you can write your own plugins in Java and expose them to the PHP layer, such as using a JDBC back-end.
How easy it is all depends on how well separated the layers are in the PHP application. For example, if the view layer is well separated, you might be able to replace both controller and model logic with a Spring MVC application that uses a 'QuercusView' for the view - you may be able to re-use a lot of the PHP view logic.
You should also consider how you can make a survey of the PHP code - maybe a script that extracts all the function calls, imports etc. so you can quickly test the Quercus support for them.
Sorry, I haven't used the PHP-Java bridge, but I think the Quercus library is pretty mature these days, so that would be my first choice for a staged migration.
My experiences with Querces are not so good. Maybe it has improved, but when I tried it something like two years ago (a long time, I know) it was far from complete and did not support all functions yet. Also, if your application is using some extensions (e.g. from PECL) you will experience difficulties getting this up and running under Querces.
We're currently in the process of migrating a web application from PHP to Java. We're designing a SOA and we'll probably replace some data access objects in the PHP application with a version that talks to internal webservices. Currently we're using Thrift as protocol for our internal webservices, a framework that also has a client available for PHP. We expect this to increase flexibility during migration (allowing us to do step-by-step migration, rather than all-at-once)
PHP/Java Bridge may be of your interest:
The PHP/Java Bridge is an
implementation of a streaming,
XML-based network protocol, which can
be used to connect a native script
engine, for example PHP, Scheme or
Python, with a Java virtual machine.
It is up to 50 times faster than local
RPC via SOAP, requires less resources
on the web-server side. It is faster
and more reliable than direct
communication via the Java Native
Interface, and it requires no
additional components to invoke Java
procedures from PHP or PHP procedures
from Java.
NUMITON may be useful for you:
http://java.dzone.com/announcements/automated-translations-php-jav
The shortest route from PHP to Java
Numiton offers an automated alternative to migrating PHP codebase. This way,
established applications can benefit from the advantages offered by Java in its
enterprise-level capacity.
Some of the risks inherent to any software migration are avoided by using an automated
translation tool. Our PHPtoJava product performs variable type inference,
objectualization and other operations in a uniform manner, the resulting appearance and
behavior being identical to what the users already know.
Of course, the human factor still plays an important role in the post-translation
phases: application fine-tuning and functional testing. The speed and accuracy of the
entire process surpass however those of a manual translation.
One of the applications we have migrated this way is the well-known forum engine
phpBB. The translation result, nBB2, powers our own forum and was recently donated to the
open-source community as a SourceForge project.
PHP in frontend and Java in backend
with separate front (PHP+JavaScript)
and back (Java+SQL) teams
This is technically feasible using SOAP.
using both technologies in a Java
webapp, for example via Quercus with
one or multiple teams
I have no idea about this
migrating everything to Java
This is better option, but it will take time depending on the size & complexity of your project.
I do not have any experience running PHP inside a JVM, but I am betting that IBM does. :)
You might consider Project Zero.
http://www.projectzero.org/php/
Seems similar to Querces or that other thing someone linked. The only other thing that you didn't mention that I can think of is to refactor the PHP code because I'm assuming that its an older codebase written in a PHP 4 manner.
I know this is 2 years old question but i still want to contribute. We are migrating from full java portal to php+java. We have 14 million users. This design doesn't need web services because we use java as json provider for php and js. We will see the result soon...
PHP in frontend and Java in backend with separate front
(PHP+JavaScript) and back (Java+SQL) teams
I would like to create a RESTful app on Google App Engine. I would like to provide XML and JSON services. I have briefly experimented with Restlet, Resteasy, and Jersey. I haven't had much success with any of them, other than some simple examples in Restlet.
Could you share your experiences creating a Restful web application on Google App Engine using Java or provide any insight on the aforementioned toolkits on GAE?
Thanks!
Edit (2009-07-25):
I have decided to use Restlet for the time being. It seems to work flawlessly so far. Please post any other insights/opinions you may have. What problems have you encountered? Have you successfully used Jersey/Restlet/Resteasy on GAE/J? If so, we want to hear about it!
I'm happy to report that Restlet M3 works FLAWLESSLY on AppEngine 1.2.2. I have followed the "First steps" and "First resource" tutorials found http://restlet.com/technical-resources/restlet-framework/guide.
So, it seems to me that Restlet is the answer for your GAE/J Restful applications.
I'm using Jersey on GAE. Here is the link for those who are interested about setting it up: (I'm using GAE SDK v1.4.0):
http://tugdualgrall.blogspot.com/2010/02/create-and-deploy-jax-rs-rest-service.html
I am going to begin exploring this as well, but haven't started yet. I did find this framework, that says it should work, but like I said haven't tried it yet.
http://wiki.restlet.org/docs_1.2/13-restlet/275-restlet/252-restlet.html
If you get it working, or manage to get one of the above suggestions working, update everyone as I am sure there is interest in this.
I'm using Restlet together with Guice on Google AppEngine. IMHO they fit together very well. See my recent blog post for further details: http://haraldpehl.blogspot.com/2009/11/google-appengine-restlet.html
Since these valiant older solutions were patched together, Google has apparently supplied an Eclipse plugin to create a starter project that produces an App Engine app, an Android APK, and a Web app, all talking to one another over an interface defined by a single set of annotated object declarations.
Haven't tried this yet myself, but do have a look before trying any of the more heterogeneous examples described in the earlier messages above:
https://developers.google.com/eclipse/docs/appengine_connected_android
This Google video is also quite informative:
http://www.youtube.com/watch?v=NU_wNR_UUn4
For what it's worth, there has been quite a bit of discussion on Jersey user lists wrt how to make Jersey work on GAE. It is bit tedious work due to GAE restrictions (missing classes from white lists -- hopefully resolved over time), but apparently can be made to work.
So while not trivially easy, that might be your best bet; esp. since many of the problems faced are the same for all frameworks (imposed by GAE).
Well, I would highly advice you to have a look at play framework
Have a look at the video on the homepage
It has a gae module
With siena as a orm to handle gae datastore
From all the java frameworks I've seen so far, I think it has the easier learning curve,
great documentation,
a tutorial to develop a complete application
very active and helpfull community,
free as in beer and also as in speech
highly scalable due to it's stateless out of the box design
rest friendly
highly customizable via it's modules and plugin approach
more over, taking into account it's for a college course, it's really easy to hack into the code, I could handle a couple of tickets and new features without any experience at all with java, just a couple of year developing web applications with php
other benefits
it's really easy to start, no complicated setup involved, just download and unzip the file and your are ready
great development experience, just fix the code and hit refresh, play autocompiles changes on the fly when running on development mode
fast and lightweight
fullstack, you don't have to integrate cumbersome frameworks to make it work
great errors report, no more endless error stack trace, just shows you the line with error
no xml configuration anywhere around
great support for tdd with selenium integrated test
I think the main advantage as a learning tool, is that it's possible to peek into the source code without feeling lost and the community support... The documentation is very clear, and you can learn a lot by just having a look at the source code...
I recently put together a project template with Jersey, Guice and AppEngine at GitHub. It has been developed with SimpleDS, but it can be modified to work with Objectify / JDO easily. The project is live here.
It should be a good starting point for new projects.
Here is a very very good tutorial Restlet/Android/GAE/Objectify with an example of a simple application. Sorry it's in french, but you can juste copy/paste the code, or use google traduction.
I followed it and had a working Android / GAE server communicating together in a 2 hours. It's a good base to start or test Restlet.
http://www.tutos-android.com/webservice-rest-android-appengine-restlet-objectify
Good Luck
The 2 most cumbersome GAE REST API actions to make work, whether Java or .py, are graphics and how to undisplay private information. My little gae rest feed forked another project. I'm sure Java succeeds where python stuck due to the Java takes and gives more ways (advantages) as well as longer (slower) time to succeed (disadvantage) while python projects opens less ways to succeed (disadvantageous) and less development time (advantageous rapid development) to succeed the same.
If you have a Java based web application (J2EE webapp - never mind which other underlying frameworks are being used), and you wanted to introduce a Flash based front-end, would you use Laszlo or would you rather expose a ReST-like XML interface and build and deploy a Flash application that uses that?
On one hand, Laszlo is quite amazing - doing for Flash what JSP does for HTML. It is easy to work with. It fits in very well with the rest of the web application (which is JSP based).
On the other hand it might be better to develop a complete Flash app decoupled from the server and use an XML-over-HTTP mechanism to bind the two. This would have the added advantage of being able to use the same XML interface for an AJAX front end if needed.
What would you do, and why?
I would create the contract-first services, deploy them separately, and then write the RIA client to access them.
Coming up with the schema first has the added benefit of completely decoupling the two during development. The RIA developer can create some synthetic XML streams to use for data while waiting for the services to come on-line.
I might have considered Laszlo in the past, but today, I'd stay within the Java stack and use JavaFX.
Laszlo is the product that never made it, there isn't a big enough ecosystem of developers around it.
I'd use Adobe Flex for the front end. The same benefits of using a markup language for doing flash, but it has a much larger developer base and open source projects to draw upon. For the data communication, use either REST or if you want to get clever, use BlazeDS.
OpenLaszlo is a complete RIA framework, so I'm pretty sure that you can 'compile' it to a completely standalone app that communicates with the server over HTTP. It's really very similar to Flex. The advantage Flex has is a much bigger community, a full-blown IDE, and more resources (Adobe), while OpenLaszlo is a little more innovative in that you can deploy to Flash or AJAX from one codebase.
I've actually spent some time working on a implementation similar to what you're suggesting. I had a complied Open Laszlo front end embedded in a web page with a Django (a python MVC library) REST interface on the backend and no Open Laszlo server. It works reasonably well, but there are a couple of things to watch out for. Open Laszlo only supports calls to GET and POST, so you won't be able to easily use the DELETE and PUT methods in your REST API. The other is the lack of community around Laszlo (as mentioned elsewhere). I can sometimes be frustratingly difficult to answer some basic questions when using Laszlo, particularly around the XML HTTP API and XML replication features in the framework. I personally never really looked at the Laszlo back end server seriously as I wanted an open API that could be consumed easily by other clients.
All this being said, the implementation does work and can be effective if you're willing to work around the limitations mentioned above. Plus Open Laszlo is free, which can be a really big plus if your working on a budget.