Reading so many contrary positions about which model is better or worse shows how difficult it is to measure intelligence based on personal experiences. Of course, benchmarks try to make the process as objective as possible, but they often don't correlate with our personal experiences.
The other day 4.6 was fantastic for x task. Today, 4.6 overengineered everything and I had to revert all my changes. When evaluating models, perhaps it makes sense to consider luck as an ingredient before reaching any personal conclusion.
I refer to the technical constraints of the on-promises model which affects the modernization of the healthcare sector in the DACH regions. There is a need for integrating with SaaS products for several use cases or having AI features. Both things are not easily possible will a fully isolated setup. Therefore, I have experienced that IT departments are becoming more open to adopting Saas solutions compared to a few years ago, where it was not rare for a solution to be immediately rejected because it was using a hyperscaler.
I very much agree with the fact that IT departments have a massive influence during the sale process. Though, based on my experience, things are slightly softening. We entered the DACH market in 2023 with a cloud based CRM for the care sector. Before that, it was pretty much inconceivable in the care sector to use anything that wasn’t installed on-promises and fully isolated from the internet. Nevertheless, companies are quickly realizing that this is not scalable anymore. There is an urgency for modernizing work tools which is simply not possible with the limitations of the on-promises software era. Additionally, things like C5 seem to give a lot of confidence to IT departments for speeding up the sales process.
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.
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.
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?
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.
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).”
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.
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.
What a nice idea! A few questions out of curiosity:
* Do you plan to somehow collaborate with local post offices/companies/partners in order to avoid long-distance trips and increase the efficiency of the delivery?
* How will the delivery fee be calculated? Will it be roughly fixed or will it increase according to the distance/remoteness?
Even with the price reduction, I am still considering PostHog. I think it makes sense to leverage many of the features that PostHog is offering instead of using Mixpanel + a separate product for handling surveys or feature flags. What makes feel skeptical is the migration effort. I need to do some research about this.
Mixpanel user here! Actually, a few weeks ago Mixpanel updated their pricing plan and now it is way more affordable. I assume that is related to the recent success of PostHog. Nevertheless, PostHog seems to be a super attractive alternative as it offers way more features: surveys, product tours, error tracking and more.