I'm working in javascript(React) to create a web app that makes use of multiple APIs(Spotify, Twitch, Youtube) and so far I have been using Axios to make
the REST calls successfully. But now I have begun running into Cross-Origin Resource Sharing (CORS) errors and I have been told
that I need to make calls to external APIs from a server instead of from my client. I've never made API calls from a server and
have some questions:
Everything I am doing is currently running locally using Node and I dont have a "server" unless that's what Node counts as. Do I need to get a "server"?
Should I be creating my own API and hosting it on some server so that I can call that API from my javascript code?
How do I create my own API if that's what I should be doing?
Is there a different language I will need to use to make server-side api calls?
Everything I am doing is currently running locally using Node and I dont have a "server" unless that's what Node counts as. Do I need to get a "server"?
React comes with a bunch of development tools that use Node, including a development server. It isn't designed for production use though, so you shouldn't use it for that.
Should I be creating my own API and hosting it on some server so that I can call that API from my javascript code?
Yes.
How do I create my own API if that's what I should be doing?
Write some code which accepts an HTTP request, gets the data you want to respond to it with, and makes an HTTP response.
Express.js is a popular way to do this in Node. You can combine it with Next.js to apply server-side rendering for your React app (resulting in better performance, accessibility, reliability, and SEO).
Is there a different language I will need to use to make server-side api calls?
You can write your server-side code in any language you like.
I assume you are hosting your application on a development nodeJS server, therefor you
will need an extra server.
Yes. Create an API and call it from your frontend.
Create a server which takes http requests and does your stuff according to the route
chosen.There are many examples on how to do this with for example nodeJS+Express on the
internet.
The Language you use for the server side is your choice.
Related
Im starting with Next and I'm kind of confused about how it works the SSR and the API. When should I use the API folder in pages instead of having my own server with a database? Does Next server for SSR will have any conflict if I had my server in Node for example?
The point is to provide a simple, scalable alternative to running your own server.
When you deploy API routes via Vercel, it will provision AWS Lambda functions on the backend to form your API.
These functions are sort of like individual snips of code that get run on demand when you have traffic.
You're right in the sense that there isn't too much difference. Just an alternative way to deploy your API. The main purpose is to make it easy and reduce the management associated with running a server.
For most use cases, it should work well but please note it doesn't have support for Websockets.
You're free to use API routes, or your own server. It doesn't matter and won't impact on the SSR.
I am currently in the process of creating a portfolio website for myself but due to hosting restrictions, I cannot make use of Node.js.
I know Angular can run on any web server, but is it possible to make use of Express.js to create web api's with relying on Node.js to run these web api's using Express.js?
If not, is there an alternative solution to create web api's that I can call using Angular and later for my mobile version of my website?
Please note that my shared hosting runs using cPanel.
As per definition Express.js, or simply Express, is a web application framework for Node.js so you can't do that. Alternatives would be to use a different backend language.
That also depends if your server supports them, for example, you can go with .NET CORE
You cannot use Express without NodeJS by definition so you have to deploy your backend somewhere else in you want to use it.
I suggest giving a look Firebase: you could write your backend using http cloud functions in express without paying anything until a reasonable amount of traffic (after that, is pretty cheap). You could also get rid of cPanel and deploy your frontend there via Firebase hosting.
Maybe you can try to build at first a web application with express. Of course you can create a web app without express if you need it. With express and Node.js I created a MySQL REST API. With HTML and Ajax you can fetch the Data from the API. So you can create two applications. One application where you need to run Node.js because it`s much easier to create a REST API with express. The second one is fully without Node.js.
Maybe there are better solutions, but inside each Web Application you can than but you can then access this API in any web application using jQuery. It doesn't matter if it is written with PHP, ASP.Net Core, Java EE / EE4J. You can also access this API in Ruby, Angular, React, Vue etc. using an AJAX request.
In some scenarios you can't start Node.js as a server because an application is already running on apache2 or nginx. There this would be a workaround to use something like this. For example, one could also integrate applications with HTML+JS in a CMS system that accesses other database tables and thus extend such a system without an iframe.
So can be helpful for few scenarios. Now just doesn't get around the actual goal of doing without Node.js completely or even express. But why are there REST APIs? So that you can query the data and incorporate it somewhere else. Otherwise you would have to build a REST API with another technology. Especially in the example of accessing MySQL with JavaScript, this would not be quickly feasible.
If you are looking for a similar solution to separate the web app and the REST API, but you don't need Node.js, then you should really build a REST API with .Net Core or with another technology, depending on what is possible and installed on your server. It could be Java or PHP behind it or Ruby.
The API that provides the REST access does not have to be written in JavaScript. You only need to be able to access it with JavaScript. So you can use many different approaches to access JSON data. I hope that in the short time with my bad English I have explained the basic idea, how to proceed stylistically and where advantages exist in REST interfaces.
With this, it should be self-explanatory that you don't have to use NodeJS and Express, but with JavaScript it's a pleasant solution. Only you have to ask yourself if a JavaScript application has to provide this interface at all or if in the end only a JavaScript application has to access this interface. Very big difference.
For backend rest api you can use golang with gorilla framework. Golang simple keyword and easy to learn.best important point is performance. If your server support golang you can use golang for backend..
ExpressJS is NodeJS framework so it's impossible to create an API without NodeJS.
Angular is front-end framework so you can host it on web hosting server.
If you need to create back-end APIs, you can use other clouding host servers that support NodeJS.
It's fairly simple to build this with just the net/http package. Set up a router that handles various commands and deal with the response accordingly.
I'm using django-rest-framework, which accepts API requests from frontend javascript. My frontend javascript and backend django APIs are hosted on the same apache server and are within the same domain.
Is there a way by which I can ensure that my APIs are accessible only via the frontend javascript and not via curl commands or any other programming methods ?
I'm not sure about that, the nature of an API is making it accessible to those who have the key and correct way to request information but there are other tools to achieve the same effect if you're only wanting your db accessible from your site. Take a look at django ajax https://github.com/yceruto/django-ajax it works by throwing a decorator on a view which returns a json response. I've found it to be a very helpful tool.
I'm working on a Parse web app and have run into some problems using the backbone.js based client side javascript sdk. I noticed the way I have things set up, the client can view all of my source code by simply using the dev tools to view source files and can also run code against the database (within the limits of the ACL's I've set). I've started working on rebuilding the app in cloud code using the Express.js module Parse provides so that all of my code is stored server side, but I was wondering how those using client side frameworks get around this obvious problem.
That's the issue with client-side code. Assume any code you send to the client is hacked, broken, and tampered with.
With JavaScript, your best bet is to use either Cloud Code and send AJAX or streaming data calls to the server, retrieve the data from the server at runtime (not super secure, but would fool some people), or accept that your code is vulnerable.
I typically work with frameworks in the MVC format, so I only expose a limited subset of the actual model via a REST API. I use both a client-side framework and a server-side framework. Any thing sensitive goes on the server.
I'm about to create a JavaScript-based client for a RESTful webservice. The client should facilitate access to the webservice and wrap some raw HTTP calls into more "candy" functions and objects.
I'm intending to use this client library for node.js-based applications as well as for PhoneGap. So, I don't have to care about the Same-origin-policy. However, dispatching HTTP requests is totally differnt in PhoneGap and node.js.
Now I'm wondering how I can implement a client library in JavaScript, that is portable between different "platforms" (node.js, PhoneGap, perhaps later even browers)?
Thanks in advance
You might try this emulation of XmlHttpRequest under nodejs but you still may need to special-case your client library to operate under PhoneGap (and other browser-based JavaScript platorms) and nodejs.
One way to do this would be to check the contents of 'window' which is undefined by default under nodejs, or 'global' which is (should be) undefined in a browser.
EDIT
It appears I spoke(wrote) too soon. Check out abstract-http-request which while not explicitly supporting PhoneGap, might give you enough to work with.
Phonegap is basically just a browser. So if you want to get around the same origin policy you might want to take a look into different phonegap plugins (GapSocket) to handle your own communication.
REST is an architectural style for designing web services. A web service doesn't have to use HTTP to be RESTful, though a large proportion of them do. To be RESTful, an HTTP-based web service has to rigorously leverage HTTP's resource names (URIs), operations (GET, PUT, DELETE, etc), error codes (404, 200, ...), and so on. This means that any (HTTP-based) REST client framework can interoperate with any (HTTP-based) REST server framework: if it doesn't, something's probably wrong. So your problem decomposes into finding a good generic REST client framework and one or more generic REST server frameworks.
For node.js based web services, take a look at the Geddy server-side framework (here's the documentation).
For a PhoneGap REST client, you could try the Force.com JavaScript REST Toolkit (and see this extension).
Disclaimer: I have only read about these frameworks, not used them.