Q: Working with laravel-json-api?

[tsterker]

I am considering adopting this package more broadly, but I am concerned about how much boilerplate this would require when using laravel-json-api.

@lindyhopchris I will try to set some time aside to explore possible approaches here, but I was wondering if you already have some general hints from the real world.

My current setup is a modular monolith, so I'd generally have direct access to the DB/Eloquent models.

At a glance, I'm currently seeing these options:

• (A) Pragmatically allow the laravel-json-api package to directly use my eloquent models.
  • This is probably fastest path to adoption, but probably a big compromise in terms of architecture.
  • I'd directly reach for the eloquent models and ensure my feature tests protect me from regressions.
  • I could possibly move the laravel-json-api related classes into the module (i.e. a Presentation namespace after all?) to keep ownership of the eloquent models within the modules.
  • Things might get more complicated if there are cross-module eloquent relationships, e.g. due to legacy or pragmatic reasons.
• (B) Use non-eloquent Resources.
  • This is probably the cleanest approach, but comes with significant boilerplate.
  • I'd also curious which parts of the implementation should live where.

I fully acknowledge that the pure way would probably be to definitely avoid (A), but for smaller projects (B) might not be a justified up-front cost. My current idea is to find a way for gradual ("just-in-time") adoption of DDD and hexagonal/clean/onion architecture concepts, where I start pragmatic in some areas and get increasingly more dogmatic where required. Maybe that's the first mistake? :)

I'll report back if I gain some insights, but would highly appreciate initial general pointers or opinions.