Frontend Backend communication clarification - security

Pretty new to web development so apologies for the probably obvious question.
I see everywhere that the frontend makes requests to the backend and not the client directly.
But let's say I have a react app, that runs on the browser of course, and it makes Ajax calls to the backend, so it's basically the client makes the call and not the frontend server which serves the index.html and whatnot.
Does that mean, from a security perspective, that I should permit access to both frontend and backend servers from clients?
Much thanks!

usually, today FrontEnd(FE) , it is just Codes that runs in the client browser.
generally speaking, Modern Architecture is built from FronEnd (code that runs in Client Browser like React, angular, HTML, JS etc.) that communicates with a server (Node JS, PHP, etc.)
a few years back there where a FrontEnd Server that generates the Client-side for the users that cold FronendServer (that server had FE DB etc) and that server communicated with BE server that kept more sensitive data.

Related

React app listning for backend notifications

I'm developing a react app and I need to trigger notifications in it for database changes , My back end is node and I'm not sure how to achieve this task. Should I listen always from front end for back-end notifications?I need to do It like how they do it in Facebook, When I develop my flutter apps I used Firebase streams to achieve this and don't know how to do this in react and node with PostgreSQL database.
You can use web sockets or socket.io library.
https://socket.io/
Old browsers don't support web sockets, in that case you need to check repeatedly from the front-end whether there is any notification from the back-end, lets say when database changes. This is called polling.
But, socket.io supports this polling automatically if browser don't support web sockets.
Socket.io is used by many applications . Your purpose seems to be solved using this library. It is event based. Once there is any database change in backend, and if you set up a socket.io event emitter, your front end will receive it via socket.io on the client and your react app can finally notify the user.
From their website,
Socket.IO enables real-time, bidirectional and event-based communication.
It works on every platform, browser or device, focusing equally on reliability and speed.

Building scalable SPAs using websockets, how complex is it?

I am beginner in web technologies. While studying about frontend frameworks, I came to know that we run separate application servers for frontend and backend server(API).
e.g. If I am using vue.js, I'll be running a vue server for frontend and I'll be running another MEAN stack API server separately. Now my application will need to show real-time updates, I'll have to use websocket connection between my browser and frontend server which further will need websocket/webhook connection with my backend server(API). Now I am already aware of the scalability and session management issues with websocket connection. In this scenario, how should I build my application for better scalability and with less complexity? Is it possible to create a monolithic application server for frontend and backend? Will that be a good choice?
Is it possible to create a monolithic application server for frontend and backend? Will that be a good choice?
That choice is fine; start simple and you can break into microservices in the future. Unless this is for a large production system!
If you use something like express you can serve the Vue.js files using express.static, API endpoints using express.Router() instances, and the ws or socket.io module attached to express instance for websockets.
Now my application will need to show real-time updates, I'll have to
use websocket connection between my browser and frontend server which
further will need websocket/webhook connection with my backend server
This isn't the case. You can have your frontend (the app running in a browser) connect directly to the backend via websocket if you wish, no need to proxy via a frontend server. For session management look into JWT tokens.
You can go for socket.io library in Nodejs. It's simple and easy to use, The scalability and session can be handled by introducing Redis,
check https://socket.io/docs/using-multiple-nodes/

Transfer data from Node backend to React frontend

What I want to achieve is having a react application receive data posted to a Node-js server. Currently, the Node server receives a POST from an external source with a list of items. When the Node server receives the data, I want to send the data to the react application. This data will be used in the react application to display the listed items. How would I proceed to make this possible? Any advice is appreciated!
Thank you!
You can do this using Web Sockets. It would look something like this
Your app connects to your API and maintains a socket
The external source will POST to your API
API handles the POST request
Then the API passes some data on to the React app over the web socket
Your app consumes said data
Profit?
Socket.IO is a popular JavaScript library for web sockets with fallbacks and stuff.

I'm confused with the meaning of WAS(Web Application Server) and web framework

