https://serverless-stack.com/ logo
Join Slack
Powered by
Is there any guide on how to use HTTP API proxy? L...
# guide
a
Is there any guide on how to use HTTP API proxy? Looking to have something like a “public api” exposed to the front-end and then this API should talk to each individual micro-service APIs… Looking for a guide / guidance on this.
s
this is a good starting point. have you checked this out already? https://docs.serverless-stack.com/constructs/Api
a
Yeah been trying to use the Api examples from there, but not sure if my architecture pattern it’s correct or not.
s
what are you trying to do?
a
I have a React front-end, and looking to build a “BFF” for it… basically and API that can encapsulate all the calls to my backend services… I have some microservices like 
users
, 
tasks
, etc… But I don’t want to expose each individual API… I would like to expose a single API to the front-end.
s
so: front end <-> HTTP API <-> AWS services
a
I would say… frontend <-> HTTP API <-> Many HTTP APIs
Frontend <-> BFF API <-> { User API, Tasks API, Reports API }
s
this seems like a bad idea already 😉 unless the “many HTTP APIs” are third party services not owned by you
a
The thing is my APIs are micro-services which I’m thinking to have “service auth”.. that means those services are agnostic of the User itself.
Then the BFF is basically what authenticates the user, and bypass the requests to internal APIs.
s
why can’t the BFF API just make Lambda calls, or otherwise use the AWS SDK to fire off microservices directly?
a
Not sure why it’s a bad idea, it’s a really common pattern, could be called as BFF (backend for frontend) or UX API (depending who names it).
Yes, it can… but for example… I have an API with this structure..
Copy code
Tasks API
- find tasks
- create task
- etc..
This API could be called from other micro-services… That’s why it has service-authentication.
s
we have a handful of microservices, and those are accessible via the HTTP API directly. so for us, it’s: front end <-> HTTP API <-> (microservice 1, microservice 2, etc)
the HTTP API ensures the user is authenticated and has the permissions to do certain things. then it invokes other AWS services directly
a
So it’s 1 API for all the micro-services?
s
absolutely. the microservices are all invoked in different ways, because they do different things. one is a Step Function, so it’s executed directly via the SDK. others are triggered by things being pushed into an SQS queue, for example.. which the API can do
front end -> HTTP API -> AWS SDK to invoke microservice A/B/C/etc
a
My problem with that is… your API is user-based, that means a user is going to authenticate to perform actions… But what if I want to build a ETL process which consumes that API.. that process is not an actual User.
s
I’m not too familiar with what that is or how it would work. but I don’t see why it couldn’t follow a similar structure. why would a Lambda behind an HTTP API need to make another HTTP call, when it can just call a service directly?
it’s hard for me to say without getting into more details, look at diagrams, etc. but hopefully this info is somewhat helpful
a
Yes, that’s the thing… I dont want to put a lambda… I just want the gateway to proxy my requests to the internal-apis.
So there is no lambda in the middle.
Front <-> Ext API <-> { Int API 1 (+lambda), Int API 2 (+lambda) }
Yeah anyway, this is something I been doing with other platforms, and it’s pretty normal, it’s the concept of having… • UI • UX API • SYS API • INT API Mulesoft calls this API-Led connectivity.
The intention is to create abstractions on every layer of the architecture.
s
ok. this makes sense.. if API just means a service of some kind, and not an HTTP-based API. AWS affords you the ability to avoid chaining HTTP calls by calling services via the SDK
a
Yes, that makes sense for internal usage.. because I’m building my infrastructure with the AWS SDK…. but if want to re-use any of those components, I don’t want to stick to the SDK.
s
you mean, accessible by a third-party? someone who wouldn’t be coming through your mobile app or web app?
a
Yes, or another app to extract information, for example.
I would like to hit the APIs directly, without any SDK.
s
ah.. yeah, then in that case I’d have an HTTP API for your microservices that third parties can use, but then for your internal use, use the AWS SDK to fire off those services (it’ll probably be faster and more efficient)
a
Having HTTP-APIS on each service, gives me that flexibility.
Yes, I agree that internally the SDK would be more efficient.
But is not that universal or portable.
s
you mean if you want to leave AWS and go to another cloud provider?
a
No that far… just flexible in the way that… it’s HTTP, everything supports HTTP… and I don’t need to code any SDK to use it.
I can just open Postman and “get all tasks”, no SDK required.
Having HTTP APIs gives a lot of flexibility, in my opinion.
s
well, going back to your original question, I’m not sure how much it involves Serverless Stack spceifically. but there’s this article: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-http.html
a
Yeah been looking into that.
But doesn’t have much honestly, haha.
But thank you! good brainstorming 🙂
Going to keep thinking on this.
s
Good luck!
s
Hey guys, helpful discussion here. Had to solve similar issue in my app and end up going with graphql appsync as BFF. But for you usecase @Adrián Mouly I think sst recently add support for http proxy to a public endpoint that Sam mentioned. Here in doc: https://docs.serverless-stack.com/constructs/Api#configuring-http-proxy-routes. Haven't tried it out yet though.
a
Thanks @Sione, yes, this is what I been looking, that’s why I’ve sent the message above… I’m still not sure how to use it properly, still doing some tests.
f
@Adrián Mouly, while I’m not too sure about ur specific use case.. I wanted to chime in and share the most common use case of the HTTP Proxy integration I’ve come across
I’ve seen ppl having a traditional API (ie. Rails) running on EC2/Beanstalk or externally. And it’s cumbersome for them to implement ie. IAM/JWT authorization
So they’d go create an HTTP Api, setup authorization, and simply proxy requests to their existing API
That’s the use case for HTTP Proxy I had in mind for FWIW 😁
a
Yeah that makes sense, thanks for sharing.
p
Or you work for a company who has microservices and its like working with 3rd party vendors for every... single... one... of them... 😬. Interested in this topic as this is what I've been planning. UI => HTTP Api => we have every service written in... you name it language... except for Rust... would be cool if we had someone build something in Rust 🙂. Since I control the Http Api (with awesome SST) it allows me to control auth / permissions and how the front end filters / queries / gets data which moves the business logic to the lambda layer. Front end has a nice clean/consistant way of always getting stuff. I'm guessing I"m going to take a hit on response time but hey... thats what animations are for right!... right! aw 😞. I went down the route of AppSync as this is pretty close to that? But I was already putting all new things on my team so I figured we would skip that one... plus we don't have mobile so payload size is meh... (I know I should care...) Make sure you are connecting to your microservices with internal http! I noobed that up and was doing external (even though we shared the same VPC) for... 40 million-ish transactions... this is fine...
a
@Patrick Young how I ensure if I’m doing “internal http” call?
That’s one of my concerns, due I don’t have a way to create private-apis at the moment.
I was thinking just hit the API with authentication, from 
Service1
to 
Service2
.
p
I found out because someone noticed the bill higher than normal 😆. I'm pretty foggy on how it was actually setup so hopefully someone can verify but I believe if you setup each service in the same VPC you can configure api gateway to not actually leave the VPC using private api gateway?
a
Yeah documentation is not good on this topic.
Open in Slack
PreviousNext
Powered by