I want to generate webApp in java and just use some REST service. I think there are two approach for this:
1- Client side consumer: With an simple app that contain some java script file which call service and then generate UI from result.
2- Server side consumer: In backend first call service(with spring RestTemplate) then generate appropriate UI and send HTML ui to client.
Which approach is recommended?
I know this question is very general but I want to know advantage and disadvantage of those.
Client side consumer approach is the better one as tomorrow if you have one more client application who requires the same data but will be displaying it in a different way then client side consumer approach will benefit you. For eg: suppose the consumer today is a web page then you can get the data from backend and display it on your webpage, but tomorrow if your business grows and you plan for a mobile app then in that case your same rest api will come in handy for you.
Related
I have a web application with a client that receives data from a server. I have the data in NodeJS, but I want to pass the data to a Javascript file. The Javascript file is included in a HTML file, so I can't make the files communicate with eachother.
I am new to NodeJS, so it can be a stupid question, but anyones help is appreciated
This is for a project where I need have a data stream, and I need to pass it into a web application. I tried to pass the data to different page inside my application and then I tried to get that data on that page inside my web application via Javascript, but I couldn't make that work. I'm not even sure if its possible at this point.
Your node server can't communicate with your front-end without a specific way of communication like websocket, you have many other way to communicate with your front-end as node-server, take a look at server send event for example.
By the way your front-end can call your node server more easely with a get request as said #tomerpacific in comment.
For that you have to open a route with your express app. Routing with express
And for call it on a GET request, for that you can use the XMLHttpRequest, and if you have implemented jQuery on your front, you can use Ajax jQuery.
I have a client web application. The user clicks buttons, gives inputs, makes selections, etc... This is all done with Java using the Spring framework.
The client talks to another service that I have built in Java (with Vertx). This service talks to the database, handles caching, and the endpoints return values.
user navigates to web page--->client controller handles request mapping--->
--->request mapping uses controller method to return view--->
--->view's JS makes requests to service--->service returns model data
Now, I like the idea of control that Spring controllers offer. My client's pages use the Spring controllers to return views, and a small amount of model data.
However, what I am doing to call my service is: in my view's JS, I am making AJAX calls directly to the service. I mean, it works, and that is what was suggested for me to do, but I'm not sure if that is what I should be doing.
The alternative would be for my client to make JS calls to the client app's controller, and let the controller from my client app make requests to and receive responses from my service, then pass those responses back to my JS. I feel like this is probably the "cleaner" or "better" way to do this, but I am only about a year into programming with Java and don't know what the best way of doing this is. Essentially,
user navigates to web page--->client controller handles request mapping--->
--->request mapping uses controller method to return view--->client view's
JS makes requests to client controller--->client controller makes request
to service--->service returns data to client controller--->
client controller handles data and returns data to client view's JS
My gripes are that the JS exposes more than I would like it to in terms of the service's endpoints. Furthermore, I feel like using my client's controller to call the endpoints just seems... right.
I'd prefer input of experienced developers on what is right and/or wrong about these design patterns.
I've seen it successfully implemented both ways. Using a client controller is a fairly easy way of narrowing the exposed surface of the API (provided you lock-down access to the back-end services, otherwise you're just wasting your time). This method also allows you to turn the Client Controller into an adaptor to adapt the return values from the API into something more UI-centric (e.g. map codified values into text via an i18n file) and pare down any surplus data before it goes to the client.
However, there's an element of extra work or duplication as well as a performance overhead (hops, marshalling and unmarshalling).
If you ever suspect you're going to expose the underlying API or the client's usage of it is going to grow to the point where you've effectively created a shadow copy of your API, you should just put in place a robust Auth and Auth system to only allow calls from the appropriate places. This is not a trivial task, but would allow you to expose the API to other consumers.
The current and expected future usage of your API (but don't go all YAGNI on this!) should shape your decision. It may be appropriate to have the Client Controller layer doing filtering and shaping to avoid excessive client payload or not if you want the client to have a more transparent representation of your resources.
The main interface app will return variables based on those initially POSTED by the client, and subsequent database calculations performed in real time by a dedicated engine.
In Sails can we plug the engine into a Controller used for returning the calculated variable?
What would be the best way to implement a real time link between the client and the engine ?
Sails comes with sockets support built in. You can transmit the data out of your controller back to the client via sockets to keep everything in sync.
Reference this page for sockets in sails:
https://gist.github.com/mikermcneil/6598661
As an aside, you could do everything using sockets, including the posting.
What is this 'dedicated engine'? Is this a separate service running somewhere else, or is it just logic for processing this data and handing it back to the controller?
If you want to put the data processing logic in the same app you can create a service which exports whatever data processing functions you need. Then in your controller that is handling the POST requests you can call on those services as needed, process the data, and emit it back to the client. All your sockets logic can go in that same controller since it is for communicating with the client interface. I would consider just moving all of it to sockets. If you look at the sails docs you will see that it has a similar interface with sockets where you can do standard CRUD operations: sockets.PUT, etc.
Sails.js WebSockets
No framework other than Sails, unless necessary for security purpose
Minimalist architecture implemented in Sails
1 POST API
1 POST Model
1 POST Controller
1 Socket per processing method
1 Socket switch within the Controller
Now if a secured framework integrates socket switching within controllers, that would come useful.
We may add middleware to the POST Model for the purpose of filtering text input data...
Hi all,
My question was how to create a web chat plugin to be supportive on my companies web site.
1- which protocal is most suitable for this application ??
2-about the coding all client site.
3- about the coding at server side.
4- how the transmission of data takes place from client to server and vice versa.
The easiest approach (not taking into account using all ready existing plugins) would be to use Ajax and a database. This means that the protocol will be HTTP/HTTPS if you want to implement it into your company's website.
The client and server side depends on how you want the chat to function. Try building something similar to IRC with one room for example.
create a database table which will hold the chat
on the client side implement a method which will send a message with Ajax and also recieve all messages posted
for the server side all you need is something which will store the new message and provide them when requested from the client
As I said, this is just a quick example, if you want a more complex chat system you will have to do a bit of research.
I have a web site showing some data. It is constructed of:
- A web app, showing data.(ASP.Net app, but I don't use server side features in showing data; It's pure HTML and JavaScript)
- A Service providing data in Json format.(WCF)
the client requests data and receives and shows them.
Now I want to change the process in order to works in push base strategy.
I googled and I found out that that Comet is a good choice, but I don't found practical samples in my case.
Some samples had client with php (server-side) and so on.
Now I want some hints on using comet in a way that client is pure JavaScript and HTML and server is WCF (server pushes Json to JavaScript )
look at nComet it is an asp.net implementation of comet, not sure if it is wcf yet, but i would have thought much of the code would be reusable.
Or better pokein