This article is a translation of https://masutaka.net/2025-07-20-1/.
For casual information gathering, I've been running a serverless application called masutaka-feed since 2020.
masutaka
/
masutaka-feed
Notify my feeds of github and hatebu to mastodon and pushover
- Post GitHub private feeds1 to Mastodon
- Star and follow notifications are also sent to Pushover
- Post Hatena Bookmark favorites feeds2 to Mastodon
These are pieces of information that aren't worth subscribing to seriously with a feed reader, but I want to keep them in my field of view.
※ Mastodon posts are made to the private account @masutakafeed@mstdn.love
TOC
- Previous Architecture Diagram
- Current Architecture Diagram
- Current Architecture
- After the migration
- Implemented with Claude Code
- Conclusion
Previous Architecture Diagram
Previously, I used IFTTT's RSS Feed Integration to detect new items and call Lambda functions via API Gateway.
However, starting in 2024, RSS Feed Integration became available only with paid IFTTT Pro, so I was reluctantly paying the annual fee of $34.99
.
GitHub:
Hatena Bookmark:
Current Architecture Diagram
Since I wasn't using IFTTT anywhere else, I really didn't want to continue paying the annual $34.99
, so I completely migrated to an AWS serverless architecture this time.
The architecture uses EventBridge Scheduler to periodically check feeds and DynamoDB for read state management. Dependencies on external services have been eliminated, and processing is now completed entirely within AWS.
GitHub:
Hatena Bookmark:
Current Architecture
In the new architecture, the following components work together:
Periodic execution with EventBridge Scheduler
GitHub private feeds are checked every 5 minutes, and Hatena Bookmark favorites feeds every 15 minutes, executing the Lambda Subscriber functions shown below.
Lambda function responsibility separation
Each feed is separated into 2 Lambda functions:
- Subscriber function: Feed retrieval and new item detection
- Retrieve RSS/Atom feeds and parse with rss-parser
- Manage read state with DynamoDB
- Call Notifier function if there are new items
- Notifier function: Execute notification processing
- Filtering processing (GitHub only notifies specific events)
- Post to Mastodon
- Send notifications to Pushover (GitHub only)
Duplicate prevention with DynamoDB
- Create tables for each feed
- GitHub:
masutaka-feed-github-state
- Hatena Bookmark:
masutaka-feed-hatebu-state
- GitHub:
- Set partition keys
- GitHub: Atom feed, each
entry
'sid
- Hatena Bookmark: RSS 1.0 feed, each
item
'srdf:about
- GitHub: Atom feed, each
- Set TTL to automatically delete old records after 30 days
Configuration management with SAM continues
As before, I use AWS SAM to manage the configuration of added components.
Environment variables continue to be managed with GitHub Actions Secrets/Variables, and automatic deployment occurs when commits are added to the main branch.
After the migration
- Despite increased responsibilities, the code became unexpectedly cleaner
- rss-parser was more convenient than expected - by just defining feed types like GitHubFeedItem and HatebuFeedItem, parsing became simple
- As a result, I was able to abandon HTML extraction using regular expressions
- No longer need to pay IFTTT Pro's annual
$34.99
- AWS costs stay within the free tier
- Running error-free for about 2 weeks
Implemented with Claude Code
After starting to pay for IFTTT Pro, I had the concept in my head, but since it was essentially refactoring, I couldn't get motivated and left it alone.
Claude Code helped me overcome that lack of motivation, and I made great use of it.
- Migration from JavaScript to TypeScript
- Migration from IFTTT Pro to AWS self-implementation
💡 Each commit message in the pull requests contains Claude Code prompts.
Resource definitions in template.yaml are tedious to research, but Claude Code wrote them in one shot. Of course, I verified them afterwards.
- EventBridge Schedulers definition
- DynamoDB Tables definition
- IAM Role settings for each resource
- CloudWatch Alarm monitoring definitions
Conclusion
By self-implementing IFTTT Pro's feed notification feature with AWS serverless architecture, I was able to gain the following benefits:
- Cost reduction: Annual fixed cost of
$34.99
became essentially zero - Transparency gained: Full control over what items are added to feeds and what items have been marked as read
- Enhanced monitoring: Can set up monitoring for feed subscriptions and detect failures immediately
- Code optimization: Optimized feed parsing using rss-parser
Additionally, by utilizing Claude Code, I was able to significantly lower the motivation barrier for tasks like migrating from JavaScript to TypeScript and creating SAM templates.
I will continue to operate masutaka-feed at a low altitude going forward.
Top comments (0)