Agreed. Loved this FAQ notice:
"If you don't have the time to at least skim through the documentation and you plan to solely rely on some AI tool, then please do NOT use PocketBase!"
OpenAI models are a little less likely to trip up as long as you keep reminding it that it needs to account for v0.23+
It is a very good piece of work, and extensible with JS (I just tried that). I have a fear about the future because the dev is alone, and responds alone in the discussions. He is also quite, how to say, "rough" in the interactions, which I can completely understand, being the one pulled around by everyone.
This is a very, very good piece of work when you need to decorrelate the back from the front
I didn't know it was just one maintainer. That can both be a good thing for keeping the product focused, but it is also worrying, as that's a single point of failure. Anything could happen and then the whole project might fall into disrepair.
That factor alone would make me weary of overly relying on Pocketbase. I would hope that if he runs out of time, the project could be handed over to the community, but often the problem is then that we end up with 50 forks, all at different stages of development. I wonder what the best solution to this issue is.
What you are saying about forks is very true. Some very good ideas were started, then semi-abandonned on the way and they ended up with incompatible forks, and finally all of this collapsed.
I have no idea what the correct model could be.
- User signups and auth
- Stripe subscriptions using different subscription levels
- Business listings with image galleries, editable images
- Map with markers for business locations, tags, filterable business categories & tags
I'd say that the way Pocketbase handles collections, you probably don't want data that is too nested (even though there's a JSON type field, which then allows much deeper nesting).
If you're coming from Firebase, you might be used to infinitely nestable collections, but that's not how it works in Pocketbase. So you could either have a ton of collections or use nested data.
But, if for example, you had multiple clients which then need to hold a bunch of nested data, you couldn't have a 'clients' collections which then holds a bunch of collections within it. It's just one level of 'collections' within which each item then has fields.
This works well at medium complexity, but could get complicated if you had, say, a CMS where you'd want a few levels of nesting.