NodeJS with Java RESTful backend? - javascript

I require some advice in terms of choice of language, I hope that I'm allowed to ask this question here.
To provide some framework information:
As from next week, I'll be following a Java course to get my graduate degree in programming.
For this graduate, they mention that we'll need to develop a webapp in Java.
At the same time, coincidence wants that we are currently developing a webapp that allows users to search popular activities (events) and follow hashtags to render a specific activity feed.
For the front end we currently use some client libraries (Marionette, Backbone, Underscore, Requirejs).
For the server front end (router, rendering server pages), we currently use nodejs.
The question is if it would be a good choice to use Java to build the REST service (to serve both the server and client front ends). The webapp includes a social network, organisers can create their own profile, users can bookmark all sorts of things, ... well, there will be pretty database intensive actions (we'll be using a relatively complex relational model with MySQL).
We might still be using Node to handle push notifications with web sockets but we haven't really discussed this yet.
Since we'll get time at school to work on our project in group, I'd have plenty of time to build the backend REST api with Java which seems like a huge opportunity for me in terms of time. I'm just wondering if there would be any real tradeoffs to do it with Java for this purpose.
Thanks.

I think this would be a huge opportunity to build a REST backend in Java.
Take a look at Spring for a fast and effective way to server HTML
Also you could look at Spring Boot for serving REST APIs. If you follow the tutorials you'll be up an running in minutes.
Good luck

Related

How to implement a Node.js chat app into an existing website?

I've been getting into Node.js recently and I really like the example shown on Socket.io's website showing a real time chat application. However, in all of the examples I see the URL used is localhost:8080 or whatever ip and port is applicable. However, is there any way to implement this into an existing webpage so that it isn't a separate URL? If not, how are these real-time chat apps done in real life?
these sort of questions are usually not meant for stackoverflow, but everyone has been where you are! Stackoverflow is dedicated for code related questions, but this might help you get to your next steps:
NodeJS is a backend server language, you will have to deploy it to a production environment.
New developers typically learn by using services like heroku.com to quickly host backend apps, they take a lot of the complexity of learning Linux or Microrost Server out of the mix, but they are not typically used by more advanced developers.
More advanced (real world apps) run on AWS/Azure/Other hosts.
Implementing it in an existing website requires both frontend and backend languages. Nodejs gives you a leg up in that it's javascript, and can run in both frontend and backend situations.
There are many places online that provide tutorials for creating backend servers and frontend websites.
the list is endless, but some good places for new developers are
https://frontendmasters.com/
https://teamtreehouse.com/
https://egghead.io/
Here is a tutorial on heroku for setting up a nodejs app
Getting Started on Heroku with Node.js

I need advice in how to aproach setting up a webserver

For a school group project we're asked to make a sort of scheduling application, we are free to set it up any way we want but i dont have any experience in web developing.
For the backend we've decided on java for the logic and a mongodb database but i'm exploring options for frontend development so far javascript has peeked my interest but i need some directions for what to look into
I was wondering if i could make a connection between javascript (if there are no more intresting options) and the java program running on my (virtual) machine and if i could host a webserver myself or need to look for a hosting service
Lessons on this topic start following next week but i want to make a head start and have a n idea were to look into
Thanks very much in advance!

Vue.js: Backend realization

So, I have been learning Vue.js as my first js framework for some time and after I made some simple SPA:s without much interactions with a server I started to wonder: What should a backend be like with Vue? For education purposes I gave it a try and came up with some pattern on my own and now I can't imagine anything else, maybe I got some wrong idea.
What I came up with: I made a simple API with PHP which was receiving requests from the frontend (Vue component methods reacting on UI events) and requesting data from the model or updating data through it.
There are a lot of different Backend Solutions and you should take what fits your websites purpose and also personal preference the best.
If Backend includes Hosting in your case then you basicly have the 2 big options:
a) A Server where you run it ex. via an Reverse Proxy (example: Digital Ocean)
b) A cloud computing Platform (example: AWS, Heroku, App Engine)
But you only need to host it that way if you actually run the app and retrieve dynamic updates on the page, new routes get added when you for example publish a new Post.
If that is not the case then a static hosting provider would be enough, there are 1000´s of them and they are pretty uncomplicated.
If you mean which Database to use, then it also comes down to preference, do you want a SQL Databse or a NoSQL Database like MongoDB? As a personal recommendation I would suggest you to use Firebase as your backend for your experimental app, the free plan is far than enough for testing purposes, you also have a smooth and easy to integrate Authentication System avaliable and you can also take quick advantage of things like Push Messages, Cloud Storage Buckets and more.
Note that Im not related to FB by any means and this is just a personal recommendation, but I feel like your Question is pretty opinion based so maybe be more specific about your goals or just comment down below if you got any more questions.

