You can look into Bruno: https://www.usebruno.com
HN user
coronapl
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.
Give way to people crossing the street.
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.
How about blocking all tracking, ads, malicious sites and more at the DNS level? I have been using NextDNS for a while know I really like it.
Since you are hosting your blog on your personal server, I would just go with Mixpanel or postHog. They are quite easy to integrate and they enable you to track some more specific events that might be relevant for you.
If you ever decide to host your blog on a cloud provider, Cloudflare provides nice and simple analytics.
I did it in Germany. It can be quite expansive and difficult. Nowadays, I would actually consider the E-Residency from Estonia. Super interesting initiative: https://www.e-resident.gov.ee/
This is very useful! Finding GDPR-compliant tools has always been a huge challenge for us. Feedback: adding a brief description for each tool could be a nice touch.
I just created a PR with a tool that I believe would fit very nicely in the list.
I'm not sure about the exact scope of the list, but I founded a SaaS company focused on optimizing patient admissions in care facilities. Let me know if you think it makes sense to include it.
Super interesting! I can assume that it is quite complex to scrape all of the RSS feeds and build the PDF. I will make sure to play with it.
Really interesting project! A few questions:
1. How do you send the document to the Remarkable? My understanding is that Remarkable does not provide any public APIs. Do you use one of the unofficial open-source APIs? 2. Are you using pstmrk.it for tracking purposes? Maybe you can be more explicit about this in the Privacy Policy.
Additionally, the magic link email is landing in my spam inbox. I assume that this might be because you are using an icloud domain.
I'm really happy to see the SST team pushing this forward. A few months ago, I wrote about how SST is becoming a flexible framework that lets you start with a simple serverless approach and easily migrate to containers. This is my blog post in case someone is interested:
I have worked for some time with Next.js and SST / OpenNext. I think that if you are fully into the AWS ecosystem OpenNext is a great option; although you have to take into account that there may be some compatibility issues with the new features mainly. If this is a big concern, I think both Remix and Astro are a great option because of the adapters. I have been using Astro for my personal blog and I love with its simplicity. My impression is that it could be a good option even for big projects.
I agree. My point was that all software components rely on some form of abstraction. A SaaS, for example, is essentially a wrapper around a database, just as the database itself is a wrapper around OS APIs, and so on.
Isn't software itself an abstraction layer to communicate with the underlying physical components? In theory, it's possible to build a machine that solves a problem without any software at all. Isn't this what an automaton represents—hardware directly engineered to perform specific tasks without the need for software?
I agree, but I would actually say that this is a good thing. If a SaaS can effectively map a real-world problem or pain point and solve it in a simple way, the goal has been achieved. Sometimes, there’s no need to overengineer a product when it can leverage existing technologies in a smart way.