Anvil: An attempt of saving time

When I'm creating a new project, I always have the same problem: To follow best practices and make the code maintainable, the codebase becomes extremely verbose.

It always takes my motivation from me to have to write a bunch of stuff only to make some CRUDs. It's boring, repetitive, and takes all my joy off coding.

Why I don't use Template Repositories?

• It's a terrible experience to have to keep updating dependencies.

• I always forgot to change example values, like the README

• The changes that I do on the template aren't applied to the previous projects, so if I want to add a new thing like graceful shutdown, I have to do it one by one, and I have it.

• This one doesn't affect it so much, but I don't like to have commits from the template repository on a new repository, and it's an extra thing to have to delete the .git folder

This leads me to think about the things that I hate, and I discovered that I hate many things:

• Lack of documentation in a project

• Lack of standards between multiple projects

• Lack of a way to track where a piece of data is used

• Lack of standards between multiple projects

• Lack of a way to track the flow of events and communication between services

• Lack of standards between multiple projects

Did I mention that I hate the Lack of standards between multiple projects? Because I hate it. A lot.

And all these frustrations gave me an idea: What If I tried to create a specification to creating APIs?

Most APIs follow the same pattern and have the same things, and we all agree on a couple of standards and best practices for web development.

And from this, Anvil was born.

Anvil is my attempt to create something that's a mix of three things:

• OpenAPI/Swagger specs

• No-Code solutions

• Frameworks

So, from a schema file (similar to OpenAPI specs), a code generator that can be fully customized by anyone, will generate a repository with all the standards and best practices that you want, without making you dependent on it like a Framework would.

The best part is that it can update your project for you, so it's not used only on the project creation. The schema file will always be the starting point for any feature.

I'm already working on the schema definition, it's hard to make it work with all the features that HTTP has, it ends up being too flexible (WE NEED MORE STANDARDS!!!!), but nothing that a couple of days to define if a property should be called ResHeaders or ResponseHeader, am I right?

Please, look at the repository, the JSON schema definition, and the examples to see what you think about it. I'm open to any suggestions, the more edge cases that we can predict, the fewer breaking changes we have.

If you have any options that you wanna share, please, leave them in the comments or create an issue in the repository, and let's talk about it. Thanks for reading.