Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new lambda to get stripe setup intent ids for the client side #2111

Merged
merged 43 commits into from
Oct 24, 2019

Conversation

johnduffell
Copy link
Member

@johnduffell johnduffell commented Oct 4, 2019

This PR is open but I need to self review it before it really makes sense. Feel free to review now or wait until it's tidied up and I've added my own comments.

Why are you doing this?

This is part of the programme to get stripe SCA support up and running.
This is step 1 from https://stripe.com/docs/payments/cards/saving-cards-after-payment

This is implemented as a lambda as serverless is a good thing for us to move towards where sensible, and this functionality has nothing to do with support frontend play app, and doesn't need access to most of the secrets and libraries that support-frontend has.
This is created as an independent lambda from the support-workers jar, as support workers already has a lot of dependencies and the startup time is 7+ seconds on a 51MB jar. This jar comes out at 40+M which is mostly down to the aws s3 sdk library, but there is a lot of huge DLLs for gitapi for some bizarre reason https://github.com/luben/zstd-jni
Keeping things in a big mono-jar is not really a sustainable way to create lambdas for other uses so I have teased apart those dependencies that we really need and tried to structure things so that the dependencies are more reasonable. Hopefully this would be a more sustainable way if we want to make more use of lambdas in future.
This has required a bit of restructuring but hopefully I've got the essential without going overboard.

TODO

  • test on code - DONE
  • add unit tests
  • upload stripe live key mappings - DONE
  • consider adding a health check or similar
  • alarms needed - DONE

Trello Card

@@ -49,7 +49,9 @@ lazy val commonSettings = Seq(
"scm:git:[email protected]:guardian/support-frontend.git"
)),
// https://www.scala-sbt.org/1.x/docs/Cached-Resolution.html
updateOptions := updateOptions.value.withCachedResolution(true)
updateOptions := updateOptions.value.withCachedResolution(true),
dependencyStats / aggregate := false,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this command is useful to see what the jar size will be.

@@ -1,7 +1,7 @@

object LibraryVersions {
val circeVersion = "0.11.1"
val awsClientVersion = "1.11.226"
val awsClientVersion = "1.11.642"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just bumping an old version

@@ -25,7 +25,7 @@ addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "0.3.3")
addSbtPlugin("net.vonbuchholtz" % "sbt-dependency-check" % "0.2.0")

// dependency tracker plugin - needed for snyk cli integration
addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.9.0")
addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.10.0-RC1")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are on sbt1.3.2 now but there are bugs with its interaction with this plugin. this version of sbt dependency graph will appear to work rather than crash sbt/sbt-dependency-graph#178 (comment)
however it doesn't always produce the right result coursier/coursier#1375
so we will need another version bump at some point, but this is just a small helper tool rather than something from the build itself.
Another option is just to remove it, and people can add it to their local ~/.sbt, plugins.sbt file if they like to use it.

It is a separate jar from the support-workers jar because the unused
code would add to be loaded on every single step of the functions.
Hopefully we can be a bit more cohesive and minimise dependencies if
we separate things better.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this turned out to be harder than expected, for example because pulling in support-models pulls in acquisition-event-producer which pulls in various thrift stuff including a 3.6mb binaries of compression algorithm used by capi. I think sometimes pulling in a "com.gu" library can get more than we bargained for as we are not always disciplined at not adding dependencies that not everyone would need. Client side devs have some nice tooling so every import shows the size in KB of the file in the IDE, but server side we have no idea.

DomainName: stripe-intent-code.support.guardianapis.com
StripeConfig: test
PROD:
DomainName: stripe-intent.support.guardianapis.com
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we (@tomrf1 @JoemG ) had a very brief discussion about appropriate host names for prod/code as they are making a similar style lambda. We have the existing code.support.dev-guardianapis.com convention but no certificate so this one is a bit easier. But now would be a good time for objections. These conventions are also present in support-service-lambdas repo.

RestApiId: !Ref ServerlessRestApi # auto generated by the Transform
DomainName: !Ref DomainName
Stage: !Sub Prod
DependsOn: ServerlessRestApiProdStage # auto generated by the Transform
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a hack based on the predicted names of the low level resources. AWS are working on proper support for custom domain names, at which point we can feel free to switch over to that aws/serverless-application-model#783




object ManualTest {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be somewhere else?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably shouldn't exist at all, I think maybe an it:test would make more sense, as then we can check assertions.

@@ -44,7 +45,7 @@ export type ReferrerAcquisitionData = {|
abTests: ?AcquisitionABTest[],
// these aren't in the referrer acquisition data model on frontend, but they're convenient to include
// as we want to include query parameters in the acquisition event to e.g. facilitate off-platform tracking
queryParameters: ?AcquisitionQueryParameters,
queryParameters: AcquisitionQueryParameters,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure how this change relates to this PR?

@alexflav23 alexflav23 force-pushed the stripe-intent-lambda branch from c309706 to 35f0a1f Compare October 24, 2019 15:38
@alexflav23 alexflav23 merged commit f944439 into master Oct 24, 2019
@alexflav23 alexflav23 deleted the stripe-intent-lambda branch October 24, 2019 16:05
@prout-bot
Copy link

Seen on PROD (created by @johnduffell and merged by @alexflav23 10 minutes and 11 seconds ago)

Sentry Release: support-client-side, support

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants