My company has been using AWS Lambda for many years to run our Spring Boot REST API. We are migrating to GCP and they want me to deploy our code to GCF the same way we were with AWS Lambda, but I am not sure that GCF works that way.
According to Google Cloud Functions are only good for Single Endpoints and can only work as a web server using the functions framework.
Spring has a document that uses the GcfJarLauncher, but that is still in alpha and I can only get it to work for a single endpoint. Any additional functions I put into the code are ignored and every endpoint triggers the same function.
There were some posts here on SO that talked about using Functional Beans to map to multiple functions, but I couldn't fully get it working and my boss isn't interested in that.
I've also read of people putting the endpoint in the request payload and then mapping to the proper function, but we are not interested in doing that either.
TLDR/Conclusion:
Is it even possible to deploy our app to GCF or do we need to use Cloud Run (as Google suggests in my first link)?
Related
I understand you can use the AWS API Gateway to allow developers to create applications that interact with AWS backend services (e.g. DynamoDB).
The basic flow is:
Create the resource (e.g. DynamoDB table)
Create a Lambda function
Create an HTTP API
Create Routes
Create an integration
Attach integration to routes
But what are the options for the API? What kind of operations can be done on DynamoDB (or whatever resource you’re working with)?
Usually when a REST API is available through a Gateway there is a set of endpoints, so the developers know what they can build with the API. Like Swagger Documentation.
It would be great to know all the things that can be done via API to DynamoDB, S3, Cloudwatch, etc. is there a master list somewhere?
Or is the idea that you can do anything inside the Lambda function that is supported by the aws-sdk?
In that case, is there a list of available options for the aws-sdk?
Am I thinking about this the right way?
I'm building a graphql gateway service, which merge multiple services into one graph, using Apollo/Node/Express and following the Apollo Federation model. Initially, most of the services I'll be connecting to are REST services.
In all of the examples I find (e.g. here), I see that the gateway project runs multiple instances of ApolloServer, one for every REST service plus one more for the gateway itself, and runs them all using a package like concurrently. Basically the gateway project runs n+1 ApolloServers. Having all of these servers running seems strange to me, but I'm pretty new to this whole ecosystem.
I'm not clear if this is just for demonstration purposes, or is this also how it's implemented and deployed in the real world?
I hope that those were just examples, and are not the expected pattern.
If you need multiple GraphQL Services, each one of those would be served as a separate Domain Graph application, as its own project. Then an additional service (the gateway) would consume all of those applications and expose a single unified GraphQL API.
I have a simple question: is there a way/program/method to create unit tests to test the API Url generated on AWS AppSync to verify the validity of created GraphQL schemas, queries, mutations, etc?
There is an open-source AppSync Serverless plugin which has offline emulator support. You may find it useful: https://github.com/sid88in/serverless-appsync-plugin#offline-support
Another good recommendation is to have two separate AppSync APIs. One API is hosting you production traffic. The other is to test changes before they go to production. This is significantly easier if you use Cloudformation (highly recommended) to manage your infrastructure.
If you want to validate your API is working periodically (every minute or so), you could create a canary like the following:
Create a Lambda function which runs on a schedule. This lambda function will make various GraphQL requests. It can emit success/failure metrics to CloudWatch.
Setup a CloudWatch alarm so you can be notified if your success/failure metric is out of the ordinary.
For the canary use-case see:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/RunLambdaSchedule.html
https://docs.aws.amazon.com/lambda/latest/dg/with-scheduled-events.html
There is also amplify amplify-appsync-simulator package that is supposed to help with testing appsync, but there is no documentation on how you should use it. It is used by serverless-appsync-simulator Michael wrote and Amplify itself.
I have been studying microservices and serverless solutions and am playing with an angular frontend hosted on S3 and Lambda functions that talk to various DynamoDb tables via the API gateway on AWS.
Every example and video I read/watch uses a simple CRUD microservices as part of a simple 'todo' application or similar. My problem is where does the business logic sit? If I'm building a complex application I don't want all my business logic in my frontend Angular application. Or do I? I could build an Application API which in turn calls CRUD microservices but that feels like a monolithic approach.
I appreciate there may not be a definitive answer but can anybody advise a novice on best practice?
There are several best practices I follow in designing Serverless Microservices
Start with only few Microservices (Less the better up front, unless you know exactly how the service separation should be, delaying the decision to split)
Separate your business logic that goes to the API, and use the handler as a controller in MVC to invoke the business logic. (This will also helps to unit test logic without depending on Lambda).
Its not necessary to write only simple CRUD in your API. It depends on your domain and Business Logic required. (But don't build another monolith without separating the code in to different services. Several AWS Service limits will also give you some guide on how much endpoints should be there in a service & etc.)
Apply the design patterns available for Microservices (e.g If you want to sync data bases between each Microservice, use Pub-Sub pattern using SNS, DynamoDB Streams and Lambda)
Use the Angular App to put most of the presentation logic.
Use CloudFront as a proxy and a CDN to avoid CORs.
If you need more information you can refer the following articles I have written on this.
Deploying Angular/React Apps in AWS
Full Stack Serverless Web Apps with AWS
Note: You can use the CloudFormation in Deploying Angular/React Apps in AWS to automate the creation of S3 and CloudFront with best practices.
I am planning to launch container cluster from an SDK/API. Presently, I am fine with any language, but I prefer NodeJS SDK. As far as I have seen, I could not find any Container engine SDK. Here is the NodeJS SDK for GCP which does not contain container engine. In fact it contains SDK only for very few GCP services.
I came across OAuth API for container engine but it involves human intervention to launch it. I am looking for service account based authentication for the SDK.
Are there container engine SDKs available ?
Update after discussion with Robert Lacok:
This is the code I tried to use for container APIs with API-key, it does not work. It expects Oauth 2 token, or some other credentials other than Service account. I tried API-key it didnt work. I dont know how to use Service account authentication with the API.
Here is my source code:
Here is the error:
I see a method for Application Default credentials. But I dont think so it will be useful for my use-case. I am trying to create container cluster from AWS Lambda. So, I cant use application default credentials. Is there any other options ?
The API for Google Container Engine is very limited at the moment as all the features are in Alpha status and because they can change not many people are incorporating them into the SDKs they are developing.
These are the current available APIs: https://cloud.google.com/sdk/gcloud/reference/container/
And here is the Alpha APIs: https://cloud.google.com/sdk/gcloud/reference/alpha/container/
What you probably want to do is making calls to the REST API and using the client library for OAuth2 authentication.
You can browse the API documentation and see that every method has a short how-to for a number of languages, NODE.JS being one of them. Have a look here for an example on how to create a container cluster.
You also mentioned service account authentication. The preferred way to do this is to use the application default credentials, you can have a little read about them here.
In short, you want to set an environment variable GOOGLE_APPLICATION_CREDENTIALS=/path/to/key.json which is a key to service account you generated in console.
Then the client library will take care of the rest (getting the OAuth tokens and what not).