Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 9 months ago.
Improve this question
I've created several RESTful microservices and dockerized them. Now I want to have a web-based UI for them and the ability to create users and grant permissions to them to use some of the APIs.
I know that I need some kind of API gateway. My first thought was that I always could do that bruteforce way: create some django app that would serve UI and proxy all request to APIs by hand, but this seems very dull. Maybe there are some alternatives? I've ready about Tyk, but can't find any information about the ability to add users and grant permissions to them.
I probably could create an application that would serve as API gateway and automate proxying of requests by writing some code that would model that. So for example I basically need a mapping between external urls to actual api urls and some authorization logic. Maybe there are already something like that?
I was looking for something similar, including support for rate limiting, UI console, etc. It boils down to a few freemium tools like:
apigee
mashape
apiary
3scale.net
and a few open source ones:
tyk
kong
ApiAxle
WSO2
API Umbrella
I've decided on tyk since it has a nice UI console and solid docs. All of them were mentioned on Quora, which is nice when you want to go shopping :)
If you like getting your hands dirty, you could quite easily implement your own simplified API Gateway. I believe this approach perfectly fits into microservice paradigm - implement simple service with limited functionality that does only one thing, but does it well.
I've written a tutorial on this subject (implementing simple API Gateway for Dockerized microservices with Node.js). My example is about 100 lines of JavaScript code, it uses node-docker-monitor to listen to Docker events and http-proxy to handle HTTP requests from the clients.
https://memz.co/api-gateway-microservices-docker-node-js/
or alternative solution with SkyDNS and Nginx
https://memz.co/reverse-proxy-nginx-docker-microservices/
Unless I'm mistaken (I'm a bit new to containers) - I think all of these solutions from Amazon AWS (with AWS API Gateway itself in front of any of them for public access) would also fall in the category of freemium solutions for running / orchestrating Docker Container(s) behind a public API Gateway:
AWS ECS - Elastic Container Service
AWS EKS - Elastic Kubernetes Service
AWS Fargate
Here are AWS blogs on using AWS API Gateway with them:
Using Amazon API Gateway with microservices deployed on Amazon ECS
API Gateway as an Ingress Controller for Amazon EKS
And depending on your requirements, either of these (also from Amazon AWS) should also meet requirements for users, accounts, permissions, authorization, etc:
AWS Identity Access Management
AWS Cognito
By the way, I don't think any intermediary management / compute / server should be necessary for architecting with any of those (although compute from AWS EC2 and/or AWS Lambda could still be inserted for any purpose), as they are all AWS services [that manage their functionality] unto themselves.
When working with .net Core webapi or other services in the .net world: Ocelot would be a choice.
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/implement-api-gateways-with-ocelot
Related
My backend is a simple dockerized Node.js express app deployed onto elastic beanstalk. It is exposed on port 80. It would be located somewhere like
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
I can call my APIs on the backend
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/hello
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/postSomeDataToMe
and they work! Yay.
The URL is not very user friendly so I was hoping to set up API gateway to allow to me simply forward API requests from
api.myapp.com/apiFamily/ to mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
so I can call api.myapp.com/apiFamily/hello or api.myapp.com/apiFamily/postMeSomeData
Unfortunately, I can't figure out (i) if I can do this (ii) how to actually do it.
Can anybody point me to a resource that explains clearly how to do this?
Thanks
Yes, you can do this. For this to happen you need two things:
a custom domain that you own and control, e.g. myapp.com.
a valid, public SSL certificate issued for that domain.
If you don't have them, and want to stay within AWS ecosystem, you can use Route53 to buy and manage your custom domain. For SSL you can use AWS ACM which will provide you with free SSL certificate for the domain.
AWS instructions on how to set it up all is:
Setting up custom domain names for REST APIs
I want to design an application using AWS as IAAS, Docker as PAAS and Spring Boot and Spring cloud as application technology.
For this, I googled and read a lot of blogs and watch videos but could not find any answer for that.
I developed one application using Spring Boot and Spring cloud technology, and the application architecture looks like below image.
This design looks good and working fine as per expectation.
Now the new task is, I need to use the cloud (AWS) as Infrastructure and Docker.
For that, I designed one more architecture, and it looks like below image.
The component as follows:
ELB - (Elastic Load Balancer) -> Target Group (Part of Auto Scaling) -> EC2 instance (will be created more on demand)
Now if I want to integrate my previous design then I think there is not need of Zuul server here because this load balancing is done by ELB, the second I do not need Service Discovery component as well because it will be done by Target AutoScale group.
I am a little bit confused here with Spring Cloud and AWS infrastructure.
Could someone help me to make really simple how I can integrate these components to work together?
Thanks
Why Spring Cloud with AWS ?
Let's take example when you need Spring Cloud even if your architecture is deployed on AWS infra :
Imagine your Product service need to communicate with your Order Service, in this case you will see Spring Cloud utility.
You don't see the necessity of Spring Cloud because you don't have an internal communication (between your services) and this is the role of Registry service.
Why Gateway service (Zuul in your architecture) ?
Again, your current architecture don't use (need) the powerful of Gateway pattern.
Let's assume your system need to aggregate multiple results from different services to response to client request. You can do this in Gateway (Zuul in your case).
Another advantage to use Gateway service is you can use it as a unified front door to your system, which allows a browser, mobile app or other user interface to consume services from multiple hosts without managing cross-origin resource sharing (CORS) and authentication for each one.
Important :
It's fine to not use Spring Cloud, is not a rule or THE right way to implement microservices architecture. If you don't need it don't use it.
I am building a web application where development teams can install and use inside their companies. I am exploring the possibility of adding SSO support with Github since it is very convenient for developers.
In Github API, Auth0, Google etc. you need to specify Callback URLs.
The problem is that since everybody can deploy an instance of my application they can host it under any valid domain or just use a local ip address. So the Callback URLs cannot be predefined.
One option is to instruct people to deploy the app under certain local domains/subdomains. However, I don't think this is a good solution.
Do you know any other options that might solve my problem?
Is SSO only suitable for apps that run under global(already known) domains?
We are running two restful apis, one with http and the other is with udp.
They are running on premise infrastructure and within next few release, we'd need run them as google container once we dockenize them
Before we put the service up in cloud and all that, we need to implement oauth!
My question is that where to start and how we should approach implementing oauth 2 considering the road map I described?
Truly appreciate any suggestions.
It kind of depends on what you want to use OAuth2 for.
One option is toThere are OAuth2 implementations for most languages (e.g. https://cwiki.apache.org/confluence/display/OLTU/Index)
This allows you to keep your own login/password system.
If you'd rather delegate the auth and identity to a provider like Google, then you just need to implement the OAuth2 dance to get a user's identity from Google, see https://developers.google.com/accounts/docs/OpenIDConnect for more details.
(and when it comes time to use container engine, visit us on IRC #google-containers if you have questions about containers and Google!)
My iOS app uses a single hard-code URL api.xyz.com to find our REST service. At the moment there are just two servers running this service, and we use Amazon Route 53 DNS. But I've found that the timeout of an hour (or more) is too long incase one of our servers fails; don't want to leave users in the dark that long.
The alternative would be to implement a failover mechanism in the app. To be honest, I don't like the idea of pulling this low level DNS-related logic in the app, but I don't see another solution at the moment.
So my question is: How do I implement such a failover mechanism on iOS? I'm using AFNetworking for my REST API.
Or, are there better alternatives on server side? At the moment the servers are individually rented ones, so no Amazon, Google, ... cloud service.