Our system is build using microservices, that all sit behind an API gateway. Since all of them are REST API services, the benefits and whole point of using API gateway is clear to me. Now what about frontend microservices - the small components, that have both UI and corresponding backend to handle internal communication? Are there any scenarios where proxying every microservice HTTP calls is harmful?
Example
One of our microservice is a payment provider integration. As dealing with payments have specific regulations, one of those is a required web browser redirect to the user's bank page for authorization. Since this is impossible to do in a purely backend way, we deliver a frontend microservice - a service that essentially serves a HTML you must nest inside an iframe and should be able to process the payment in an e2e way. Very simplified and stripped example below.
Let's say you are on https://acme.com/order and want to pay, where such snippet is embedded:
<iframe src="https://pay.acme.com?amount=42+USD
&returnUrl=https://acme.com/thankyou/[orderId]">
</iframe>
Basically a fire and forget thing for the developers of https://acme.com. What happens inside an iframe stays there. https://pay.acme.com however now worries about: collecting credit card details, validating them, redirecting user to the bank page to enter 2FA code or whatever needed, waiting until the payment is approved and finally moving user back to the returnUrl with a proper trail for which order the payment was finalized (orderId).
Now, what about pay.acme.com frontend <-> pay.acme.com backend communication? Would it be OK to let microservice talk to itself, or rather all, even the internal communication that doesn't make any sense for API consumers, must go through the API gateway? That is of course possible to do and still keep the microservice decoupled and unaware of the API gateway, but this is much more costful than deviating from the always do constraint and bring very small benefits, as we don't use any advanced rate limiting or proxying features for now.
There is simple approach - To have UI gateway. Gateway that instead of API calls will route and proxy asset request calls (static files serving).
If entities belong to the same bounded context (pay.acme.com frontend <-> pay.acme.com backend) they should definitely exist as single backend microservice that serves one of:
isomorphic js
thin client apps with real-time reload (then UI gateway will need to proxy ws connection)
thick client app (SPA)
Such microservice is regular microservice which API (if exists) should be accessible through API gateway, and UI should be proxied via UI proxy/gateway.
Hope that helps.
Related
We configured Azure web app infrastructure such way that consist
customer web portal and WebApp API site
Scenario: when a user accessing a customer web portal where all requests communicate from Web API like (GET, POST, DELETE, PUT).
Here actually the problem is Web API portal is publicly available for now (but I don't know about for what extent Web API visible to users publicly still requires or not?).
In our case Customer ----API call should be in internal communication only there no third-party vendors supply.
Is there any methods secure the cus--API.
We tried to secure cus---API azure network restrictions in Web API network settings but that not helps us (we got stuck the complete cus--API communication is blocked)
As I mentioned Web API hide from the internet then we applied Azure AD authentication for Web API.
In this case, we got results were negative
we have no prior knowledge from code level securing and communication token generation
Finally, we looking for suggestions, and suggest me what are security checks to WEB APP-API COMMUNICATING WITH CUSTOMER PORTAL. WHAT ARE SECURITY CHECKS THAT NEED FIGURE OUT?
Another big problem is really WEBAPP-API put publicly if yes then what are the ways to tighten security.
Please share ideas and suggestion it would be greatly helpful to us.
Thank you
I am looking in to how to use API gateway in my project. My current API gateway pattern idea is to create a layer of composite APIs calling multiple APIs, and expose the composite APIs through the API gateway.
Researching elsewhere, I've found that it is not recommended to create composite APIs if using an API gateway, but rather that composition should happen in the API gateway itself. But if I need to do the composition in API gateway, doesn't that mean that I need to expose some domain logic there, because would I need to construct a meaningful request contract and possibly a sequence of calling APIs? Personally, I don't feel comfortable doing that.
Is there other way to do this without exposing some logic?
From what I research, it is not recommended to create composite API if using API gateway but composition should happen in the API gateway itself.
could you refer where did you find the statement?
IMHO the service composition is not task of the api gateway. It's task of n integration layer (you don't need to have a separate esb product or service, under integration lyer you can understand any services or service layer implementing the capabilities, such as composition, transformation, etc)
You did not specify any api product or service, it depends on the product if it is capable to execute any logic or not (some do, some some don't). Even if the api gateway product is capable of executing any logic, indeed I don't recommend it either (you will have to fight with maintenance, error and state handling,..)
But if I need to do the composition in API gateway, doesn't it means that I need to expose some domain logic there
(personally, I don't feel comfortable doing that) because I need to construct a meaningful request contract and possibly sequence of calling APIs?
what do you mean by composition in API gateway? I assume under the term executing some logic. Then the logic is hidden from the api clients.
Or could it be layer of composite API sounds better?
Indeed.
Generally try to treat an api gateway as a smart proxy (doing authorization, throttling, client facing api store,..) but the exposed backend services should be already exposed as they are
I have implemented web push using Firebase using Service-workers (which works only for https website). I want to use web push notification for http website.
I have read that it is possible to implement the web push for http website using some tweaks like subscribing to any third party.
Two questions I want to ask:
a) Is it possible to achieve the same without using any third party library?
b) How can I achieve the same behaviour for my website?
Any help is appreciated.
a) Is it possible to achieve the same without using any third party library?
From the developer guide: No, During development you'll be able to use service worker through localhost. but to deploy it you need HTTPS, the site registering the service worker must on on HTTPS and the service worker, which has to be on the same origin, will be served over HTTPS as a result. For security reasons. Having modified network requests, wide open to man in the middle attacks would be really bad
b) if you need web push notifications and you don't have an SSL take a look at Pushpad Express https://pushpad.xyz/
Alright, A friend and I are developing an App where I'm developing the back-end and he is developing the front-end. The project is separated into two repositories the front-end and the back-end, and we need to implement a payment API.
Now, since we're using the REST API Concept, we communicate both ends through JSON data.
My question is, when we're making the connection to the payment API, who needs to execute that request? The front-end or the back-end?
I know it's a silly question, but first timer here.
The backend will obviously process the payment, I'm not sure which payment API you're going to use. But depending on the API you go with, the implementation will vary. But the actual processing of the payment will be processed in the backend for sure.
It completely depends on the API.
In some cases, a payment can be accomplished via a secure web service call, which would be issued by your friend's REST service. The front end will still need to collect data (e.g. payment amount and card number) and may also need to collect additional information to satisfy the API (e.g. IP address or browser signature, for risk management purposes).
In other cases, the payment is sent directly to the service from the browser. The role of your application would be to render an iFrame housing a page that is reached via SSO. The back end may need to call a service to retrieve an SSO token, or may have to compute an SSO token using a shared key.
You should probably refer to the payment API's documentation. They often have very specific guidance which you must follow carefully in order to achieve payment card (PCI-DSS) compliance. There is nothing special about "payments" that says that allows StackOverflow users to guess anything about its API.
I want to implement a Pusher client in Qt, and I was wondering what the difference is between the client API and the server API.
As they are telling on their site, clients are consumers and servers are producers (including authentication verifications).
Is it correct that a client cannot publish events, and that we always need a server to handle event distribution and authentication?
Is it correct that a client cannot publish events, and that we always need a server to handle event distribution and authentication?
Clients can publish events, but only on authenticated channels: http://pusher.com/docs/client_events
Server libraries tend to have the functionality you mention. But it is possible to have all functionality in a single library. However, this way of dividing functionality fits well with enforcing security good practice and generally with where apps want to use it.
The iOS library (libPusher) provides more than the standard client functionality e.g. you can make calls to Pusher's web API.