JS Local Network Communication [closed] - javascript

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
This question is more about looking for an idea, rather than an implementation or technical solution. I'd like to hear how you would solve this kind of problem (or task).
I have an application build with Javascript using React & Meteor. At the moment every time a client does something there is a Meteor Call to our server which will write Data to MongoDB and every other client will notice this change (and will respond in some way). This is working fine atm.
Now i want to add a new feature which allows two clients to communicate with each other (LAN only - atleast in the first version). So as an example: I have a room with 4 clients - A, B, C and D and i want to match two of them, e.g. A & C. This connection should only exists between those two clients and i want to minimize traffic to my server and meteor calls. (My server should not be involved in this communication at all, besides maybe saving some data every few minutes, but all in all it should work without my server) and it should be possible to open up more than one communication, if A & C are working together B & D should be able to do the same, the data which is transmitted - at this time - is JSON.
Further thoughts: A presses a Button in my webapplication which is a React Component. The React Component than establishes a connection to another person who is also looking for a partner (in the case above C) - Some sort of document/page opens up and both can work on the same document in real time or near real time. In worst case: The communication should be able to work without a connection to my Server (or Internet connection in general), but it doesn't have to.
I first thought about using sockets (SocketIO or something along that line), e.g. A creates a server when he wants to work with C and C connects to A, but this comes with some problems in JS
and i am not sure if its really a good way to approach this.
I'd like to hear some other ideas, perhaps im running in a completely wrong direction.

Use the WebRTC API.
Although often associated with real time audio/video communication, it can also be used for peer-to-peer communication with arbitrary data.
As far as I know this is, as of this writing, the only client-side web-native peer-to-peer API available which is widely implemented by major browser vendors.

Related

How to implement dual display in a Django app [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am developing a Django application for a school project and it is essentially one page that takes user input and another page that responds to the user input by displaying various alerts/data.
The end goal is to have the application launch on a tablet and display the user input page while having the summary data page displayed on the monitor. The issue is that as of now, these two are communicating via localStorage values. Obviously this will need to be changed down the line.
I am extremely new to Django and web dev so I was wondering if this is even a feasible task and what the right approach would be?
In short, yes this is something Django can do.
Fundamentally right now your application is just a client. You need a server to both:
A) use a database to store your data (whatever you currently store in local storage), and
B) share that data with your two clients
Django is a web framework designed to create such servers, so it's a great option. However, Django also requires knowing Python. If you don't know Python, and aren't learning it in a class, you may instead find it easier to use a different tool: Node.js
Node lets you use Javascript the same as other languages (eg. Python). It also has frameworks (eg. instead of Django it has Express.js). But again, if you don't mind Python, Django is a great choice.
Whatever your choice of framework, your first step will be to understand how it sets up "routes" or "endpoints" to talk to your client (you'll also have to learn how to have that client "talk" using fetch or $.ajax).
Once you master that, you can then learn to use a database to store the information you need, and finally you just "connect the dots" between those routes and your database to create your server.
I should warn you though that this is a sizable project, involving several complex technologies (servers, databases, AJAX, etc.) I actually teach a college class on server-side development, so please understand I speak from experience when I say that ... even to make a simple server with a little bit of data ... you'll have to learn a lot (with Django or any other tool).

Should I use two seperate projects for frontend/backend in addition with API or merge them to one? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a few questions which I'd appreciate to have some answers on.
So I've created a backend node server with express & mongo which is running specific tasks on the net and saves it in the database in a loop. I've also added an admin page with express & bootstrap. And that works fine. What I needed then was a frontend page - for this I chose VueJS. I started that project seperate for multiple reasons. I felt that this would be easier to get started, since I didn't have any frontend framework experience before and the backend project was written in typescript and I'd rather use normal es6 JS for now.
Right now - the site has already made some pretty decent progress and is at the point where I need to establish connection with the database and also use some of the already implemented functions in the backend project.
And this created the question:
Should I create new functions and/or create and use API's? Would there be any problem with the mongodb in the form of accessing and writing to it by two different processes? Would there be security issues if I'd create "public" apis from my already existing backend logic? (Haven't written any apis yet.)
Or should I use the time and import the frontend project into the backend (meaning also either translating new to typescript or switching to normal ES6 JS)? Would this be a security risk since I'd rather not have the backend logic in my frontend site.
I appreciate any answer to that!
Thank you :)
This is a question of can you afford to run two servers? separating your front end from your back end is actually a good move considering all things microservices since it allows you to scale these things separately for future purposes. Like your backend needing more resources once you start catering to mobile user as well or once you get more api calls, while your front end server need only serve the ui and assets, nothing more. Though the clear downside is the increase in costs since you do need to run two servers instead of one, something that is difficult when you are just starting out
Should I create new functions and/or create and use API's?
For your backend? Yes. APIs are the way to do things now in the webspace as it future proofs you and allows a more controlled and uniform way to access your backend(everything goes through the api). So if your front end isnt accessing your database through the APIs yet, i suggest you refactor them to do so.
For your concerns about mongo, im pretty sure mongo already has features in place to avoid deadlocks.
As for security of your API, I suggest checking out JWT.
should I use the time and import the frontend project into the backend
should you go this path instead due to cost concerns, i would suggest rewriting one of the codebase to comply with the other for uniformity's sake, though do that at your leisure(we can't have you wasting all your precious time rewriting code that already works just fine). this isnt really that much of a security issue since backend code isnt being sent to the front end for all your users to see
Let me start by saying I've never used Vue. However, whenever I use react, I always make separate projects for the front end and the back end. I find it's 'cleaner' to keep the two separate.
I see no reason for you to transcribe your entire project from typescript. Simply have your frontend make requests to your backend.
If you're looking to brush up on your web security, I recommend you look into the Open Web Application Security Project.

