I use Node.Js along with Express and Express HBS (Handlebars). And for users real time synchronization I use Socket.IO.
Let's say I code a web chat and each time someone hit the send message button I emit an event from client to the server. Next, the server will receive this event and emit a new event to all the others client, updating everyone one with the last message send by our first user.
Since we all want to be messy for the less and organize as possible, I would like to have a template file containing my new message skeleton. But after that I don't understand what I've to do. My first thought was render this template either :
from the client with data send by Socket.IO.
or from the server and send back the html rendered to the client through Socket.IO.
But it seems that's not recommendable ways, as far as I am in my research.
What I would like to avoid is :
HTML Skeleton inline in the client JS code receiving the new message from Socket.IO.
that everyone ask to the server (ajax request for example) the same message just after receiving the info from Socket.IO that it is one available. What if I had 10,000 users sending and receiving message ?
that we put the block of code in a <script></script>, get it inside the js and put it at the right place in the DOM when I need it. Best approach I found for the moment, but what if I need a lot of this sort of thing ? I don't like the idea that I could have a lot of blocks code at the end of my DOM just in case I could grab it and use it, maybe or maybe not.
Reload the entire page each time a message is send.
Actually, my current project is not a chat but I use this as an example. Keep in mind that the block of code I want to add to the DOM on events could be more heavy than just a chat message.
What is your thoughts about all of this ?
What you can do is send the template earlier on as a string, compile it and store as template (in some Map). Then when a new message comes in, you just need to pass in the data to get the html content where you can then set as innerHtml to some div at your desired location.
If you need my thoughts i will say the stack may be an issue. You want to realise a reactive feeling in your application but at the expense of your api, as it continously compile those templates to send to your various clients as html.
Another bad effect to consider is those html tend to be heavy when sending to the various clients, whereares sending just the data that changed is quite light weight.
Best approach will be use a client framework that is best suited for such reactivity you need. A library/framework like React will permit you manage the events, and show new data using components available on the client. You will only need to send data concerning the event like the sender info and content.
Check out this page on handlebars website specify best suits for handlebars. https://handlebarsjs.com/installation/when-to-use-handlebars.html
Related
I creating a Web App that using Nuxt.js, with Server-Side Rendering.
I don't want expose my backend data, so I tried to use asyncData and Axios to request to my backend server.
But the Nuxt.js exposed my backend data to client with window.__NUXT__.data variable.
I tried remove this by using render:route hook, But It says
[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside p, or missing . Bailing hydration and performing full client-side render.
So I tried remove the script that making not matching error, But It makes stop working script at my site.
So the question: How to disable the client hydration(client-side virtual DOM tree rendering)? or How to stop exposing raw data?
I used asyncData with this code:
asyncData ({ params, error }: { params: { id: string }, error: Function }) {
return axios.post('(backend)', data).then(res => res.data ? ({ data: res.data }) : error({ statusCode: 400, message: 'Bad request' }));
}
You cannot stop the hydration of your SSR'ed content (not yet at least, it is planned to server only static content pretty soon tho).
Nuxt is aimed to add SSR to your day to day VueJS SPA. If you don't want the hydration, you're probably using the wrong framework here anyway.
Astro may be a better fit, to name just one. You could find more here too.
The DOM mismatch issue is explained here (reasons + solution).
How to hide things on the client side?
Short answer: you can't.
Long answer available here.
If you want to display something on a page, you'll need data.
Nowadays we're using SPAs to have a local state in the browser. Since it's local and under your eyes, the state is living in your browser, so you can't really hide it and also, why would you do that?
If you want to hide the data, maybe don't send it initially or send an image at least.
You could also make some obfuscation, but this will just be a band-aid and not really good on semantics/performance/etc...
If you have some sensitive data that you want to show only to admins or so, you could use some auth and rights checking. More details above, in the long answer.
If you really really want to hide data on plain sight, that is, you want to send data on client-side without exposing it, then you do not have a full solution for that as it is, but there are ways to achieve what you need, choose your preference based on your intent.
Not sending data to the client if you do not want to expose it
Yes, I know you have asked for the diametrically opposite, but, before you read the really, really unconventional and often difficult approaches, first, let's ponder on whether you really need this indeed. The alternative would be to just not send this data to the client at all, but rather work with this sensitive data on the server. It is the scenario you will need 99.9999% of the cases of web-development. (the number is my subjective estimation, not the result of a representative statistical research)
Email, chat, SMS, paper mail, smoke signals, morse messages
You may need to send that information for the client, but this does not automatically mean that you will need to send it to the client-side of your website. You could send the information using some other channel, just make sure that it's trusted and reliable. For this reason I don't really recommend the use of smoke signals.
iframe
Now to the technicalities. Modern browsers protect against the scenario when you have webpage1 opening webpage2 in an iframe if they happen to have a different domain. So, you can create a domain that's different from the one your main page uses and show whatever you want to the client by calling a page of your brand new second domain (via HTTPS, of course), using minimized Javascript and closures. If you need communication between your iframe and your main page, then you can use messaging between the two, see Communication between tabs or windows.
A possible objection may be that one can still see the network tab of his/her browser where the actual received data is being shown as well as the possibility to debug Javascript. Well, bad luck. We cannot send the data to the client without sending it to the client. If this caveat is too much of a risk, then read on.
Encode the content you want to avoid from exposure
Yup, it will create a lot of difficulties and sometimes you will wish you never did it, but you can encode your top secret data and even if the user has access to it, he/she will have no idea what it is. But in this case you will need to face the problem of encrypting/decrypting your data whenever you use it.
You can use visual representation of your data
Like an image, an svg or some other kind of generated captcha-like content, but don't send it a file, because a third-party watcher may just download it. If you generate that inside an iframe, then your data is difficult to mine. Oh, wait, but what if the hacker looks at your screen from behind your chair?
Write your own browser (extension?)
You can implement a browser or a combination of browser extensions that will handle this and use HTTPS. But what if the spy has a lucky day and deciphers it? What if you have a virus?
Bottom-line
By the sheer fact that you are sending data to the client-side you will have to accept some risks. There is no way around it. You can reduce those risks, but it's always safer not sending the data than sending it.
I have an html page that has a form and is communicating to a server via JSON requests, when loading (e.g. in order to remember user's previous answers) and when submit button is pressed (e.g. in order to save his new answers). Every user has a specific user_id that is located as an attribute in the url of the website. I have only HTML pages, CSS and Javascript that makes some simple functions, as well as received and sends the requests.
The problem is that the server needs an api-key for the request to happen, that I need to be kept hidden, but instead is easily discovered when the user sees the source code. I want this specific line to be hidden, but I guess this is not possible without any backend in the game.
I would like to know the easiest and fastest way to get from this state (just frontend, where every piece of information in the source code is totally insecure) to another where the api-key (at least) is not on the open.
I guess the solution is to use a server for that part but I need suggestion on the easiest transition from my code to another. I tried to use GWT, as I am a bit more familiar with JAVA backend application (but not with GWT), but seems like a big trouble, where I need to change my HTML, my Javascript and also the CSS that I have may not be useful, as well as I face a lot of problems when trying to read my parameters.
I know that it is not the best way but I do not have a lot of time to make it work, so sorry if it seems lazy (I am new to this type of programming), but I haven't found anything helpful and I cannot study for 2 weeks in order to be able to begin implementing it.
Is node.js (which is Javascript and I already have implemented the request sending/receiving in this language) easier than GWT for that matter? Will my sensitive data be secure in that way? I would be grateful if there was a similar sample, that I could start using for my implementation, as I haven't find anything that is specifically helpful for my situation.
Thanks in advance!
NodeJs is not javascript, NodeJs is specific javascript "interpreter" whose is purpose is mainly to be executed server-side. If you have an HTML page, it is likely to be loaded in a web browser (client-side), so not in a NodeJs environnement.
Everything that is hard-coded in the javascript of you web page is visible from the client, there is no way around that. So yes, you need some server-ish thing somewhere.
If you are not to manage a server by yourself or via PaaS, you can go for a serverless architecture. For instance, If you consider AWS which I know the most, you can easilly add some user management to your web page using Aws Cognito User Pool. Once a user is connected and have the good permission, he can be granted access to some other resources via a JWT token that you send along with your request.
I am a frontend guy, but I am working on a project in which I need to process lots of data in my nodeJS backend (my front is reactJS).
But once the data that needed to be processed in the backend is processed, I have the choice of either reprocessing this data in node or in react (knowing that in the end, I need this data in frontend).
Example: An array of links has been created in my backend, but I need to extract a single link from this array, in order to display it in React. I have the choice, pass the array to react and process the data there, or do it directly in node.
Is there a common fashion to fix this dilemma? What should I take into account to make a decision?
It's not good to send excessive information from your backend to your frontend. If you're going to send data to your frontend from your back-end and a lot of it isn't going to be used, then it's probably best to adjust your backend so that it only returns information that's going to be actually used by your frontend.
Alternatively, if your frontend isn't going to use all the the information sent by your backend right away, but potentially might use it later (based on user input), then it's better to send all the data from your backend and process it on the front end as needed to avoid making future requests to your backend.
Taking an array of links as an example:
If the user requests to see a link based on certain criteria, and that's the only link that they are going to see (based on the design of your application), then your backend should process that request and return only the link that your user wants to see to be displayed on the front end.
If the user can request to see a link, but could potentially request to see another link later, then your backend should send a full array of links that might need to be displayed at some point. Then your frontend can display the links at the appropriate time without having to make a request to your backend each time the user wants to see a new link.
In my opinion, if the logic doesn’t need to be done by the browser, then do it on the server. It will help you with reducing the size of your app in the long run. You want your final, bundled .js file to be as small as possible. That’s just one small step you can take to contribute to that.
The short answer is that it all depends on your business logic. Regarding how best to handle an array of items to be sent from backend to front-end, if a user will only ever need to see this one item, for example, then by all means, have the backend parse the array of data on its end and send that single item to the client front-end. If, on the other hand, you anticipate that you'll need to work with an array of items to be presented to the user at some point in the app, it would be reasonable to simply have the backend send the array of items. Furthermore, that array of items could be, for instance, a filtered version of the items that would be relevant to this particular user.
My goal is to create a real-time chat similar to the Facebook chat, from scratch. I want to store all the messages on a database table (MySQL) and every time a new message is sent by a user, if the receiver is connected then a request will be sent to the receiver's browser and the message will appear on the chat window.
I don't want to have the client to check if a new message for the user was sent, but I want the server to send the request to the client's browser.
I know that this can be achieved using the Comet technique (I saw this stackoverflow question) but I am not able to find a good guide on how to implement this for this certain problem.
I want to use php and javascript and as less extra software or frameworks as possible.
I use WAMPServer and I have Windows.
If you know a good guide or tutorial or can provide any guidelines on how I could achieve what I want, it would be very helpful.
Try use for this CppComet open source comet server. There have api for php and other languages.
And viwe this chat example or this
You can also use Node.JS with PHP. Creating a Real-Time Chat App with PHP and Node.js
I have already developed an application which is not completely Real-time messaging system, but it works like realtime. Built using without any external new frameworks/API, just used known and familiar skills to develop this using: Ajax jquery, PHP, Mysql, Javascript.
Logic used is:
All messages will be stored in database,
When you load page all messages will be loaded from database.
When you get new messages after reloading, the new messages has to be
loaded/displayed without reloading whole page again right? This is done
using javaScript and ajax jquery. I have set time out for EVERY 0.5 seconds
to reload only new messages and display them.
In my code, At first when the page loads all messages will be loaded in div
tags each, Later whenever new message gets into db it will displayed into new
div tags. its Simple and works without any external API.
To refresh new messages and throw them in to div tags .load() from ajax jquery is used,
to refresh every 0.5secs Javascript is used to set timeout.
I don't know what your exact question is but Websockets is the answer!
https://github.com/crossbario/autobahn-js
https://github.com/voryx/Thruway
(FYI, when you see WAMP in the context of websockets they're talking about something that's not windows/apache/mysql/php)
Unfortunately you can't make a real time application with PHP it self you can use a framework like Laravel in PHP and use packages like laravel-websockets and create a realtime application. laravel-websockets is really useful for creating a realtime application. laravel and the laravel websokcets with any front end you can do this
http://beyondco.de/docs/laravel-websockets
https://laravel.com/docs/
You can easy create anything with it just try to understand the fundamental concept of websokcets .
Web development being completely new to me, this may be easy to find online but I might lack the technical jargon in this area...
I need to display some data on a linux-device that also runs a webserver, so I figured the easiest way would probably be to do this in a browser. The data might change due to (physical) interaction with the device: it has external push-buttons attached. I need the data on the webpage to change instantly when a button is pressed, so that the user sees the values change immediately when he presses a button.
This might be complete and utter nonsense, but is it possible to have the program that watches for button-presses pipe its output somewhere and have a piece of php respond to this?
A sub-optimal solution would be to have a piece of client-side javascript with a timer that periodically "calls" (?) a piece of php. I don't like this solution because you either reload ad nauseam to minimize delays, or you'll notice lag in the response to the button-presses.
You can use socket programming. Usually used in chat servers to send data to client without refreshing.
http://php.net/manual/en/sockets.examples.php
This should help
In this question the p asker tries to do the same u are trying, push data on some external event
Python Socket Programming - need to do something while listening for connections