Posts tagged "amazonka":
11 Nov 2020
Combining Amazonka and Conduit
Combining amazonka and conduit turned out to be easier than I had expected.
Here's an SNS sink I put together today
snsSink :: (MonadAWS m, MonadIO m) => T.Text -> C.ConduitT Value C.Void m () snsSink topic = do C.await >>= \case Nothing -> pure () Just msg -> do _ <- C.lift $ publishSNS topic (TL.toStrict $ TL.decodeUtf8 $ encode msg) snsSink topic
Putting it to use can be done with something like
foo = do ... awsEnv <- newEnv Discover runAWSCond awsEnv $ <source producing Value> .| snsSink topicArn where runAWSCond awsEnv = runResourceT . runAWS awsEnv . within Frankfurt . C.runConduit
10 Feb 2019
Using stack to get around upstream bugs
Recently I bumped into a bug in amazonka.1 I can't really sit around waiting for Amazon to fix it, and then for amazonka to use the fixed documentation to generate the code and make another release.
stack contains features that make it fairly simple to work around this
bug until it's properly fixed. Here's how.
- Put the upstream code in a git repository of your own. In my case I simply forked the amazonka repository on github (my fork is here).
- Fix the bug and commit the change. My change to amazonka-codepipeline was simply to remove the missing fields – it was easier than trying to make them optional (i.e. wrapping them in =Maybe=s).
slackto use the code from your modified git repository. In my case I added the following to my
extra-deps: - github: magthe/amazonka commit: 1543b65e3a8b692aa9038ada68aaed9967752983 subdirs: - amazonka-codepipeline
The guilty party is Amazon, not amazonka, though I was a little surprised that there doesn't seem to be any established way to modify the Amazon API documentation before it's used to autogenerate the Haskell code.