There are several alternatives. Most of them, including mailcatcher, seem to be unmaintained.

Mailpit is an alternative that has regular updates: https://mailpit.axllent.org/

> Most of them, including mailcatcher, seem to be unmaintained.

MailCatcher is great. It "just works" and has Docker images for both AMD64 and ARM64 CPUs.

Thanks for the link - we’ve been using mailhog for local smtp testing and it still works ok for basic tasks, but it’s not maintained any more.

I was using Grammarly for a long time, but a while ago I made a wrapper around the OpenAI API to fix grammar and style and highlight the changes.

- Demo: https://refiner.roman.pt/. - Source: https://github.com/imankulov/refiner.

For me it works better than Grammarly.

In my experience, the "Citadel pattern" is a good alternative to microservices for small to medium teams. I have seen it emerged as a natural evolution of a monolith in several places where I worked, where it served us well.

https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Hackbraten is right. When I talk about dicts, I refer to a specific Python data type. Still, the truth is, I struggle to spell "dictionary." Even now, I copied the word from your comment.

I'd rather phrase it as "well-defined data structures help maintain your app." In another comment, leetrout recommended using named tuples. They define a list of their attributes without saying anything about their types, and this may be a perfect choice for some scenarios.

Yes, the context is Python.

Hey, molly0! Do you have a specific example in mind? I'm thinking about how common this use case could be but can't come up with anything.

In my case. We have an internal REST like api. It mostly is just a wrapper around our python ORM but returns JSON.

If I update an object model It’s because I want to expose new fields. Else I actively have to tell it not to.

It feels like a normal use case.

Huh, I worked with this architecture, and while it was convenient at first, it became an issue down the road. Here's what we had.

- A few times, we inadvertently exposed internal fields. They were not sensitive, just internal. Still, clients discovered and started using them and effectively blocked us from changing the data schema without updating the API version.

- A risk of inadvertently exposing sensitive fields. We never had this, but the mere fact that it was too easy to have, kept unnecessary pressure on us.

- Adjusting the serialization format for different purposes became a problem. When everything is a dict, it's difficult to bolt in custom serialization logic. We had this issue when we had to support different API versions, different object representations for different clients, or different purposes. For example, when we cache an object, we want to keep all the fields, but when we return it to an object, we need to maintain the subset of them.

- Slower onboarding. When a newcomer joins the project, they need to be aware that any database change may leak as an API attribute. They couldn't start working before they saw the whole picture.

We haven’t had issues with exposing unwanted fields (yet?). autogenerating API documentation and versioning major updates address the concerns you listed for us.

True. Don't slap in types just because you can — add types when you need to work with your data. Most of the time, I worked with systems where my python code *was* the downstream and required data to run some business logic. In that context, types make the most sense.

The standard for type hints in Python is lengthy and detailed PEP-484.

PEP-483 is 2x shorter and builds the foundation for this work. It summarizes the typing theory and outlines its guiding principles for Python. I found it helpful to see the bigger picture.