I come from Mexico, where millions of people walk and take public transport every day. Unfortunately, poor infrastructure and our mobility culture hurt pedestrians the most. Sometimes people have to wait several minutes just to cross a street. Years ago, a teacher told me that giving way to pedestrians was a simple action to make the world better. It makes a real difference for those who don't have the privilege of being in a car. This stuck with me, and I try to do it whenever possible. It might not apply everywhere with better infrastructure, but I find it to be a small yet meaningful action.
I’ve used SST, Pulumi, CDK, and Terraform. I decided to stick with SST because it offers a far superior development experience. Sure, I could write IAM policies with plain CDK, but it’s more error-prone and harder to maintain. Features like linking and live lambdas just make development so much easier.
I actually think this project makes a lot of sense. It lets you get started in minutes without dealing with unnecessary details. Furthermore, you can always access the low-level Pulumi component and override whatever you need. Keep doing what you’re doing! Your project makes IaC more accessible to everyone, and that’s a good thing. I’ll be happy to try it.
Just came across SST the other day and it looks very interesting. It looks like it's based on Pulumi, so it begs the question for me of why does it exist? Structurally it doesn't seem to be that different in capabilities. Perhaps it is more that it is a more opinionated subset that has better ergonomics. Is that correct, or is the reason different for you?
We have a handful of legacy SST Lambdas at work. We literally just use it to build a ZIP which we publish to an S3 Bucket, not much different than publishing an ECR image. It’s all Terraform from there.
Curious why you’d go from sst (back?) to terraform? Are there services or features missing in sst or is it about terraforms ergonomics that fits your case better?
Terraform in combination with Claude Code is actually quiet managable. Yes it generates much code, but you have great detail of what is actually going on, there is no hidden abstraction layers on top.
I'm glad to see useful features like easily adding userId and sessionId to logs. That said, I wish it wasn't limited to just these properties. From my experience building enterprise SaaS, you need more metadata for proper filtering: tenantId, operation, and others. With Winston, I typically create child logger instances and pass them around to ensure all logs contain the right metadata, but that workflow is pretty annoying.
Quick question out of curiosity: why does the example include an API key when initializing the logger? I couldn't find an explanation on the GitHub page. Some people might be put off seeing that in the first example, thinking the logger requires a paid subscription.
Agree! In fact, I would appreciate more well written articles explaining basic concepts on the front page of Hacker News. It is always good to revisit some basic concepts, but it is even better to relearn them. I am surprised by how often I realize that my definition of a concept is wrong or just superficial.
While queues definitely play an important role in microservices architecture, I think it’s worth clarifying that they’re not unique to it. A queue can fit perfectly in a monolith depending on the use case. I regularly use queues for handling critical operations that might require retrying, for having better visibility into failed jobs, ensuring FIFO guarantees, and more. Queues are such a useful tool for building any resilient architecture that framing them as primarily a microservices concern might cause unnecessary confusion.
I work on PeopleSoft Enterprise Resource Planning applications - the "boring" back-office HR, Pay, Financials, Planning etc stuff.
The core architecture is late 80s - mid 90s. Couple of big architectural changes when internet/browsers and then mobile really hit. But fundamentally it's a very legacy / old school application. Lots of COBOL, if that helps calibrate :->
We use queues pervasively. It's PeopleSoft's preferred integration method for other external applications, but over the years a large number of internal plumbing is now via queues as well. PeopleSoft Integration Broker is kind of like an internal proprietary ESB. So understanding queues and messaging is key to my PeopleSoft Administrator teams wherever I go (basically sysadmins in service of PeopleSoft application:).
Recently, I also started using queues for integrating with legacy health care applications. Most of them run on-promise and they don't have incoming internet connection for security reasons. The strategy is to send a message to a queue. The consumer application uses short polling to process the messages and then it can call a webhook to share the status of the job. Do you also follow a similar approach?
If I understand it correctly, no; PeopleSoft is Legacy in some ways but it is actively developed and improved/maintained. The Peoplesoft Integration Broker is "modern-ish" from that perspective, and a proper middleware messaging system:
It'll do XML messages in somewhat proprietary format with other PeopleSoft applications, and "near-real-time" queues via web services with other applications in a fairly standardized way (WSDL etc). I think of PeopleSoft Integration Broker as a "mini, proprietary ESB", as inaccurate as it may be in details :).
Monoliths also have to scale to multiple servers eventually, so message queues are an important architectural component to understand regardless of the organization of your services.
No one specified external message queue. You can have a message queue within the process itself that can deliver messages from one thread to another. There are different kinds of messages queues for this purpose depending on how many threads will be producing messages to the message queue and how many threads will be consuming messages from it. While using message queues may not be neccessary for multithreading it is a very common setup. The ability to have a message queue to schedule work on a background thread is very common between many programs.
The analogy could be: “Queues are the like the todos list of your team. The todo item (message) stays there until it is successfully completed. It can be handled by the producer (monolith) or it can be handled by someone else (microservices).”
We recently added an Astro Starlight site to our monorepo, and it’s been great. Whenever someone makes a significant change, the PR includes the corresponding docs update, which makes reviews much more complete.
Another benefit: since the docs live in the repo, they’re easy to feed into AI tools.You just drop the relevant Markdown files in as context. This workflow has worked really well for us.
The only real headache was adding auth to our Wiki, but we eventually found a simple solution.
I’m really curious to see how Dia will evolve toward being enterprise-ready. The Arc vision was sadly killed, and I assume the same might happen with Dia. Rather than competing with Claude for Chrome or Gemini in Chrome, it seems more likely it will become a conservative, secure AI browser tightly integrated into the Atlassian ecosystem.
That’s the paradox of Next.js: it can feel extremely simple and extremely complex at the same time. For a small hobby project hosted on Vercel, I’d recommend it. For building a full SaaS product, I often regret it.
I’ve run into this myself. I tried middleware, AsyncLocalStorage, even wrapping layouts and pages in HOCs. After plenty of research, it still feels over-engineered for such a trivial task. Ironically, my understanding is that Next.js on Vercel already provides a requestId by default.
Another recurring issue is the documentation. The moment you hit anything even slightly advanced, it becomes too simplified to be useful, and the only guidance you find is a handful of open GitHub issues.
I come from Mexico, where millions of people walk and take public transport every day. Unfortunately, poor infrastructure and our mobility culture hurt pedestrians the most. Sometimes people have to wait several minutes just to cross a street. Years ago, a teacher told me that giving way to pedestrians was a simple action to make the world better. It makes a real difference for those who don't have the privilege of being in a car. This stuck with me, and I try to do it whenever possible. It might not apply everywhere with better infrastructure, but I find it to be a small yet meaningful action.