Implementing a RESTful API based Web App. Do I need a server-side framework?

I'm starting a project that basically is a single-page app that downloads and shows a bunch of stats (using d3.js). The data layer is Mongo-powered, served through a RESTful API, and the client app will be coded in Ember.js. We want all data to be exchanged through the API, since we also have some mobile apps in the back burner that will hook to the same API.
I'm debating on whether write the API (using Express.js or other server-side MVC framework), or just serve the API use Deployd and not using a server-side framework at all, besides Deployd. I'll provide some hints about the project characteristics:
The main feature is basically a dashboard that shows aggregated stats that are already computed and stored in the Mongo database.
User interaction is minimal, enough only to allow users to customize their dashboards, but users never upload data (other that customization preferences).
Most of the app is a lot of d3.js to create and render a bunch of graphs, which can customized in many ways.
It requires a very rich and responsive user interface.
I proposed skipping completely the server-side framework, and simply go with a bunch of static HTML+CSS and do all the heavy lifting with a client-side MVC such as Ember.js. Since all data download and upload can be handled by Deployd, a pure static site would load much faster and is also easier to scale. Also, (I think) all user-related data and validation can be done with Deployd itself.
The thing is, some of my colleagues had a heart-stroke when I mentioned this idea. So I'd like a reality check: do I really need a server-side framework besides Deployd to cope with problems I cannot foresee yet? Are the benefits of having a pure static site a good enough tradeoff versus having, say, Express.js just in case?
I haven't worked with Deployd before, but from a quick skim of its docs, it is a server-side framework. It accepts requests and respond with json. It's just oriented to APIs and json and neglects html, unlike, say, default Ruby on Rails.
The main issues I can think of that might arise due to a lack of a traditional server-side framework are things like auth, CORS, and XSS/CSRF/other common security issues. You could cater for this through Deployd if it's built in or easily added, but that may be difficult.
Looking further into Deployd's docs, I see there's a guide for users and CORS. I can't find anything about XSS or CSRF.

Writing Real-Time apps with NodeJS

im looking forward to build RT web apps with NodeJS. Coming from Rails, I've felt in love with NodeJS and Async JS programming.
Run a few experiments with Node, and then as I search tools and resources to get used with, I got overwhelmed with the lot of stuff over there.
I found lot's of libraries and components over there, and pretty much got confused on how a large-scale well-writen and implemented RT web app should be built.
So the app will run over NodeJS, using Express framework.
I read about knockout.js, a client-side library to provide realtime stuff like automatic UI refresh, and I guess I could conbine it with jQuery.
Also, I found socket.io.
The author says:
Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. It's care-free realtime 100% in JavaScript.
So socket.io is about compatibility.
What about backbone.js? Where does it goes to?
With so much stuff, I got shocked. What should I learn? Which modules worth studing?
Im focusing on NodeJS and Express but most books/screencasts covers old versions of nodejs. So im being guided by its official API.
Now im here asking your advice and to organize somehow all the info out there.
Correct me if my assumptions are not precise, please point me to the right direction and feel free to suggest any other module that could help on my learning.
Thanks in advance
It might be useful for you to separate the node.js server side libraries (via npm etc...) from all of the client side (browser) libraries and technologies like jquery, backbone, knockout etc... when you think about it. Even socket.io which exposes a persistent socket connection between the browser and the server (to avoid polling) does not dictate what client side technologies you use.
Focus on exposing a solid web-api ( random example ) from your server and your client technologies can be swapped, augmented etc... with no effect on the server. The only place they intersect is if you're using a view technology like Jade. It's also an option to have a pure separation where the server is just serving up the client files and your client is a thicker javascript application (using knockout, jquery etc...) calling a good server web api.
Some folks try to unify the client and server models - for example, this article using backbone and node. It depends on how much data you work with to say whether that's feasible but it does couple the client and server and makes the server stateful which can have downsides (scale out, requires affinity etc...). Personally, I get wary of that much magic (binding, state, syncing etc...). Node is about keeping things simple, light and fast. It's a fast front end network server.
My 2 cents (and some may disagree). Start with node on the server and pick your storage (mongoDb etc...). Design a solid RESTful (hypermedia) API - a good webapi regardless of the client. Then start with a basic html/css/js, maybe jquery client and add things like knockout etc... as you expand your client skills. That will allow you to replace your client technologies independent of your server as the new technology winds change (and they will).
That's the hallmark of a well designed system - the ability to replace componets/sub-systems without rewriting everything :)
Hope that helps clear up some of the fog :)
You may want to look at Meteor if you are focussing on real-time Javascript apps: http://meteor.com/

Categories