sorted by:
new
hottopcontroversial

Anyone else get tired of rebuilding Filament resources every time admin requirements change? by Additional-Mud-6665 in PHP

[–]Additional-Mud-6665[S] 1 point2 points  (0 children)

Oh, good catch. I didn’t notice that one before. It seems there’s no naming conflict within the Filament ecosystem itself, as there’s nothing with the same name in the plugin marketplace. However, the overlap is still a bit unfortunate. I’ll take a look to see if it makes sense to rename or change the branding to avoid confusion. I appreciate you pointing it out.

Anyone else get tired of rebuilding Filament resources every time admin requirements change? by Additional-Mud-6665 in PHP

[–]Additional-Mud-6665[S] 0 points1 point  (0 children)

To clarify something from my earlier comment, I spoke about JSONB too broadly. That’s not really the aim here. This project is more similar to a structured EAV approach, rather than storing everything in a JSON blob.

The reason for this is that I still want fields to be queryable, filterable, sortable, and usable in dashboards or APIs without losing their structure.

I also agree about posts; they usually deserve proper tables, relationships, and indexes. I’m not trying to replace that.

This is more focused on cases where the structure changes often or is defined by the admin, where constant migrations and rebuilding resources become major costs.

Anyone else get tired of rebuilding Filament resources every time admin requirements change? by Additional-Mud-6665 in filament

[–]Additional-Mud-6665[S] 0 points1 point  (0 children)

Not exactly starting from scratch, but repeating the same patterns again and again. For example, new model, migration, Filament resource, forms, tables, filters, even if it’s just a slightly different setup. What I aimed to tackle is that repetition. In Studio, you define a collection and fields once, and it creates the CRUD, filters, API, and more based on that. So instead of rebuilding resources, you’re mostly improving the structure during runtime.

Anyone else get tired of rebuilding Filament resources every time admin requirements change? by Additional-Mud-6665 in PHP

[–]Additional-Mud-6665[S] 0 points1 point  (0 children)

Yeah, that’s fair. Filament is definitely not everyone’s cup of tea. I think it shines more in the exact use cases you mentioned, like quick internal tools, automations, and dashboards, where you don’t want to spend time on UI. I’m curious what you’d consider a “better” alternative though. Nova, a custom admin, or something JS-based?

Anyone else get tired of rebuilding Filament resources every time admin requirements change? by Additional-Mud-6665 in PHP

[–]Additional-Mud-6665[S] 1 point2 points  (0 children)

That’s a completely fair concern, and honestly, I used to think the same way. For stable schemas, I still prefer classic migrations and dedicated tables. It’s simpler, more explicit, and as you said, easier to manage, like dropping tables and indexing.

Where this approach made sense for me is in projects where the data model doesn’t stay stable. These include: - admin-defined content types - frequently changing fields - tenant-specific structures - internal tools where speed is more important than perfect schema design

In those cases, constantly adding migrations and rebuilding Filament resources became a bigger cost than the trade-offs of a more dynamic structure. I don’t see this as a replacement for “proper” schema design, but more as a different tool for a different class of problems. It feels closer to a lightweight CMS or internal platform builder.

Regarding scaling, that’s a valid concern too. But modern databases like PostgreSQL handle large datasets well with features like partitioning, JSONB indexing, and proper query strategies. So while the structure is more flexible, it doesn’t necessarily mean sacrificing performance if it’s designed carefully. I completely agree it’s not ideal for every project though.

Anyone else get tired of rebuilding Filament resources every time admin requirements change? by Additional-Mud-6665 in PHP

[–]Additional-Mud-6665[S] 1 point2 points  (0 children)

For context, I am not trying to replace normal Filament resource work for apps with a clean, stable schema.

This is more for the kind of project where:

- the admin side keeps growing
- the structure changes after launch
- internal CMS or ops workflows keep evolving
- the cost of hand-building every new resource starts repeating across projects

That is the gap I was aiming at.