I'm searching for a possible solutions on how to control versioning of an API. Currently I have a non-versioned API using ASP.Net Core on a EC2 machine on AWS and I need to maintaing multiple versions of it simultaneously. I heard of a few options like:
Different Docker containers for each version.
A diferent proxy for each EC2 machine containing different versions.
Controller Versioning different end-points for each version.
AWS Api Gateway.
but I don't know much about this topics, and what is the best practices versioning and other options I have.
why not use API Gateway for this overall solution? You can use Staging to have more a version control for your API Gateway when deploying and testing. Also,
API GATEway allows you to approach API in a serverless approach and aspect.
If you want, you can use AWS Code Commit to keep track and build branches for a different version of your API.
AWS Code Commit
API Gateway
Related
As far as I understand, there are only three ways to access AWS resources:
Management Console (browser)
AWS CLI
AWS SDK (in various programming languages)
However, why did not AWS provide REST APIs and their reference document so that we can interact with AWS resources directly using a REST client like Postman?
I think they are using REST APIs behind the scenes (All the above three interactions actively use REST API I guess).
Thanks in advance.
There is REST API documentation available as well. Its just that AWS officially encourages the use of more abstract methods such as using CLI and SDK since its easier to use as well as they are maintained by AWS.
Also using the sdk or cli is encouraged because they are perfectly interfaced with the aws rest api with extensive testing and covering all cases. And you don't need to focus on stuff like what headers you need to attach or what should be the request body format. Users can focus on writing their own business logic.
The only source I could find for documentation of rest api are the official docs which I have linked below. Since the direct use of rest api is not preferred hence no commonly available tutorials. I don't think there is anything extra which can be accomplished using the rest api which the cli or sdk doesn't already offer.
A more practical example would be aws s3 cli. It has a lot of underlying implementation which speeds up the process of uploading and downloading, like establishing 10 network connections in parallel to utilize the complete network bandwidth etc. This you would have to implement yourself if you are directly using the api.
Some Examples:
S3 REST API
EC2 REST API
Similarly there is API documentation available for every service.
I have been thinking about building a backend with graphQL.
The aim is to make the life of the backend team easier and iterate quicker rather then have to build REST endpoints or wss actions for each dataset retreivale.
GraphQL seems to be one of solution. We are very familliar with the Lambda environement and therefore in our research we found AppSync. I looks like a perfect solution, however I have some concerened around being locked in AWS and by designing the whole architecture around AppSync.
The beauty of serverless is that with the Serverless Framework, we could redeploy all functions to another cloud provider (Azure Functions) or even dockerize the functions for a deployment onprem.
I am concerned that with AppSync there is really no alternative in either other cloud providers or to easly do this onprem. Does anybody have any experience with this? Would it be more worth it to do the work to deploy an appolo server in lambda and build the connectors/listeners to the data sources our selfs with something like this: https://github.com/michalkvasnicak/aws-lambda-graphql/tree/aws-lambda-graphql%400.13.0#design-michalkvasnicak ?
IMHO, it comes down to how exactly the client of the GraphQL endpoint will secure data. One strategy is to secure an app with Amazon identity services like IAM and Cognito. Amplify's strength is secure integration with IAM, Cognito, API Gateway, DynamoDB, S3, and AppSync. A secure GraphQL endpoint on AppSync, for example. The data hosted in each AWS cloud service can be secured with Amplify and there are many other strategies too.
The serverless framework is a break through for serverless developer operations. The framework is beautiful. I don't disagree with your concern that Amplify generated cloudformation is not portable. Cloudformation is different DevSecOps culture than the Serverless framework. Amplify's generated DevSecOps code simply lands in Cloudformation culture.
I'm awfully new to GraphQL on the cloud, FWIW. I don't have experience with Apollo on Lambda. I cried, it looked difficult to automate the security though a seasoned pro may know. I certainly hope you get to a point where you never have to throw a single line of code away. I'm not even close, yet.
An easy entry point to the AWS eco system is to use AWS Amplify.
It has documentation guidance on security, GraphQL API, etc.
We are looking at utilising aws api gateway for better management of APIs. However, at a enterprise level, what will be the best practise? Will a common API gateway for to be used by all app teams be necessary (In this case, we might need a administrator for this common API gateway which adds to overhead) or should each app team build their own API gateway and administration of their API calls?
Hope to have someone share their experiences.
I have used AWS API gateway for different web/mobile application projects. let me try to answer your questions one by one here.
Limitations Based Design
API gateway comes with limitations. You can find answers based on these limitations.
For eg: There is a soft limit on "Resources per API" and its set at 300 which can be increased up to 500 max. This means that in future, if more than 500 resources are needed, new API gateway needs to be created.
So, it's better to logically segregate the APIs and have different API gateways depending on the purpose.
Throttle limit per region across REST APIs, WebSocket APIs, and WebSocket callback APIs is limited (Soft) to 10,000 requests per second (RPS) with an additional burst capacity provided by the token bucket algorithm, using a maximum bucket capacity of 5,000 requests.
So based on traffic API gateway needs to be designed.
There are many such limitations https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html
Features Based Design
API Gateway uses OPEN API standards and facilitates XML/JSON import and export features. So if a new API Gateway is created with a swagger file from an application, its better not to mix it with other applications.
There are many features like 1)Enable API cache, 2)Enable throttling, 3) Web Application Firewall 4) Client Certificate which cannot be common for all APis in an enterprise. So again, it's better to have separate APIs based on the requirements.
AWS API Gateway is engineered with different logging mechanisms and each API gateway implementation will need a tailored approach.
SDK generation comes very handy for mobile development and again there is no use of bundling all apis into one SDk and providing access.
So my suggestion is to use multiple API gateways, for an enterprise based on specific needs.
I'm building an app and the idea is to go serverless.
I'm looking mainly at AWS and GCP (Google Cloud Platform), and as AWS costs are a bit obscure (at least for me), and there is no way to ensure not being billed, I'm going with GCP.
For the "server" part of the app, I would like to build an API on GCP as I could do with AWS API Gateway, but I couldn't find any matching product for that.
The closer one was Google Cloud Endpoint, but it seems to have a very different concept from AWS API Gateway. I've watched some videos about it (for example https://www.youtube.com/watch?v=bR9hEyZ9774), but still can't get the idea behind it or if it fits my needs.
Could someone please help clarify which GCP product would be suitable for creating an API and how it compares to AWS API Gateway?
Some link with info/example on how to do it would be really appreciated.
Google Product Manager here.
We don't have an exact analog for AWS API Gateway.
You're right about Cloud Endpoints. It's a bit of a different architecture than AWS uses -- it's a sidecar proxy that gets deployed with the backend. That's different than API Gateway, which is a fully managed proxy deployed in front of your backends.
If you are deploying in App Engine Flexible environments: good news! The Endpoints Proxy can be deployed as part of your deployment. It can do things similar to AWS API Gateway (API key validation, JWT validation, rate limiting).
We are working on some plans to allow for the proxy to be used in other places (Cloud Functions and the newer App Engine Standard runtimes).
And, finally: on our older App Engine Java and Python runtimes, we have API Frameworks that provide the same functionality. Those frameworks do the same thing as the proxy, but get expressed as code annotations and built into your app. We're moving away from the framework model in favor of the proxy model.
An example of springboot project with google cloud app engine can be found here-https://github.com/ashishkeshu/googlecloud-springboot
At the moment I am building various REST API's using AWS API Gateway, which is going great, but I am managing all these API's just through the WEB UI (Usual AWS Console ).
Is there a way, I can store all my API config in a source control ? So that I can keep track of the versions ? I don't want to just depend on API Gateway alone for these configurations, it will be great to have these API specifications in a source control.
Also I understand that API gateway supports swagger, that way I can store the swagger API specification somewhere. BUT I guess swagger won't cover all aspects of an API, For eg: if I am using mappings templates in API Gateway for talking to DynamoDB, how can I manage the mapping templates ?
Any thoughts ?
The question has been asked some time ago and I dont have a better answer
Hopefully, meanwhile, the serverless framework has improved a lot. It can support nodejs and python2.7 code and java should come.
serverless also supports Templates & Variables so so you can manage your dynamo resource from a Json or yaml file
Note: the aws-api-gateway already exists so feel free to use