Websocket Implementation without Node.js running Ember?

Questions
1

Hello all!

I’ve been pouring over frameworks for the past week - research, test, run into a problem, find out it requires a billion dependencies and/or don’t fit the build structure we are needing…

As such, I’m hoping that I can get some clarification regarding the capabilities of this framework in this setting…

We have 3 parts to our environment:

  1. UI hosted (anywhere - not embedded)
  2. Node.JS Server as controller
  3. Java Server as the backend computational/database access point

We have our reasons for requiring the separation between UI and the Java Server and or UI and the database… please do not reply with “well you should just drop the Java” or “drop the Node.JS”… this is being built in the context of financial institutions and therefore requires a greater level of processing and separation.

What I did:

Created a ‘vanilla’ JS/jQuery UI which can request dialogs/data from Node.JS - which authenticates the user, requests the data, and then generates “on the fly” a new (div) window for the user.

The problem with this is rather obvious: while it works for now, any changes in either code can complicate things - and we’ll be hiring developers who need to “pick it up and run with it” once the infrastructure is complete.

As such, I’m looking for a way to do this:

User Requests Info → UI → send request over WebSockets → Node.JS takes request, authenticates, and replies with a dataset and name of the dialog to make → UI generates dialog with attached data, and passes it on to the user once completed.

As this is meant to be a SPA, and we’re avoiding routing as the idea is to load a new div in the same ‘index.html’, I had looked into Vue.js but ran into serious issues with the WebSocket implementations as the compiling required complicates data retrieval over WebSockets, and Socket.IO … while functional, is not enough of a ‘standard’ to be used in this way. The Java server is also using (pure) WebSockets, so we don’t want to have to do some “loop” when they could all “speak the same language”.

Ideally, we do not want Node.js compiling or spitting out any html or views within it - as in the future a mobile app or other entry point may be added, we need generic ‘envelopes’ to be sent across the wire, allowing the UI to handle their output.

I.e. :

envelope = [ header: “infoRequest”, body: { // array of info } ]

Based on the header, it will then pass off the body to the appropriate function for loading.

If this can be done within Ember.js using websockets as communication, without routes and Node to do the generation… please point me in the right direction!!

Thank you for your time, look forward to the feedback. :slight_smile:

2

Hi @Paracoder, hopefully I can clear up some of your questions.

What you’re describing isn’t remotely unusual, it’s probably one of the most common architectures.

Yup, there is lots of precedent for financial industry users of Ember, including some of the really big ones like JP Morgan Chase and State Farm.

I agree. Teams that are happy with Ember cite this as one of the major advantages. Strong conventions mean that people can come on and off of Ember projects and immediately know how things work, without messing around with a lot of custom tweaks that need to be rediscovered by every newcomer.

This is a bit of a non sequitur. SPAs do routing, the two are not mutually exclusive. A normal Ember app loads a single index.html once and then everything from that point onward happens on that single “page”, even as the user moves through the states of the app and perhaps sees the URL updating. Even if you think you don’t care about encoding state into the URL right now, if the requirements change it’s hard to retro-fit later onto an app that isn’t conventionally organized to support it (any Ember app is conventionally organized to support it).

Here I don’t really have anything encouraging to offer. I don’t know of any truly standardized solutions that are higher level than what you’d get from Socket.IO. I will say that there is a trustworthy Ember integration for websockets (including optional socket.io support) that will save a lot of custom fiddling with setup. It’s rated 10 of 10 on EmberObserver, meaning the community considers it well-supported and high-quality.

3

Thank you for your response!

Regarding the sockets specifically, it appears as though the ember integration is still using a Node environment.

Can ember either use the existing HTML5 sockets in the browser, or is there a client-side application for that within Ember?

Socket.io has been eliminated from our environment based on my superior’s disinterest in it.

The idea is that I need my Node.js environment to be simply sending and receiving ‘envelopes’ - not running a very specific router in Node that may have to be entirely copied/replaced if we decide to connect another kind of app to it externally.

I had a lot of this going through generators using JS/jQuery, but we’re trying to find a way of doing the same thing with templates that are generated - client side - rather than relying on languages likely to change on a whim.

Can you offer some advice regarding this approach?

I only want the server to send an envelope - not be handling routing and such… if states can be used client-side and it shows it in the URL, no problem… but relying on a server which is simply a controller to also do generation isn’t what we’re trying to go for.

Thank you again!

4

If I understand your mention of “envelope driving the content” correctly, you may be interested in exploring the metaprogramming capabilities of Ember.

5

I think you may be mixing up two different things.

Ember is (for purposes of this discussion) 100% in-the-browser. It doesn’t really make sense to say that Ember’s websocket integration “is in Node”. Ember is necessarily agnostic to what server-side technology is speaking on the other end of that websocket.

That is what I’m saying. The Ember addon I linked earlier uses native websockets in the browser.