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
I have recently begun exploring the concept of microservices and API gateways and am particularly confused on how frontend endpoints should be hosted.
If I have an API gateway that acts as the middleman between requests to all of my services, where exactly should the frontend be hosted? If I request /api/example, I understand that my API gateway should route that to the appropriate service and forward that services response. I do not understand however, how an API gateway should handle /home/ in a microservice context. In this case, we want to deliver html/css/javascript corresponding to /home/ to the client making the GET request. Does this mean that we should have some sort of frontend service? Won't creating a service that just returns HTML/CSS/JS be redundant and add increased latency, since all we really need to do is just immediately return the HTML/CSS/JS associated with our frontend?
An alternative I was thinking about was to have the API gateway itself provide endpoints that return the HTML/CSS/JS required for the client to render the frontend. In other words, the API gateway could just immediately respond with the HTML corresponding to /home/ when receiving a GET request to /home/ rather than calling a service. However, I read online that API gateways should not be actually serving endpoints, rather just proxying them to services.
That is my main question: Where should frontend code go when your backend is built out using a microservice architecture?
I assume your frontend is Single Page Application. SPA has static content like HTML, CSS, images, fonts etc. It is the perfect candidate to be deployed as static website that gets data from backend using REST APIs.
In cloud environments like AWS, GCP it is recommended to host SPA applications separately from REST APIs. e.g. in AWS SPA can be deployed in Amazon S3 and it remains directly accessible without going through API gateway.
API gateway is supposed to be used to only route REST API calls and performing cross cutting concerns such as authentication etc. However the problem with this approach is that you will get CORS error while hitting REST APIs from frontend because SPA and API gateway will be hosted on different domains. To overcome this issue CORS need to be enabled at API gateway.
If you are looking for simpler solution, frontend can be served from a service through API gateway. Since static content is served only once in SPA it should be okay to start with this approach for simpler applications.
https://aws.amazon.com/blogs/apn/how-to-integrate-rest-apis-with-single-page-apps-and-secure-them-using-auth0-part-1/
https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
API Gateway as you have already mentioned should act as a proxy/router with minimal logic. And as the name says it all, its main purpose is to expose API and not GUI components/pages for different types of clients and address some of the non-functional aspects e.g. security. Provide high-level API [use case driven] based on requesting client[basically BFF/Backend for Frontend approach].
When it comes to having frontend/GUI fittin to microservices, you can think of having UI Gateway/Container which is backed by Micro FrontEnds. Also, refer to MF's site for details on micro frontends.
So, following microservices architecture for frontend, your frontend code should reside in micro frontends along with other microservices.
Before answering your question let me go through the different rendering strategies:
Traditional Server Side Rendering
Quite uncommon nowadays. You don't need any API gateway, since everything is computed and rendered in the server you can perform the necessary calls to other microservices there.
Pros: simplicity; instant interactivity for the user on page load; SEO
Cons: full reloads each time
Client Side Rendering
Most popular option in the last years. You provide a basic static HTML/CSS/JS bundle, perform requests to an API to retrieve some data and use some sort of template engine to render new pages and components.
Pros: no full reload; lazy loading; richer interactions; benefits from CDN
Cons: SEO; page not interactive on load; slower first load
Since the rendering happens in the browser you don't need to serve the static HTML/CSS/JS files from your server. Instead, you should use a CDN to deliver them faster.
The other requests to non-static resources will be performed against the API gateway, which is responsible to forward the request to other services (or make some sort of orchestration/aggregation).
Modern Server Side Rendering
This is gaining traction nowadays thanks to frameworks like Next.js. The page is initially rendered in the server using the same template engine that it's going to be used in the browser, so you can send an interactive page faster while keeping the features and benefits of client side rendering.
In this case all the static pages can be pre-rendered, cached and served through a CDN. For dynamic pages you can still send a partially cached/rendered page that will later fetch the additional necessary information from the API gateway.
TL;DR: You don't need to serve your static HTML/CSS/JS from your API gateway or your server. You should deliver them through a CDN to improve loading times.
Otherwise the static files shouldn't be served through the API gateway, IMHO. You could make your /api/{resource} requests go through it and forward all /{page} requests to static resources.
Using API responses for a Frontend app, does not make sense if you are returning the WHOLE body of the Frontend, as you point out.
However, you can load (initially) a frontend, that contains let's say header, with a menu, footer, and a main body section with few elements, like articles.
Upon interacting with this frontend, an action can be triggered to that API (usually via JS Ajax calls), which will request specific portions of new data from the API, and once received, the JS will update only the relevant portions on the webpage, and not reload or replace (or refresh) the WHOLE page.
This if done correctly can save a great deal of network traffic, thus making the website more flexible, without it being fully reloaded every time you need new data to visualize.
One simple example:
When you click on a link in your menu, to load a contact form, the API will return either the raw HTML for only the contact form, or it will return (usually) a JSON object/array, that will be used to further generate/replace a portion of your main body, to BECOME now the contact form..
Where exactly should the frontend be hosted?
Where should frontend code go when your backend is built out using a
microservice architecture?
Your Front-end (web) application usually sits BEFORE the API Gateway. Requests to resources like HTML/CSS/JS are served right from the Front-end application itself, hence no API-Gateway involvement here whatsoever. If the page contains an (AJAX) call to a back-end (Micro)service, it might (should) go through the API Gateway. From hosting perspective, they are hosted as a separate web application.
how an API gateway should handle /home/ in a microservice context?
It won't (i.e not intercepted by API Gateway at all). Requests like /home are page requests served directly by Front-end application itself (Of course, it will have its own scaling mechanisms like Clustering, Caching etc)
A novice javascript developer here!
A have a basic question on whats the best and secured way to make HTTP calls from a front application to a backend service that needs an authentication. My application is a SPA (using Vue.js) & getting data from Java services. Java services need authentication details and return sensitive user data.
I see there are a few options and I wanted to understand a better approach amongst all 3-
Making direct HTTP calls from javascript code- Concern for using this approach is, as Javascript code can also be viewed via dev tools in browser, wont it be easier for anyone to do an inspect and view all critical authentication details hence making overall integration less secure?
Making an HTTP call using Axios via Vue framework- Seems like Axios is Promise based HTTP client for the browser that lets you easily make HTTP calls without much code overhead. but is this secure? is Javascript code loaded in the browser? Or the front end code sends the request and axios makes the request from backend server where the application is hosted?
Using Node- If front end application has unique routes configured for each API call and in my application if I have a route mapping to use request module and node js backend code to make those HTTP calls, is that going to be a robust and secure way of integration?
Please let me know your thoughts and apologies if this is a dumb question!
Not dumb at all. You're just learning.
My first question to your answer 😅 will be: is your application server-side rendered or it's sap + backend?
If it's server-side rendered then I would say it's secured since Node will be sending pages with all required data. On the dev tool, you will only see static files being loaded.
However, if it's SAP, I am not sure whether there is a way to hide whatsoever you send to the server from the dev tool. The only one thing you will need to do is to make sure you encrypt whatever is sensitive to your application.
I am studying NodeJS and React front-end. And I want to test what I have learned by making a web page.
I want to create two servers: back-end server to provide API, front-end server to manipulate data by communicating with back-end server through AJAX.
In backend server, I will use NodeJS(expressJS). I have been reading below link to install expressJS server.
enter link description here
but I am stuck on choosing which template engine do I use. Since I want my back-end server to be provider for just only API - besides, I am not sure what API means correctly, I guess it is for manipulating data throguh AJAX
So simply my question is,
What template engine do I have to adopt in my back-end server?
I'm new at Firebase, I'm starting making a project which has to include Firebase and angular2, but I am such confused about how to implement them. I don't know if a there's the need to have a Back-end implementation (like Java or NodeJs) to handle some security issues (like form validation, authentication, routing etc), or it's enough just implementing Angular2 to handle all these issues. I would be so Thankful about any helpful advice how I could implement these both technologies to build my project successfully. Thanks
first firebase is something like your backend firebase can safe get and send request as your backend apps...
and angular js will do the rest like you just said andd all the backend stuff you can handle by firebase :)
This is my simple explanation on how this 2 works together
Always keep in mind that Angular works only in front-end. Its domain is the look and feel, application events, sending data to server and anything else that has something to do with displaying data is coded in this area.
Backend services in the other hand interacts with your database, creating business logic, handling authentications, saving / sending of data and other stuff that interacts with the database is coded from here.
Now how these two interact is done by the frontend service to send HTTP requests to the Server which is the backend service. This is done by using Angulars $http service or the so called jQuery AJAX or the infamous XMLHttpRequest JavaScript native. New technologies today utilizes Web Sockets which is being used by Firebase and some other frameworks, Web Sockets offers a faster way sending / fetching data from server.
The server then interprets the data being sent and send appropriate response. For example getting user list, saving profile, getting reports, logging in, etc.. It would work in this workflow.
1) Angular sends http request to server to get list of users.
2) Backend service installed in the server then interprets the data being sent.
3) Backend service then gets list of users from the database.
4) Backend then sends the data back to the frontend service.
5) Frontend then recieves server response and displays the data to the view.
Also these two is coded separately. To have more detailed explations research about how frontend and backend services interact you can find so much resouces in Google.
I have developed a front-end interface using Aja(AngularJS) and HTML5. Right now, I send an HTTP get request to my backend server which returns some data based on the GET parameters.
Since the URL is exposed in the Javascript file, I believe anyone could just use the URL to create there own API to fetch the data. How can I prevent such things ?
One way I could think of is that now instead of directly sending the request to the backend server, an application server could be used (hosting the HTML as well). The Ajax request would then be sent to this server (PHP script ?) which would in turn forward the request to the backend server and return the result to the UI. To prevent 3rd party services, I can disable cross origin requests on my application server.
Is this the correct way to solve my problem or are there better ways to do this? I am concerned that this would unnecessarily create another hop (internal though) for requests.
Note: The backend is running Apache Tomcat
In APIs that are not open to the world the user has to authenticate first in order to use it, see for example https://stripe.com/docs/api#authentication or http://dev.maxmind.com/geoip/geoip2/web-services/ -> Authorization