What problem does an orm solve in the frontend?

[sschneider-ihre-pvs]

Pardon my ignorance, but I was asking myself what I would do with an orm in the frontend? I had a glimpse at vee validate with the use of pinia but I seem to be unable to grasp what data would need mapping?

Can someone maybe elaborate the use cases of such a thing?

[CodeDredd]

You don't need to apologize. Like many ppl say....there are no dump questions.
Well pinia-orm will help you to improve maintance( reducing complexity ) & scalability & developing speed, if your app is going to use the store a lot and the store complexity grows.

So if you just have a small app where you don't see it become big, then you don't need pinia-orm.
Maybe this video will also help you. It's about vuex-orm: https://www.youtube.com/watch?v=wH_K5jmDALY
Or read this: https://morioh.com/p/bec0be369d9f ... there even more articles about vuex-orm.

Pinia ORM is just the next iteration after vuex-orm-next stopped developing.

[sschneider-ihre-pvs]

I currently don't use a store explicitly, although a lot of tools act partly like one. Like vee validate stores values also and apollo client cache also.
So usually I would expect an ORM in the backend to map incoming values to outgoing interfaces to other servers or persistence. Why would I need that in the Frontend? Or is it more like a tool for REST apis where you have to mix and merge results from different endpoints to have all information for the frontend?

[CodeDredd]

How much experience do you have with state managment ? Have you worked a lot with vuex or pinia?

You can think that way. An ORM is a structure pattern for data. So yes it is known mostly from the Backend.
But if you have an app which grows and needs to share states, add some point you maybe use a state managment library, because it gives you a lot of benefits (devtools, plugins, etc.).

Normally you start really easy. Lets say you haven an login. then you save the user data in the store so that you don't have to pass it through the components and also that you don't make new api calls to fetch the data. For example displaying the user info.
Then you start defining the store with name, prename, etc.
At some point you maybe need more information. For example all the posts of the user. And yes you can do for all of that api calls. But in point of performance and cost, you want to reduce api calls.
So you maybe sent the relations which maybe are also stored in your backend as relations, with it.

And now again....of course you could save all the data in one state store mongodb like. But then you have a lot of data which you don't need and you need to write function to exstract the data you need.

Look at this example: https://blog.deepgram.com/build-a-todo-list-with-pinia-and-vue-3/ . You will see actions defined and so on.
Thats something you never do if you use pinia-orm, because it comes with all the functions you need to get the data you need.

[CodeDredd]

Here is also more information: https://next.vuex-orm.org/guide/prologue/what-is-vuex-orm.html#why-do-we-need-a-client-side-orm

[sschneider-ihre-pvs]

Ok, the database like representation I get. But that is also pretty much like the apollo client cache looks like, and makes references between data. At least in the orm store alternative, that is easier to access than the cache.
Most of the state I currently work with lives in composables. That would have been my next question also, are stores or orms just composables factories with extra functionality?

[CodeDredd]

yes & no.....pinia is more the composable as a store with extra functionality. And vuex is more a plugin.
But overall it is a yes.