Sanity check on time taken to build resource routes

This sounds like a problem I've helped solving before. At my company, we've created an admin panel that uses Angular as a consumer of a Laravel REST API. We use a generator for doing the repetative work of making migrations, models, requests, controllers, routes, etc. We chose this path because we need the freedom of being able to use Laravel to it's maximum potential. Generate once, tweak wherever needed.

Sure, when starting a new project a developer can be generating and tweaking files for a day or two, but by then we have everything we need to start importing data and building a front end.

I would love some kind of framework on top of Laravel to be able to take a declaration of a project's models and relations and do the rest automagically, but I've not been able to think of a way to handle things like multi-language, parent/child constraints, eager loading, etc. For simple things this might work, but after over a year of working with this full time we know that things get complicated very fast and we don't know of a way to handle that in an automated way.

we've created an admin panel that uses Angular as a consumer of a Laravel REST API

I really wish I'd set out on that approach for this project TBH, but I wanted to get a handle on the general way of working. In the next phase, I may refactor to do this.

we know that things get complicated very fast and we don't know of a way to handle that in an automated way

That is ALWAYS the kicker when building libraries - the balance between power and flexibility

I've managed to solve a couple of the problems you mention there, which I'm pretty pleased about, mainly by adding a CrudMeta layer between the database and the controller, where all the meta / logic for forms and views resides. Every resource / model has a 1:1 relationship with a Meta class which allows me to keep both Models and Views clean, with the CrudService doing all the I/O and view data collation by interrogating the Meta and Repo classes.

Everything is provided using DI, so it's easy to extend the core classes and override any methods should the current setup not meet your needs, with the majority of the main classes having multiple ways to override their inputs.

But as you say, after a year, things do get complicated, and the constraints and overhead of a library can get in the way of writing the code you need.

Still interested in more answers...

You've left out a key motivation and requirement. My main question is - why are you doing this?

My experience has led me to the conclusion that anything that tries to solves things generically, ends up with generic solutions, and complexity creeps in as soon as you start to have more use-case-specific requirements.

Unless you're building a CMS or something for the mass market, my suggestion - don't build it this way. You WILL end up hating your work :)

Hey @kirkbushell, thanks for the input, and I totally hear you.

I'm doing this mainly to keep things as DRY as possible when the project is fairly generic.

My issue with generators, is that you end up with so many files and so much duplicated code right from the word go, when you're really just finding your feet, and probably doing a lot of refactoring anyway. When your everyday work isn't back end, keeping track of all that makes your head spin, and I'm likely to end up with a really shitty, inconsistent codebase.

Is that something you, as a back end specialist, just come to accept, or do you have your own set of tricks to mitigate that?

I think it's irrelevant - by the time you finish you'll have learnt other things that were better anyway. To give you an idea, I work on a platform that is now 3 years old, and it's had 2 complete rebuilds in that time. The current version is quite large, and has about 3 different directions in it as we've learnt more and more about the domain, and ourselves. The best part is that the new platform has far less boilerplate and generic solutions, which means we're actually freer to make changes and refactors on small parts of the codebase, rather than having to rebuild it all again (as we've already done).

Consistency is impossible, but you can always work toward making it more consistent as times goes on, which is what we're doing. Overall we have tried and true patterns but there are certainly some elements that are newer, and others that are older.

The problem with trying to solve it all with a swiss army knife, is that eventually you have a problem it can't solve, and you end up either having to hack your way through your old work, and eventually scrapping it, or adding code that doesn't fit the mould anyway.

Each feature you work on should simply reflect the requirements at the time and nothing more.