I think I know what framework is and some famous framework like ruby on rails, spring, and I think I can distinguish between the meaning of web server and web application server.
but I don't know what is different between WAS and framework, for me I think framework is a kind of WAS because framework is doing many dynamic works related with database handling request from web server(Apache or nginx)
I'm confused with the relationship between these two part in Web programming.
Could you explain it?
Basically the framework is only responsible to provide a response to an http request (that includes handling the database as you said). But Rails isn't responsible to open a new thread (or in some implementations, a process) whenever a new http request arrives - this is done by the application server (such as Puma, Webrick, Unicorn etc). This is called concurrency (the ability to serve the app to multiple requests at the same time, in a nutshell) and is purely the job of the app server. Another thing is understanding (and parsing) the http request - Rails doesn't implement http, it receives a ready request from the app server who does implement http.
In ruby land the job of each part is defined by the rack protocol https://rack.github.io/. Rails, as a rack application, simply waits for "something" (the web application server) to 'call' it (with an http request), and it returns to it the response.
So to sum up: the application server needs to handle threading or multi processing to serve http requests to Rails (the app server is basically always listening on some socket for new requests, and provides concurrency either by forking processes, opening new threads or both. It depends on the app server). The app server therefore also needs to understand http (be able to parse an http request) so it can server that to Rails.
Rails, the web framework, only needs to handle an http request and return the response.
for those who want to understand the difference between web server and app server.
refer to What is the difference between application server and web server?

Angular2 + Laravel with Real time & WebSockets

I built an app and i'm planning to make a real time battle with Angular 2 and laravel. For example, you hit the "attack" button, and your opponent see his life going down in real time.
My app built with:
frontend: Angular 2
Backend: PHP Laravel 5.2
Now I'm searching and learning for my real time battle component,
and I saw different guides and tutorials for it:
https://www.codetutorial.io/laravel-5-and-socket-io-tutorial/
http://4dev.tech/2016/02/creating-a-live-auction-app-with-angular-2-node-js-and-socket-io/
The first tutorial is about how to use Laravel 5 and socket io.
The second one is how to use Angular 2 with NODS JS and socket io.
When I say real time, I mean that both users see the same thing that is happening on the screen)
My Backend and Frontend are totally divided and I have no setup with NodeJS anywhere in my app.
Both users need to see actions happening during a battle in my app, and It need to go through my laravel API and shown via my Angular 2 battle component
My question is -
What's the best approach to real time app (seem websockets) using Angular2 and Laravel 5.2 to get the desired result of what I'm trying to achieve?
Laravel in this context is just templating and serving the client files, and acting as an interface inbetween the client and the socket.io server. It doesn't actually act as the socket.io server, and I don't believe it can.
So yes, you would still need something (node) to host the socket.io server to interact with the client, through PHP or otherwise. Personally, I'd skip Laravel/PHP altogether and just use node with koa/express/whatever to template your client (html/js/css/etc) files. Feels like an unnecessary abstraction to me.
The code below from socket.blade.php already has a connection to the actual socket.io server, so I don't see why the additional overhead of an HTTP POST through PHP/Laravel is a good idea. Security, perhaps, but you can handle that with the actual socket.io server as well.
var socket = io.connect('http://localhost:8890');
socket.on('message', function (data) {
$( "#messages" ).append( "<p>"+data+"</p>" );
});
For the real-time character of your use-case, websockets are definitely the way to go. The players that should get the updates should be in the same 'room', so you can broadcast changes more easily. For the other functionality you can either use websockets or regular API calls to your backend directly from your client-side app code with some kind of communication between your api and the socket server, e.g. through Redis.
TLDR:
All data through sockets, node server does api calls and broadcasts changes to active players
Use API from app directly, use pub/sub queue foo for communication between laravel and node to broadcast changes to active players
Option 1:
Angular frontend app
Set up websocket connection
Add triggers for game foo which will send data over the socket connection and is handled by your nodeserver
Only talks to sockets
Node server
Serves frontend app
Handles socket connections, divide players per game
Handles socket calls and calls laravel api to do mutations on your data
Process action and broadcast changes to players in game X
Laravel REST API
Auth x
Default CRUD foo
Option 2:
Angular frontend app
Talks to api directly
Uses sockets to listen for updates
Node server
Serves frontend app
Handle websocket data
Listen on queue for published data from API
Broadcast changes to players in game x over socket
Laravel REST API
Auth
Crud
Mutation x triggers publish in Redis or other queue, which the node server can/should listen on
I'm sure there are more ways you can set this up, you just have to decide where you want what. Maybe introducing Redis is something you do not want, in that case your node app will have more to do. If you do want to use something like Redis, you'll need to do API calls from either your frontend app or choose to do it through the node app anyway, combining the 2 options.
If you are planning to use websockets then there seems to be less use of laravel as only one socket is pretty capable of handling all the data that will be exchanged between the frontend and the backend, so if you don't mind changing your engine you can try Meteor, https://www.meteor.com/

Resources