Can I use Java backend for a browser game with Javascript frontend?
Since I already have knowledge in Java aswell as Javascript I was confused if I should forget Java for this purpose and skip to NodeJS for the backend, although I want to focus on Java in my future.
Would I need to learn Java Servlets and JSP or would a book aboout Java Networking be enough to deal with communication, or are both required since Servlet are part of a webapplication running on a web container, and Java Networking is not standalone.
You can! The choice of your technology stack for the frontend does not necessarily need to influence the choice of your backend technology (and vice versa).
Architecture
You can serve your game view directly from your java application. You could use JSP (or other templating solutions) for visual representation and/or include more logic via javascript.
You could also go for a more distributed approach, where your frontend would only be responsible for fetching and displaying the game state, while your backend would be responsible for serving and maintaining the game state. Your frontend could then inquire about and ask to modify the game state via http, and the backend might answer with the current game state represented as, for example, JSON.
Technologies
While reading about Servlets and JSP or basic networking can be of some value in itself; For this specific purpose, I'd rather look into some options to get you started more quickly. You might find using an established, modern framework easier - Since you're familiar with Java and want to focus that, I'd point you towards Spring Boot 2. Getting a web application running that accepts and serves JSON via an http endpoint can be done quite quickly. In my experience, it's well adopted in the industry as well, so you might benefit from that, too.
You are, however, free to chose in what language or framework to implement your backend: A server written in NodeJS any other language can be used for the same purpose, as long as you know how frontend and backend are going to communicate.
Related
I am starting my career in programming and I have being trying to learn as much as I can, specially in "new" technologies as Angular 2+, although I like a lot more working on the back-end.
I am currently working in a company that has 4 main applications all running using Java EE 7 in a JBoss application server. The applications have a user interface with is currently based in Java Server Pages (JSP) and Java Server Faces (JSF) (mainly using PrimeFaces framework). My project is related to the migration of the User Interface from those "horrible" xhtml JSF pages to something like Angular 6+.
Needless to say that this this transition should happen with minimum changes to the back end. However, in the way the Back end was originally conceived, the back end is not RESTful (no REST API). So, it is all based on Beans, which makes the back end to be closely tight to the front end, making scalebility an issue.
All that being said, considering that creating such RESTful service, although not completely off the table, is not an option now, I have the following questions:
1) Is it possible to 'feed' the data to my Angular UI using a JSP !? I did some research on the topic, and it seems it is somehow possible.
2) Considering it is possible to use the JSP pages, how much of Angular "great tools and functionality" I would loose in this process (routing, two-way-binding, service injection, etc)?
It would be great to have some unbiased opinion, since I know where the people at my company stand on that issue (they would prefer to not spending the time creating the REST API at this time) and I know where I stand (I would rather create the service, since it would be a great learning oportunity for me). Still, facing the challenges of a real world application, I would like to know the community opinion.
Thank you for the help,
biased opinion, even though you asked for a non biased one
I'm not an authority on JSP, but from what I know, these are server side templates rendered on the backend. If this is the case then you cannot use this with angular. Maybe you can make it work somehow by extending the webpack config and custom plugins which load the .jsp files, but you will definitely lose either the AOT performance from angular or the dynamic nature from JSP. And besides that, angular is moving to all AOT anyways.
My suggestion is the same as yours, write a RESTful service. It shouldn't take too long, because the requests/responses are already available. Just make sure to follow to correct REST guidelines.
Then create the angular app based on the templates from jsp. I suppose you can copy these one on one, and change the syntax from jsp to angular, and obtain the necessary data from the REST api and populate these in your template
I am creating a web application with a Java back end. I intend to house this on Amazon Web Services.
Ideally, in the future, I would like to create a Native Android application that carries the same functionality as the web app.
How can I implement my current application so that the Native App and Web App can both use the same back end database and services?
I have been reading about Service Orientated Architecture, is this the correct approach?
Service Orientated Architecture (SOA) is an approach that has been around for a while and could certainly meet your requirements. However I would caution you that you are going to run into lots of "Enterprise" designs as you search for information about SOA that will really be overkill for the type of development you are doing.
In general I would simply recommend that you focus on the following:
Keep your UI (HTML/JS/CSS) in a separate project from the Java back end. This practice will force you to keep the UI and back end concerns separate.
Have your back end expose an API that sends and receives JSON via HTTP/HTTPS.
Make your back end services stateless. Using JSON web tokens for authentication is a good way to accomplish this (I like using Auth0 for this). In other words don't rely on an HTTP session to track your users from within your Java code. This has the added benefit of making your application really easy to scale.
If you do these things then when it comes time to build the Android app you wont have to touch the back end at all. You will just have to implement the UI again in native Android.
Since you tagged this question with AWS I assume you plan to implement your back end on AWS. If so, I would highly recommend you look into using Amazon's API Gateway service. This service would sit between your UI layer and your back end. This provides several advantages such as rate limiting and caching to secure your API from DDOS attacks, an optional API key for added security, and API versioning to help you deploy new versions of your API without breaking existing clients. Also, by defining your API using the API Gateway service you can then generate an SDK for your API for use in JavaScript, Android and iOS.
Another big advantage of using API Gateway is that it allows you to break up your back end into separate servers, Lambda functions, etc. This allows for great flexibility, and I can't stress enough how the ability to use AWS Lambda in your back end will reduce administrative work as well as hosting costs. This enables you to start thinking about your back end in terms of Microservices.
The company I work for has a powerful Java based server component framework for interacting with special control systems.
We have a UI framework but this is also Java based. A customer can use a Java Applet to access control information etc.
I've recently started working on a rich JavaScript API to access this control system information remotely. It's currently a prototype. It's nice because anyone who's familiar with JavaScript can access our Components remotely. So far it works really well. I've written some prototype applications that use this API. This gave me an introduction to jQuery - great! I've also added the ability for the JavaScript API to make RPC calls to Java as well as a session based Component architecture for when you really need something held on the server.
So far so good. I have to admit though that I'm not really a 'web developer'. I've never used Structs, Spring or any of the MVC based architectures for serious Enterprise based web development (I AM very familiar with design patterns though). My background is application development.
I'd like to know from the pros whether this is the right approach or whether I'm missing anything. Someone I work with has created a really neat Server Side Include architecture. However, I'm wondering now whether this is really necessary? After, I think I can create just about anything using my JS API and jQuery. Should I consider any other 'server' based architectures in this new age of open web apps?
As far as browser support goes, I'm not concerned about the older generation of browsers (please no lectures here, the old technologies we've got will do for IE6 and alike).
By using this open client side technologies, I'll be able to write sophisticated open web apps. Very little server side code will be needed in reality because of my API. I'll be able to take advantage of HTML 5 features etc. But am I missing anything? Should I be considering other server side based Java technologies like Server Side Includes? Am I too client focused?
Well there are four ways to create modern RIAs: HTML5/Javascript, Java Applets, Flash/Flex and Silverlight. Only the first two are open.
Applets are a nuisance and not really liked by people. Personally I'd go with HTML/Javascript.
Since you are a Java shop I'd recommend going with GWT for the following reasons:
It's open source with business-friendly license.
It creates minimum-size browser-optimized javascript.
It's actively developed and used by Google. This is a guarantee that it'll be supported for some time.
There are a lot of developers with knowledge of it.
It has good documentation and very active user group.
I'm sure there are many opinions on this, but my take is that with HTML5, faster Javascript interpreters, client side persistent storage, etc. it makes it pretty compelling to put all the UI application login in the client (browser), and just use some form of RPC (with JSON serialization) to the server. Therefore templating engines, SSI, or any server side generated markup is no longer required for interactive applications. It's still fine for semi-static documents. For that I use sphinx document generator.
Fast-forward two years, and you now have TodoMVC at your disposal to help answer this question. GWT is still mentioned, though as far as server-side technologies go, The Holy Grail is probably what you're looking for to maximize code reuse on client and server.
We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.
However, we still have a number of short and long term goals:
Pick a technology stack for a new front-end
This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.
Stacks on my list are:
Eclipse RCP, Netbeans RCP
Flex/Flash, Silverlight, JavaFX
Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
Java-based Web frameworks (Wicket, JSF, ...)
Find a way of making the current application perform acceptably in a remote situation
We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.
To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.
As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.
If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.
Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.
Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.
We've just gone through a very similar evaluation process as we're migrating a legacy application.
For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.
In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.
As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.
If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)
Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.
The reasons I like this approach, you're already migrating code into Java middle tier, so
Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
Already have Java expertise, can be leveraged with DWR
Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)
I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.
I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.
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.