Performance, Scalability, and Security of Using Java via Javascript (JSON) [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Although currently still in the planning stages of implementation for our company website, we are considering different methods and technologies that successful at addressing scalability, performance, and security (as in people can't steal or easily reverse engineer our financial algorithms) concerns.
According to several posts here on stack overflow, it appears that since we have already completed a good deal of algorithms via Java for our desktop applications, accessing these algorithms via Java Servlets and JSON requests (as can be seen here and here) online might be a good choice, as it would save considerable time and money by not having to rewrite them in a different language.
Before moving forward however, I would like to know if the time and money saved by this approach would be worth it in the long run, and specifically, is accessing (java methods and array data) via JSON and Javascript both secure and scalable, compared to say rewriting all of them in straight javascript? Also, is support for applets and servlets ubiquitous, or is it possible that a good chunk of our user base would not be able to have access our website without having to download additional plugins?
In the ideal situation (minimizing learning new technologies), I would like to use technologies involving HTML5 canvass and JavaScript for all of the graphical stuff, but also be able to access small data via java algorithms (which will return an array with less than 100 indexes), however eventually on a large scale in terms of number of simultaneous users (no logins).
Is this a good option in terms of speed, compatibility, and security, or is there perhaps something that we overlooked?
Sounds like you're describing a fairly common architecture of web apps.
The client side is in HTML/CSS/JS and is responsible for presentation and UI related logic and the backend does the heavy lifting. The communication between the two is done via HTTP requests, probably asynchronous (AJAX) to REST endpoints your server provides.
This is a proven method in terms speed,compatibility and security. Pretty much every website out there uses something like this.
To get started you'll need a REST server running, I recommend using Dropwizard which allows you to setup a RESTful server fairly quickly and easy. Although if you have special scalability requirements you might want to look at other frameworks.
Here's an example of how an REST endpoint looks like in Dropwizard.
#GET
#Timed
public Saying sayHello(#QueryParam("name") Optional<String> name) {
return new Saying("Hello " + Name);
}
The name variable is being sent from the client side (JS/AJAX) and then you have a standard Java function where you can do whatever you want. Finally you return some kind of result (Saying) and parse the result on your client side.

What are the security trends for client side coding in web development [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
There are a lots of new frameworks, technologies coming up. And it's becoming so hard to follow up all of them. One of the thing that confuses me is client side frameworks. I heard that Angularjs,Backbone,Knockout,jsviews,knockback, SPA... are the most popular right now.But I can't understand how does the security concept applies? If we take an example of querying a table form database it's now possible to make queries from client side database, by specifying table name and fields and etc... So if it works that way, than everyone else can write another query and get all other information. I am pretty sure that I am missing something very important here, and it doesn't click my mind. So please can anybody explain me where can I start learning those primitives.
I really appreciate, and I am really eager to learn but I am searching it wrong way I guess.
Whatever the framework used, the security matter will still the same, and very similar to mobile apps:
which data can you afford to be handled in an untrusted environnement
which treatment can be applied in an untrusted environnement
By "untrusted environnement" I mean the browser itself. You have to understand that any code executed in the browser can be corrupted by a medium/good JS developper.
Data security suffer the same threat: giving access to data from your client means that you do not control anymore who is using it.
Once you've dealt with this simple matter, it became easier to decide what must stay on server side, and what can be deported to client.
That said, there are various ways to make data/algorithm steal more difficult:
Obfuscation that comes with minification
Double data validation (forms for example): both client and server side
Authentication protocols, like OAuth
Binary over webSockets, instead of plain json and ajax call...
The browser sandbox imposes some limitations, but mainly to protect the local computer from damages due to malicious JS code. It does not protect your code nor your data from being seen and manipulated by the user itself.
I am using angular for some of my projects. I haven't used other frameworks , but in angular you usually consume an API to get the data. You don't query your database directly. So, the responsability of securing your data is more in you API (Backend) than in your angular client.
You can use OAUTH, or other security method that you want to make your api safe.

Browser multiplayer network strategy - does this seem like a viable solution? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm interested in producing some sort of multiplayer RPG as a purely browser based game, with little or no plugin requirements. Having done quite a bit of research I've arrived at the following plan. I'm aware that some of the tech I'm referencing here is not adopted across all browsers ( specifically IE ) but I'm willing to accept that for the moment.
Also - I'm aware that an MMO is a lofty goal to strive for in any case, but having done lots of smaller projects in the past in a similar direction, I feel like I want to give this a really good go finally.
So heres a rough outline, I'd love to hear of glaring problems anyone can see in this arrangement:
CLIENT:
WebGL / Javascript ( probably three.js ). Use browser local storage to hold game assets, accepting that deleting the browser cache will remove these.
MESSAGING:
encode messages between client / server using google protocol buffers, for convenience and size reduction. Message delivery would be via WebSocket.
GAME SERVER:
running on top of gevent in python ( looks to be a good solution for dealing with many concurrents ). Would be built using the sharded pattern, based on the design here:
DB SERVER:
MySQL for the database, PHP acting inbetween the game server and the DB.
DETAILS:
I intend to have the game server update an individual client roughly 15-20 times per second, and use client-side prediction to fill in the gaps. Clients may send key input / messages to the server in the region of 30 fps. I'd prefer to go for an experience that is as close to realtime as possible, rather than turn-based. My main concern is the TCP based protocol of WebSocket, will this make the whole thing impossible?
Does this solution seem realistic to SO?
many thanks,
You generally get 5MB of space with the localStorage API. If you really have a 3D game with sound/music, that's going to get eaten up really quickly by your assets (how big is a good-quality mp3 these days?). You'll need to be super aggressive with compressing your assets and most likely have to come up with a mechanism to stream stuff in and out of local storage while the game runs.
I would ask why you need PHP between the game server and the database. Can't the game server speak directly with the database and save you some work?
Good luck with your project.

Categories

Resources