So I created schema.graphql using amplify add api command, but I said No when it offered me to generate queries, mutations and subscriptions.
Now I am wondering, how can I generate them after the fact? Or do I have to go through whole amplify add api process again?
There is an additional command that you can use to initiate the code generation.
You can run amplify configure codegen to configure it (accepting the defaults is probably fine). Anytime after you have made schema changes, you can then run amplify codegen types to re-generate your types (make sure to run an amplify push before you do so).
More info here: https://aws-amplify.github.io/docs/cli/codegen
Related
I have a simple Spring Boot REST app that uses Mongo Atlas as the database and I have a couple of environment variables to pass to the project for the connection URL. I have defined this in the src/main/resources/application.properties which is the standard Spring profile for storing such properties. Here's the property name and value.
spring.data.mongodb.uri=mongodb+srv://${mongodb.username}:${mongodb.password}#....
I use VSCode for local dev and use a launch.json file which is not committed to my github repo to pass these values and I can run this locally. I was able to deploy this app successfully to Heroku and setup these two values in the Heroku console in my App settings and it all works fine on Heroku also. I am trying to deploy the same app to GCP App Engine but I could not find an easy way to pass these values. All the help articles seem to indicate that I need to use some gcp datastore and some cloud provider specific code in my app. Or use some kind of a github action script. That seems a little bit involved and I wanted to know if there is an easy way of passing these values to the app via gcp settings (just like in Heroku) without polluting my repo with cloud provider specific code or yml files.
I would like to setup one GitHub repo which will hold all backend Google Cloud Functions. But I have 2 questions:
How can I set it up so that GCP knows that there are multiple Cloud Functions to be deployed?
If I only change code for one Cloud Functions, how can I setup so that GCP will only deploy the modified Cloud Functions, and NOT to redeployed the unchanged onces?
When saving your cloud function to a github repo just make sure to have in the gitignore file the proper settings. Exclude node_modules and such folder and files you don't want to commit.
Usualy all cloud functions are deployed trough a single index.js file. So here you need to make sure you have that and all files you import into it.
If you want to deploy a single function you can use this command:
firebase deploy --only functions:your_function_name
If you want to have a more structure solution you can read this article to learn more about it.
As I understand, you would like to store cloud functions code in GitHub, and I assume you would like to trigger deployment on some action - push or pull request. At the same time, you would like only modified cloud functions be redeployed, leaving others without redeployment.
Every cloud function is your set is (re)deployed separately, - I mean the for each of them you might need to provide plenty of specific parameters, and those parameters are different for different functions. Details of those parameters are described in the gcloud functions deploy command documentation page.
Most likely the --entry-point - the name of the cloud function as defined in source code - is to be different for each of them. Thus, you might have some kind of a "loop" through all cloud functions for deployment with different parameters (including the name, entry point, etc.).
Such "loop" (or "set") may be implemented by using Cloud Build or Terraform or both of them together or some other tool.
An example how to deploy only modified cloud functions is provided in the How can I deploy google cloud functions in CI/CD without redeploying unchanged SO question/answer. That example can be extended into an arbitrary number of cloud functions. If you don't want to use Terraform, the similar mechanism (based not he same idea) can be implemented by using pure Cloud Build.
I use AWS Amplify & GraphQL inside my iOS project. I would like to update my API.swift file based on my changed GraphQL file. The following Amplify CLI command accomplishes this, but pushes changes to the cloud...
amplify push
How can I generate an updated GraphQL file without pushing changes to the cloud?
Are you making changes to your schema or your queries/mutations? If you're making changes to your queries and mutations inside your graphql folder with the queries.graphql, mutations.graphql, and subscriptions.graphql, you can run amplify codegen types
What I want to accomplish:
I have edited an amplify + AppSync project on the AppSync web console and I want to pull it onto my local machine.
What I did:
I have initialized an amplify project with the Amplify CLI by executing three commands:
amplify init
amplify add api
amplify push
(the added api is GraphQL)
Next I edited some of the auto generated GraphQL resolvers on the AppSync web console. (I have tested the edited resolvers with a client app -> they worked)
Afterwards however, when I execute a pull in the Amplify CLI:
amplify pull
it only pulls changes made to the local files before the last Amplify CLI push command,
so any changes made to the AppSync web console are not taken into account by the Amplify CLI pull command.
Questions:
Is this expected behavior?
Is there a way to include changes made to the Web Console in the Amplify CLI pull command? (especially changed resolvers)
Versions:
amplify cli: 4.13.3
Additional Things I Discovered That Could Be Helpful:
AWS-CloudFormation also only shows updates when changes are made using the Amplify CLI.
The AWS-S3 bucket that holds the amplify projects files, also only mirrors the changes pushed using the Amplify CLI.
You can do this manually by downloading the schema file from the console and replacing /amplify/backend/api/schema.graphql then running amplify push.
There is an issue open to automate this here: https://github.com/aws-amplify/amplify-cli/issues/1220
I've spent the past few months developing a webApi solution that I'm ready to push up to Azure and hook into an Azure SQL Database. It was built with EF Code First.
I'm wondering what standard approaches there are to making changes to the database while in production. I've been using database initializers up to this point but they all blow away data and re-seed.
I have a feeling this question is too broad for a concise answer, so I'd like to ask: what terminology / processes / resources should a developer look into when designing a continuous integration workflow for a solution built with EF Code First and ASP.NET WebAPI, hosted as an Azure Service and hooked up to Azure SQL?
On the subject of database migration, there was an interesting article on ASP.NET about this subject: Strategies for Database Development and Deployment.
Also since you are using EF Code First you will be able to use Code First Migrations here for database changes. This will allow you to better manage the changes you make to the database.
I'm not sure how far you want to go with continuous integration but since you are using Azure it might be worth it to have a look at Continuous delivery to Windows Azure by using Team Foundation Service. Although it relies on TFS in the cloud it's of course also possible to configure it with for example Jenkins. However this does require a bit more work.
I use this technic:
1- Create a clone database for your development environment if it doesn't exist.
2- Make the necessary changes in your dev environment and dev
database.
3- Deploy to your staging environment.
4- If you added some static datas
that should also exist in your prod database, use a tool like
SQLDataExaminer to find the data differences and execute the
insert, update, deletes for according rows. Use Schema Compare in VS2012 to find differences between your dev
and prod environment by selecting source as dev and target as prod.
And execute the script in your prod.
5- Swap the environments