I have a front end written in react and a backend API which connects to a db for getting data. They have been written separately and are different services.
The front end server has a bunch of routes that connect to the backend API and I'm wondering what are the pros / cons of having these routes instead of directly accessing the backend API?
An example of the structure:
Front end server serves index.html and browser.js.
Browser.js makes GET, POST, PUT requests to front end server.
Front end server takes these requests and then makes a GET, POST, PUT request to the backend API.
Alternative:
Front end server serves index.html and browser.js.
Browser.js makes GET, POST, PUT requests to backend API.
So what are the pros / cons of doing it either way? The prior developer before me told me they did it the first way to bypass CORS and obscure the IP address of the backend API. However that doesn't seem to me like it is worth the trouble considering all the extra code, tests, etc the front end server has to write and maintain, in addition to extra network hops. I'm wondering if I'm missing some other more crucial reason that my inexperience cannot see? (My gut says do it the second way). Note that we are in a microservices architecture .
Front end server takes these requests and then makes a GET, POST, PUT request to the backend API.
The pattern that you describe is called API Gateway and it has the following characteristics:
Benefits:
Insulates the clients from how the application is partitioned into microservices
Insulates the clients from the problem of determining the locations of service instances
Provides the optimal API for each client
Reduces the number of requests/roundtrips. For example, the API gateway enables clients to retrieve data from multiple services with a single round-trip. Fewer requests also means less overhead and improves the user experience. An API gateway is essential for mobile applications.
Simplifies the client by moving logic for calling multiple services from the client to API gateway
Translates from a “standard” public web-friendly API protocol to whatever protocols are used internally
Drawbacks:
Increased complexity - the API gateway is yet another moving part that must be developed, deployed and managed
Increased response time due to the additional network hop through the API gateway - however, for most applications the cost of an extra roundtrip is insignificant.
Conclusion: if you don't need the advantages that the API Gateway provides then you should not use it.
Related
i am taking a course in web data so i understand that when we want to retrive a webpage on a browser we do a request response cycle using a communication protocol like http or https and a web service is a piece of software which i dont know where it is stored or how it is accessed so we can make two applications from different architectures communicate using a serialization language like XML or JSON i dont know what is the difference between a web service and http they are both a way to connect 2 different computers together and what confused me the more is api which according to the research i did is something used to access web services.
Let's begin with defining all the terms in your question since it's a bit all over the place.
HTTP (Hypertext-Transport Protocol): Allows you to transfer data over the web. Your browser will perform a request using HTTP to your web service.
Service: Any software that performs a specific task. We are interested in a web service, which is typically invoked via HTTP, however this can be anything else such as a Linux signal.
For now, let's assume it listens on HTTP.
API (Application Programming Interface): An interface by which all clients of your software have to abide by to use it. For example, in our web service, we can dictate an API so requests follow some convention.
Let's put it all together now.
You're making a website that wants to calculate the sum of two numbers. First, users will go to http://yoursite.com, and then the browser will always do an HTTP request to the domain yoursite.com on port 80. This will hit either your hosting site or some backend server.
Here you have the option if you're using something like GitHub pages to serve static content or you have some server (i.e., serverd) that will load a file and serve it.
So now the web-browser did an HTTP request and your webpage should load with an index.html. The user can now click on buttons, and everything looks good until they press Calculate -- what happens now?
We want to offload the computation to our backend. We perform an HTTP request to our backend server. We can define an API, that is in our case an endpoint, so that the HTTP request can hit it and it'll return the sum of the two numbers.
How do we return the result? We need to represent the data somehow, and this can be done through a body payload that is encoded as either JSON or XML. Again, this is a serialization format and can encode it in various different ways. JSON is nice because you can parse it easily with JavaScript on the client side.
Great -- so now we got an entire site and it works! Now we can do an HTTP request from our browser straight to the backend according to our setup endpoint and it should fulfill our request. Notice how now we're using the API from the backend server from within our site.
Other keywords you can may run into: CORS, AJAX, Apache Server; good luck!
So far all the guides i have looked at involve communicating with a frontend client via Graphql, I wonder does it have any usage for something purely backend, such as communicating among microservices?
You can certainly make a request to the API from another server as well. Just as you can make a call to any REST endpoint from anywhere, you can perform server to server communication with GraphQL APIs as well.
For example, at Scaphold, we use Lambda for many webhooks and scheduled tasks. And from our microservice, we use the request library to make POST requests to the Scaphold server's GraphQL API.
Here's an example of a create mutation that you can use from a Node server.
Hope this helps!
I've been doing a ton of research on Microservices however I cannot find a single piece of code that is written for an API gateway. I understand that between the clients and services you would have an the API Gateway which allows a client to make 1 requests over IoT to the gateway and then the gateway can make many requests internally to services which then build up a response. Now from an article on NGINX
The API Gateway is responsible for request routing, composition, and protocol translation.
use case
Suppose we support 2 clients. Android and an Angular App (browser) and let's make a tangible user story that the client is an online shopping store.
the shopping store would then have different services broken out into servers and each service could be built on a different platform/language with a different database. They are completely self contained so that they can scale in the cloud really quickly without having to scale the entire application. If there is some intense Algorithm that needs to run for payment. Then the payment services can quickly spin up a few more servers to balance the load and decrease user wait time.
but that could be written in Java which could have a HTTP/REST exposed api to be consumed. However what if it's written in say c++/Golang/Node it doesn't really matter what language, but instead of exposing their api via HTTP it's by a different protocol what would that mean on the api gateway - how would it handle the response?
the client goes and makes a request to the home page where we have 3 things loaded
shopping cart
list view of shoppings items
current specials
the client would only make 1 request to the api gateway let's say to apigateway/apiv1/home to the api gateway which then would have 3 requests to the services so
serviceShopping/apiv1/shoppingList
serviceCart/apiv1/cart
serviceSpecial/apiv1/specials
at this point the 3 services could be written in a different language and use a different protocol. How would those 3 services be requested and on the response back to the client (a single response) how would it be concatenated? json object with a specific schema? this is where I get confused...
sorry for the long post it's a simple question I think, but I needed to setup something I can conceptualize with and explain.
We're building:
A bunch of services exposed through a web API.
A mobile app and a browser app.
Is it common practice for the apps to respond to their own conduit servers that end up talking to the API services? We're going to be setting up a reverse proxy - is it enough to directly hit our APIs (instead of setting up a conduit)? This is definitely a general architecture question.
I'm not sure what you mean by a "conduit", but a lot depends on how complete and hardened your APIs are. Do they already handle things like authentication, abuse detection/control, SSL, versioning, etc...
There are companies that specialize in providing this "middleware" of APIs (Apigee, Amazon API Gateway, Azure API Management, and many others). Your reverse proxy is a start, and is probably good enough to get going with (at least you do things like terminate your SSL, and lock down your API servers behind a firewall). If you make your API services stateless, you will probably be able to add new layers at a later date without too much pain and complexity.
For an enterprise REST API (PHP in this case), is it a bad practice to include a web socket server along with a REST API? The pairing of the two makes a nice mix with event dispatching services, but I'm not sure if these two services are different enough where they warrant separation? I guess the only con I can see at the moment, would be that if the REST API were to go down, then your web socket servers are also down, which removes the possibility of having fail-over for any connected clients, or something to that degree.
If you're looking for a really robust way to manage web sockets, check out http://faye.jcoglan.com/ - it has libraries for JavaScript, Ruby, etc, and runs independently of your other servers.
If you don't need that kind of resilience, then I wouldn't worry about mixing your REST and web socket APIs on the same server.