As I am a bit beginner
Could anyone help with how can I connect my Front-End (deployed on gh-pages) and backend ( deployed on Heroku) with each other
Frontend consists of simple index.html file and app.js file.
And my Backend consist of server.js file.
How should I make changes to both of them. To integrate with each other.
Some more options have popped up these days but the workflow still used in 99% of apps is:
Client makes HTTP request to server
Server receives request and does something with it
Server responds to the request
Client receives response
Remember that your backend and frontend are 2 separately running programs on different machines.
The 2 most used ways to make your front-end communicate with the backend are:
To communicate you could make an AJAX call (an HTTP request from your javascript)
Complete a form (a form submission send a request to where the Action attribute points)
There are quite a few more possibilities these days but these are the ones you should probably look at first :)
Related
I recently learned about webhooks and am trying to implement one for a full-stack app that I'm building. However, I haven't been able to find information on how to create my own webhook. This is how my app is expected to work:
My client side is a website built with React, and when it loads, it will make a GET request to my server (built with Node and Express). The response will provide data that will be displayed on the website. The user will click a button on the website, which will send a (POST? GET?) request to my server, which will make its own POST request to send some of the data to an external API. When that external API data completes work on the data, it will send a POST request to my webhook URL (which I assume is part of my server), and the data from the external API needs to be sent to the client, which will display it alongside the original data. Additionally, when work on the first batch of data is completed, my server sends another POST request (with some more of the original data) to the external API, which will then make a POST request to my webhook/server with new data that then gets passed to the client again, and this repeats until all the original data from my server has been passed to and processed by the external API, and the all the processed data gets sent to my server and then to the client.
From my understanding, the webhook will allow my client to make a single request to my server, and then, my server can make multiple response to my client: one response for each POST request received from the external API. However, I have not been able to find information on how to create a webhook. Everything that I have found has been about how to use webhooks with pre-existing apps/websites like Dischord or GitHub or Stripe. Or using 3rd-party services to use their webhooks to connect pre-existing app/websites.
How do I go about making a webhook for my little project that will update my website every time that my server receives a POST request from the external API? Or am I misunderstanding how a webhook works? Can they only be created by 3rd-party services and/or only used on pre-existing apps?
For a simple use case, it just means another endpoint on your server that will receive a request from the external API when it's done with the task. It's a common way REST APIs work to let you know they are done with something, or communicate anything back to you in general. You have one endpoint that will receive a request from the React client, and send information off to the external API (as you said), and another endpoint (this "webhook") that will receive requests from the external API. That's it.
You described the client-server communications for this problem just fine with the exception that the server cannot send requests to the client over HTTP. If the client needs anything from the server, it needs to send a request and ask for it. A common way to do for this would be to store the information on the server once the external API hits your "webhook", and the client can ask the server if the data is back every X seconds (long-polling).
Example (payment flow):
Client -> Server: Heres my credit card number
Server -> Client: Thanks! Let me process that.
Server -> External API: Please process this credit card for the amount of $X and ping me at this webhook when you're done.
External API -> Server: OK, will let you know when I'm done.
Client -> Server: You done yet?
Server -> Client: Nope!
External API -> Server (to webhook): Hey, I'm done, here's the receipt.
Server -> External API: Thanks!
Client -> Server: You done yet?
Server -> Client: Yes! Here's your receipt.
More advanced ways to solve the problem would be using a long-lived bidirectional communication protocol such as websockets. And as others have mentioned, all of the endpoints don't have to be on the same server. You can have one server for each endpoint, and you can have turn them on only when they get a request and then go back to sleep (that's a Lambda). Pros and cons to this approach. That's more advanced stuff and if you're just learning I wouldn't really worry about it now.
AFAIK, webhooks are just normal web APIs. Properties that make an API a webhook:
The client sending requests to your server, in this case, is another server
This client will send you a request when there's a triggered event
In your case, your server POSTing data to the external API. What makes webhook different is that the external API's server doesn't have to respond right away, instead, it sends back you, for example, an HTTP 200 OK to acknowledge that it received the request and has started to process the data. When the external API's server finishes processing the data (which is an event), it will call your server's endpoint to inform you about the process along with the processed data (if succeeded).
Your server, correspondingly, will then have to inform your client (the user) about the processed data. I would suggest implementing some kinds of persistent connection (WebSocket or SSE), or simply just make the client poll request every some second.
"(which I assume is part of my server)"-- The webhook is part of the third party API that points back to either your server or maybe some serverless function/lambda(that you set up) that in turn can parse and perform computations on the data and then send it back to your server.
It really depends on the use case and architecture of your API. If you don't want your main API server to get overloaded, if say you need to perform heavy I/O, CPU/GPU processing, you could create Serverless Lambda Functions to handle this data processing and be the endpoint you supply to the third party's webhook post endpoint.
If you're not concerned with it, you could just create another endpoint in your server to handle this webhook.
Just keep in mind, when you're trying to scale up, you want your systems to be as distributed as possible-- within reason-- so your API can handle more requests and not be overloaded with a bunch of processes.
I'm making a new website with HTML, CSS, js for frontend and Java for backend (I don't know Java, my friend will do the java part) and I need to use frontend technologies (languages/frameworks) to use localhost
I am unable to find frontend technologies for this purpose. I have already tried python -m SimpleHTTPServer and node.js but as these are backend I can't use them. Also, I can't change my backend language
The important thing here is that you need to understand the terms backend and frontend.
A website is by definition something that can be loaded from a server with HTTP and it made of HTML and maybe CSS and/or Javscript.
Now by definition every code that runs on that server is the backend. All code that runs in the Browser of the user is considered the frontend. If the website only contains HTML and CSS that is generated by the server it does not make much sense to do this seperation. This means we only talk about frontend and backend if we have both.
This also means that the frontend code, that runs in the browser, must be delivered by the backend. A frontend without a backend can not exist.
Lets look on a little example. If a user enters example.com in the browser the browser will make a HTTP GET request to example.com. The server (and so the backend) will respond with a HTML file. This file now could embed a javascript file with <script src="/code.js">. Now the browser does another HTTP GET to example.com/code.js and the server (and so the backend) returns that file. In that file may be some frontend code that is executed in the browser.
Now maybe this file wants to load some data from the backend. So it does a fetch('/api/data). The browser does anotherHTTP GETtoexample.com/api/data` and the backend has to respond. Now while the backend was relativly dumb up to this point and only delivered files it now could actually execute some logic. Maybe load the data from a database or such. It then sends the data to the frontend which then can use that data to do something.
This means in production your backend has to deliver the frontend code. In this example the initial HTML file and the code.js file.
So what you want is by definition impossible. A frontend runs in the browser and so can not deliver code on localhost. If it could it would become a backend.
Now while its common that the real backend delivers the frontend code on production its not common for development. Its very common to have a seperate minimalistic server that is only used for development. python -m SimpleHTTPServer is such a tool and so would do the job.
Sometimes this is also done in production. Then your backend is for example on example2.com and your frontend is delivered by example.com. But this essential means that there runs a second backend just to deliver the frontend. Usually for production this is a full fledged web server like nginx, apache or IIS (you'll need CORS, see below). In contrast to them tools like python -m SimpleHTTPServer should not be used for production.
Now this means basically you can just use any kind of backend to deliver your frontend for development. Later you will give your code to your backend developer and he will then deploy it with his backend. However there is one open question:
How will your frontend and backend communicate?
In production your frontend can just fetch something and it will work if your backend delivers your frontend. But for development (and so testing) you probably already want to use the backend without actually starting it on your computer. For this basically there are two ways.
First your development backend could proxy unknown requests to the backend. This means if your real backend runs on example.com and you start a development server on localhost that server will proxy all requests that are not an existing file to example.com. So if you request localhost/code.js and the file code.js does exist your server will respond with that file. If you request localhost/data and you have no file named data your server should do a request to example.com/data and return that response. This is very common. Depending on the tools, libraries and framework you use for frontend development they have a integrated development server with that capability. For example if you develop with ember.js you can do ember server --proxy=http://example.com. And it will run a server on localhost:4200 with exactly that behavior. Other tools like create-react-app allow the same.
Second you can use CORS. This must be implemented by the backend and allows a frontend from another server to access the backend. This is also needed if you run your frontend and your backend from two different servers as I described before.
If the backend implemented CORS correctly you can just do fetch('example.com/data) to get your data, and this Javascript must not be delivered by example.com and it will just work. However CORS complicates security.
I have an Apache server A set up that currently hosts a webpage of a bar chart (using Chart.js). This data is currently pulled from a local SQLite database every couple seconds, and the web chart is updated.
I now want to use a separate server B on a Raspberry Pi to send data to the server to be used for the chart, rather than using the database on server A.
So one server sends a file to another server, which somehow realises this and accepts it and processes it.
The data can either be sent and placed into the current SQLite database, or bypass the database and have the chart update directly from the Pi's sent information.
I have come across HTTP Post requests, but not sure if that's what I need or quite how to implement it.
I have managed to get the Pi to simply host a json file (viewable from the external ip address) and pull the data from that with a simple requests.get('ip_address/json_file') in Python, but this doesn't seem like the most robust or secure solution.
Any help with what I should be using much appreciated, thanks!
Maybe I didn't quite understand your request but this is the solution I imagined:
You create a Frontend with WebSocket support that connects to Server A
Server B (the one running on the raspberry) sends a POST request
with the JSON to Server A
Server A accepts the JSON and sends it to all clients connected with the WebSocket protocol
Server B ----> Server A <----> Frontend
This way you do not expose your Raspberry directly and every request made by the Frontend goes only to Server A.
To provide a better user experience you could also create a GET endpoint on Server A to retrieve the latest received JSON, so that when the user loads the Frontend for the first time it calls that endpoint and even if the Raspberry has yet to update the data at least the user can have an insight of the latest available data.
My question is about:
I am currently trying to connect my electron application to my node server to get data from node.js server and print that data to my electron application. However I don't know how to do it. So could anyone help me:
To get data from node.js server into electron app?
The way you get data from any node.js server is you make a request to that server specifying in the request what you're asking for and the server responds with the appropriate data.
There are literally thousands of ways to physically make the request. The classic way in these days of web technologies is to make an http request from your electron app to an http server in your node.js server. You can make such a request from electron using the request() library.
You would then have an http server as part of your node.js server and you'd specify routes in that http server that handle the requests your electron client is making, fetch the desired data and send the data back as the response. In the node.js world, you can create a simple http server and a few request handlers in a dozen lines of code using the Express library.
This is the general approach. Further details on the exact request to make and URLs to use are dependent upon the details of what you're trying to do and the design you choose, none of which you've shared with us.
I am quite new to javascript and web application environment. I have seen a react web application project which had a public directory, a client directory and a server directory. I have few question
Why do we need an express server file setup in the frontend project if we already have backend APIs ready and backend server ready
Do we need an express server if we make the frontend on react and call the APIs to fetch the data for application.
Isn't the backend server and express server in the frontend project are same?
Why do we need an express server file setup in the frontend project if we already have backend APIs ready and backend server ready
You don't.
You need an HTTP server to listen for and respond to any Ajax requests you make from your client side code.
You need an HTTP server to listen for and respond to any requests for the HTML documents and static resources (JS, CSS, images, etc) that your pages need.
These can be the same HTTP server, different HTTP servers, written with Express or not written with Express.
React tutorials tend to ignore mentioning this and just dive in showing how to use Express for everything. Don't read too much into that.
Do we need an express server if we make the frontend on react and call the APIs to fetch the data for application.
No. See above.
Isn't the backend server and express server in the frontend project are same?
Maybe. It is up to you. See above.
There is no such thing as a "backend server" and a "frontend server", a simple web application is composed of two main parts:
1/ an application that serves html pages, which runs on a backend, so it is usually called a server, but a typical cloud server nowadays can run hundreds of different serving apps at the same time
2/ a frontend, which is typically a complex piece of JavaScript software and html pages that are dynamically send to the user browser and execute locally
The minimum that you require to have a working website is a server application that will return one or several html pages upon user request. A typical React + Node project is organized as follow:
A server directory: which contains all the code for the serving app - the one returning the webpages, it can also contains code that handle the REST API, in case your client app requires dynamic data or if your server connect to a database. Note that the webpage server and the API server could be two different- or more - applications.
You usually dont want to share to users your server code, so typically you have a public directory that contains the html pages and this is the only location on the disk - theoretically - that can be access by users. This directory can also contains required images and resources needed by the webpages, it is also called static resources
To keep thing more organized, the code of the frontend application is placed in a client directory but on production is usually bundled in one or few files, depending on the size of the app, and also placed in the public directory, so it contains everything needed to serve the app.
Hope it helps
We don't need an Express server, however, adding it comes with great benefits:
It helps add compression to an angular / react application that uses only in-memory server (if that is your case).
Defines base path where to serve static files for your project and can also add gzip compression headers for each of the request so that the server returns the compressed versions.
Helps you parse your API calls to the correct format expected by the UI so that the parsing logic stays in the express server and not the UI. This is helpful in the event that the API response changes in the future, or when the final backend endpoint changes, no need to modify the UI, but the route in the express server.
I have found out these and other benefits while looking how to add compression to an angular application (turns out you cannot without express or an actual web server).