As above - I have been building a product to detect the effect of medication on ADHD, and other mental disabilities, to help people with managing those problems.
Now, I would really like to use SOLID to store user data - but I’m confused about how to get started and if the time investment is too large to warrant using it at this point.
I’m using mariadb and firebase at the moment, mariadb will be postgres soon though. I’m taking in eye movement data and a lot of other datasets from text and video.
Should I just focus on my product, or is there a way to integrate Solid that won’t slow me down ridiculously?
hi @Hewlbern and Welcome on the boat
Sounds really adapted to use Solid as storage.
As i understand your project, the user uses your app to stores his feelings on his personnal POD.
And this app, uses your ML algorithms, to help him.
If your ML algo can be reach by API,
the user data stay on his POD, and recommandations are made on the fly.
I think all could be done in a webapp.
It’s the mainly used server right now, but I wouldn’t use it for anything in production as it calls itself a “prototype implementation of a Solid server”.
I guess several things could change if it reaches v1.0, though I don’t know much about this process. Here’s the repository: https://github.com/solid/solid-spec
(From my current understanding) database queries are inefficient
I think if you need to query your whole database, you need to fetch the relevant files first into memory.
e.g. if you want to know the age groups of all your customers to understand who is using your product. Then you likely would need to fetch all profiles and then select their profiles.
Maybe there are better ways within Solid that I don’t know of, but with my current understanding applications that need queries over the whole database are pretty infeasible right now. You would need to adapt your application requirements instead. Feel free to correct me though, I’m not that sure on this one
Opinionated Conclusion: Solid is good for POC applications, but not yet production ready, especially concerning sensitive personal data.
I think that Solid would be a good fit in the future.
I think the amount of data you need to process is only limited to the current user, and with Solid you could do that without any data ever reaching your server. Fetching the data from only one pod is rather easy to do and efficient enough imo. I’m pretty sure that the 3rd point from my previous reply doesn’t apply to your use case.
You could try to store it in an interoperable way, so others app could also use it. Either apps with the same goal (competitors or new versions), or completely different apps.
Also it would scale easily, as you only need to provide the app, not the backend.
But as mentioned before, I wouldn’t consider Solid production ready yet. With better servers (which are in progress) and maybe spec v1.0 I’d definitely tell you to use it
Solid should not be seen as a (semi) drop-in replacement for an existing SQL database: it places requirements on your data model from the start, and thus would probably require an almost ground-up rewrite of your product.
Hence, my advice would be to focus on your product for now, unfortunately.
