In my latest online course, I cover the fundamental integration patterns you will see most often in #serverless applications.. And this isn't just point to point vs pub/sub. This course covers a range of different #patterns, and importantly, how you can actually use these patterns in #production.
I am not going anywhere. I will still be building, writing, sharing, and getting excited about the web and software engineering.
If you want to read the full story, here it is:
loige.co/farewell-ful...
Let's stay in touch!
If you ever read an issue, replied to one of the emails, shared the newsletter, or supported it in any way, thank you.
It genuinely meant a lot to me.
I think what made FullStack Bulletin special was never just the quantity of links.
It was the care behind the curation.
The digging, the reading, the filtering, the taste, and the hope that every issue might help someone discover something genuinely worth their time.
I wrote a longer post to share the story behind this decision, what the newsletter meant to me, and what still lives on beyond it.
The archive is still there. The curated feed is still there. The open source tools are still there too.
Today, I am bringing that journey to an end.
This was not an easy decision.
FullStack Bulletin has been a huge part of my life for a long time, and something I poured a lot of care, energy, and love into every single week.
Painterly illustration of a warm, softly lit desk scene with a laptop open to the FullStack Bulletin farewell page, surrounded by a coffee mug, notebooks, books, sticky notes, and scattered papers, evoking a reflective final-send moment.
For the past 9 years, I have been running a newsletter called FullStack Bulletin.
Every week, I shared some of the most interesting articles, tools, and resources I could find for full stack developers.
Over time, that became 450+ issues, 3k+ curated links, and a community of 3k readers.
LOOOL this made my day! Thanks
Thx!
It's working! :D
New blog post! I added Bluesky likes and liker avatars to my #Astro blog. No API keys, no server-side code, just pure delightful #webcomponents.
Here's how I went from "I want that" to "it's live" in about an hour:
loige.co/how-i-added-...
Thank you 🙏
PS: the way you are styling the avatars on your blog deserves an article of its own 😊
... and follow them and give them tons of likes! They are truly making the web a better place with their inspiring work 😉🙏
Huge shoutout to @lea.verou.me and @whitep4nth3r.com, two of the most awesome and inspiring builders on the web!
Lea built the `<bluesky-likes>` web components package that makes this trivially easy. Salma's implementation on her blog was the original inspiration.
Go check out both their blogs...
If you like this post, hit that like button and your avatar will show up at the bottom of the article! 😇
New blog post! I added Bluesky likes and liker avatars to my #Astro blog. No API keys, no server-side code, just pure delightful #webcomponents.
Here's how I went from "I want that" to "it's live" in about an hour:
loige.co/how-i-added-...
7/7 🎙️ So, if you are building with LLMs on AWS, or trying to turn a promising prototype into something production-ready, I think you’ll enjoy this one:
awsbites.com/153-llm-infe...
Would love to hear what Bedrock surprises you have run into so far 👀
#AWS #AmazonBedrock #LLM #AI
6/7 🧱 One of my favourite parts of the episode is the discussion around structured outputs.
Because in many real applications, the challenge is not “can the model answer?”
It is “can the model answer in a format my system can reliably use?”
5/7 ☁️ Bedrock is interesting because it gives you a more unified way to work with models inside AWS, with things like IAM, monitoring, auditing, and private networking options.
That makes a big difference when you start thinking beyond a prototype.
4/7 ⚠️ There is a lot of AI content that stops at “look, it works”.
But once you want to ship something, the questions change very quickly:
Can we trust it?
Can we keep it under control?
Can we integrate it safely?
Can we make it robust?
3/7 🔍 We get into:
• what inference actually means
• how to think about model selection
• how token pricing affects cost
• quotas and throttling surprises
• IAM and access gotchas
• why structured outputs are so important
2/7 🧠 We have been building AI-powered applications on AWS for ourselves and with customers, and along the way we picked up a decent collection of battle scars.
So this episode is not about hype.
It is about the practical stuff that shows up when you try to build something real.
AWS Bites Podcast cover art showing a bed in a grassy field with a huge rock resting on top of it, under the title ‘getting started with Amazon Bedrock.’ Eoin appears on the left behind the rock, shading his eyes, while Luciano stands on the right. The scene is warm, playful, and photorealistic.
1/7 🚀 Getting an LLM demo to work is not the hard part anymore.
The hard part is making it reliable, predictable, and affordable in production.
That’s what @eoinshanaghy and I focus on in the latest AWS Bites episode, all about LLM inference with Amazon Bedrock 👇
Very good point. I'll add that to the article! Thanks a million
Link: nodejsdesignpatterns.com/blog/nodejs-...
If you work with file paths and user input in Node.js, this one's for you.
I wrote a guide on preventing path traversal in Node.js:
✓ Why path.join() won't save you
✓ Attack vectors (double encoding, null bytes, symlinks)
✓ A safeResolve() function with detailed explanation
✓ Lots of code examples
✓ How to test it
Here's the thing about becoming a senior engineer:
It's not about writing clever code.
It's about knowing what can go wrong.
Security, edge cases, failure modes. The stuff that doesn't show up in most tutorials.
Path traversal has been one of the most exploited vulnerabilities in recent years.
Apache, Rails, popular npm packages, even Node.js itself have all been bitten by it.
Yet it's still way too easy to write vulnerable code.
The developer who wrote it had years of experience.
They just never had to think about path traversal before.
This wasn't a junior mistake. It's a knowledge gap.
Database credentials. SSH keys. Application secrets.
All accessible with a simple HTTP request.
If that doesn't sound scary, I don't know what does.
The code joined a user-provided filename with an uploads directory and served the file.
Looks safe, right?
But the input `../../etc/passwd` sailed right through `path.join()` and exposed everything.