I am new to web development, and the react/next/amplify ecosystem, but I have been playing around with it and it seems great. I am just having difficulties deploying my app. It seems to be an order of operations thing I might be doing wrong with the initial configuration, I am not sure.
So I followed the 5-minute tutorial on how to set Next.js up with aws-amplify using the git based deployment (so no amplify init), I then started to follow along with the todo tutorial for aws-amplify that I had previously completed, which included the aws-exports.js file. I could not deploy it because I was getting an import error for not being able to resolve ./aws-exports, which made sense because it wasn't there. I eventually performed a amplify init and had a copy, but found this is in the .gitignore file so it still failed when I tried to deploy. I took it out of my .gitignore just to see and voila a successful build.
This seemed wrong to me because why would it be in the .gitignore if it wasn't supposed to be?
I found this post that says the info is sensitive, but the documentation says otherwise.
This file is consumed by the Amplify JavaScript library for
configuration. It contains information which is non-sensitive and only
required for external, unauthenticated actions from clients (such as
user registration or sign-in flows in the case of Auth) or for
constructing appropriate endpoint URLs after authorization has taken
place.
So, can I leave this file out of the .gitignore? Is there a better way to do this? I experienced the same issue and solved it the same way deploying to Vercel, which may be my preferred deployment method bc of the easy lambda function integration (if that matters to the answer).
Thanks for any input.
Sorry for late to the party, I don't disagree with the doc which stated that aws-exports.js is non-sensitive, if you look into that file, it just bunch endpoints and nothing really enable you to "hack" into the system, unless you didn't config your #auth directive correctly. But I understand your concerns, and I don't like the style that endpoints are being exposed to clients in a single file, but they eventually will expose to user, either from the network tab or your code where you reference the endpoint.
A good reason that you should include aws-exports.js in your .gitignore is that you don't want to deal with conflicts in git, since this file will be auto-generated during build time.
If you using server-side rendering, seems like you are by using next.js, you can easily acchive only expose what is needed for client, I won't get into it as that's another topic.
Related
I am working on a GRANDstack (GraphQL-React-Apollo-Neo4jDatabase) project and got told that it now needs an additional REST-API without making huge changes to the existing backend and GraphQL-API. And of course we have to be quick about it.
We found this (Apollo Gateway): https://medium.com/tkssharma/an-api-gateway-is-a-microservice-pattern-where-a-separate-service-is-built-to-sit-in-front-of-your-be4b16861d40
We plan on using this to set that new REST-API on top because we know we will need microservices soon enough as well. So I guess, this can be set up in some form with the already included Apollo. But I have yet to fully understand it.
Does anyone have some experience with this? Or does anyone know a project that implements this and can be checked out? I'd like more material about this that contains actual code. Especially about setting up such a gateway to put a REST-API on top.
If there is something easier and better documented than this Apollo gateway, please let me know! Open to ideas, but not complete overkills (Though we are not allowed to just put REST directly into our backend, it has to stay quite untouched).
Thank you very much!
In short: Our current backend offers GraphQL-API which works just fine. But one of our customers (in this picture "client") needs a REST-API. So we hope on using a gateway (?) which should be placed before/upon our backend in a separate docker container probably, takes in HTTP-requests from the user and then asks our backend in graphQL for the needed data.
If anyone ever stumbles upon this, we decided to do the following:
Since we have to be quick about it, we will set up another docker container, that contains a small server, which accepts data via a REST-API. Depending on the received data, it calls specific GraphQL-Queries/Mutations on our backend. Easy. No additional 3rd-party software. Simple just wins.
Have a good one!
my question starts from this article here. I followed it along, but this passage:
Security Considerations
Since these files will potentially contain secure information, such as
API_KEY, I’d recommend not checking them into version control and
instead using a secure file storage system like 1Password to contain
copies of Development.xcconfig, Staging.xcconfig and
Production.xcconfig.
makes me wonder what writer is talking about. Configs file are needed be in the app to work, I don't think I could put them aside. if someone could help I need to understand
how to handle those files in safety
how should use this config files, should I put them different (id present) endpoint based on environment? could I put there different things such images names, default values for variables etch?
I also wonder how this could be handled, putting them in some 1Password storage.
If you feel unsafe by checking in those files (why would you? Anyone who accesses the source code needs to somehow access some API using some key), you could
Handle this by .gitignore
Create a softlink from your repositiory to some outside "safe" area in your file system, protected by file system access rights
Handle those secrets by means of the keychain / secure enclave, see here
Anyhow, the biggest / only security risk I see is if you plan to publish your repository and dont't want your secrets to go public. In that case, you would replace those API keys by some text like "[enter your api key here]", which could easily be done by some awk/sed scripting.
I am looking for keeping some kind of baseline for everything applied to kubernetes(or just a namespace).
Like versioning microservices in a list and then check that in to github, in case of the need to roll something back.
Check out Velero, it is a backup tool for kubernetes. I don’t think it can use git as a backend, but you could add that (or use s3 or similar).
You can write and deploy an application that Watch the resources you are interested in, e.g. all Deployment, Service and Ingress... including all changes, and then store the changes as you want. I can recommend client-go for this kind of service.
However
Like versioning microservices in a list and then check that in to github, in case of the need to roll something back.
It is more common, and recommended to work the other way around, first save your intended desired state in Git, have an CICD service to apply your changes in the cluster or clusters. This way of working is called Infrastructure as Code. The new edition of the book Kubernetes Up&Running have a new chapter (18) that describes how to work in this way.
I'm developing an Ionic(3 / 4)(Angular 4 - 7)-Cordova / Capacitor Cross Platform Application(s). I'm interested in switching API env based on the current rollout track in the Google Play Store. For example, once an application has been successfully tested and recommended to continue staging/production. I would like to have the API env dynamically changed (e.g., using a different URI domain to connect to REST API ) dependent on the Google Play Store Track.
I'm aware that I can use Google Developer Play Store API to identify / list versions and available tracks yet, I'm unaware if there's already an implementation or solution. I'm perfectly willing to design a solution though, I figure I find out if it's been done already rather than reinvent the wheel.
I'm hoping to implement a solution either to the REST API BACKEND or in the ionic framework layer rather than an integration at the native layer for scalability per-project. The purpose of doing this would enable CI rather than rebuilding the project and change the API URI domain for every environment. Any assistance in this matter would be greatly appreciated.
So, if anyone's interested. The approach highlighted above is possible, couldn't get an answer so I just created something. Using Google Play Developer API. The process flow is as follows:
[]
For now it's a working prototype perhaps its not very efficient; I suppose it can be improved if the request was issued from a single server, or microservice. Though, I wanted to make the code recyclable and it's isolated from both the mobile application & Node Server.
If you are interested in learning more or would like to work on project. Please feel free to contact me.
I've just inherited a CF app from a customer who uses a shared CF hosting provider. I'd like to introduce better processes including the ability to stage app changes that I make for their review. (In the past, they would upload changes and cross their fingers.)
Their app lives in a folder under the webroot. Let's call it "/app". I'd like to create a sibling directory named "/appstaging" where I would publish the latest code. The obstacle is that the hosting provider lets you set paths for custom tags and mappings but not per CF app. The existing settings all point into the /app directory so if I need to make changes to tags, CFCs, etc., I can't test these without affecting the live app. What I want is CF to let me set per-app tag paths and mappings. From what I've read, CF8 lets me do this but the customer is using CF7 (I'm pushing for them to upgrade asap). In the meantime, is there anyway to workaround this or does a smooth way of staging changes have to wait?
(I am currently experimenting with ways to detect which app I am based on using GetCurrentTemplatePath() in application.cfm. The idea is that any code that refers to other files using mappings would use a different mapping. I haven't done enough work there though to know if this will all work out.)
Any ideas or input are welcome. I should point out that the app and its dev env is not very "modern." There are no frameworks involved and no things like ant used for build/deployment. The customer's budget is extremely limited so I'm not looking to convert the app whole-sale but I do need to find cheap ways to get some process in there to keep things sane.
This is a serious, but wacky, suggestion: use a second hosted account.
Write up a cost-benefit analysis of having live and staging servers, and compare that to the cost of a second hosted account. The second account doesn't need massive data allowances, etc, and ought not cost as much as the live account.
Additionally, calcuate the cost of revising the code base to allow live and staging on the one account and compare that to the cost of a second hosting account.
Remember that you wont need the second account once your real upgrade is complete.
I expect you'll need to do something like defining the custom tag paths in a config file that gets loaded into the application scope. But that'll require some serious code refitting.