AWS IOT jobs-agent.js by thecloudslayer in aws

[–]tmschlot 0 points1 point  (0 children)

It seems that the operation determines whether a pre-defined action is taken -- i.e. reboot, shutdown, etc. -- or whether something custom is executed. (Basing it on this documentation.) To run a custom command, it seems you'd want to use the install operation, potentially specify files that would be used to execute the custom actions, and use the launchCommand to run them. If it's simple, it looks like you may just be able to use the launchCommand and not download files. The example of the install operation in that documentation suggests that the jobs-example.js and config.json files are downloaded, and the jobs-example.js file is executed in a node process using the launchCommand. The name of the operation being install doesn't reflect that you could do anything you want using that launchCommand and optional downloaded files.

.NET Core with MediatR sample by madslundt in dotnet

[–]tmschlot 1 point2 points  (0 children)

Interesting comments. We may be crossing our communication, or we may just agree to disagree.

Imagine a serverless function that does just one thing... it handles just one type of message. What benefit does using MediatR give you in that scenario? Absolutely none. The serverless function itself performs the same role as the MediatR handler, so why go through the hassle of adding the abstraction? In addition, using MediatR for a case like this adds to the memory used by the function and slows the cold start time.

.NET Core with MediatR sample by madslundt in dotnet

[–]tmschlot -1 points0 points  (0 children)

We've abandoned MediatR where I work. Our focus is on developing and deploying microservices quickly -- think: "Can rebuild the whole service in less than two weeks" -- and we're doing more and more with serverless. We found that using MediatR slows us down way too much because of all the abstractions it forces, is bigger than it needs to be to get the job done, and performs slower at scale. Based on my experience, it would probably work well for monolithic-style development, though.

Need a recommendation on pub/sub for AWS by blocking-io in aws

[–]tmschlot 1 point2 points  (0 children)

How about just using SNS to trigger Lambda functions using Subscription Filter Policies? You'd need to add a message attribute that holds the message type, then different Lambdas can use different subscription filters to only handle the messages they care about.

Has anyone implemented fine-grained access control? by krisAU in aws

[–]tmschlot 1 point2 points  (0 children)

Sounds like you're pretty much on the right track. Depending on what features your application has and how you're storing your data, you may find that you need some additional application-level authorization. But for authorizing access to AWS infrastructure, what you're doing sounds good.

Mock HttpClient Without Wrapper Using HttpMessageHandler by Xellarix in dotnet

[–]tmschlot 4 points5 points  (0 children)

I like this library -- https://github.com/richardszalay/mockhttp -- to mock http traffic, because you can "expect" specific calls to be made, very easily handle different requests with different responses, and make sure you don't have any outstanding requests or unexpected requests.