Minimizing boilerplate typing for new projects

Hey alchemists :grinning:,

I’m a developer at a smaller consultancy agency located in Copenhagen, here we mainly build MVP projects for startups which typically takes within 2-3 months to develop. Because of the small develop time, we build a fair bunch of GraphQL APIs with Phoenix and Absinthe.
Sadly it also means that we do a lot of copy’n’paste every time we start on a new projects, as every project need users, some sort of oauth login, graphql schemas etc.
Writing boilerplate code is actually starting to take up a lot of development time, it’s also error prone, also not exactly stimulating our developers.
I want to make this process more efficient and i’ve come up with 2 solutions, I would love some feedback or new ideas. :slight_smile:

  1. File generation
    We build a project, that we add all our boilerplate code to. We could then run something like mix boilerplate.users.

+Fully transparent code

-A struggle to update already “boilerplated” projects
-Many generators depending on level of details
-Probably take longer to write, due to patching of files etc.

  1. Meta programming
    We build a project, which contains macros for stuff like fields (boilerplate_user_fields()) graphql types etc.

+Easy to maintain, with future updates
+More fine grained control of boilerplate parts.

-Less transparent code

Would love to hear your thoughts, pro and cons, new ideas :slight_smile:

Have you looked at:

An Elixir Project Generator

mix_generator
mix_templates

8 Likes

Just what i was looking for, i’ll give it a shot. Thank you!

1 Like

My personal preference in this case is file generation as it doesn’t tie a bunch of otherwise unrelated apps to a dependency that has multiple responsibilities. If you want to upgrade something then it may be more work but the flip side to that is you might be forced to upgrade something you didn’t need to if you had to update the option 2 dependency in an older project.

I’d be more in favour of option 2 if you were talking about splitting out the common parts into their own libraries that could be composed. I don’t think you could do that with everything and you’d still need some form of generation but there may be parts you could break out into packages to find a balance between the two options.

2 Likes