The company where i work uses indexed db to store the data for an offline application, and believe me indexed db is such a great tool in these scenarios. I am thinking to create an offline application myself from scratch to have a better understanding. Thankyou for the video.
Thank you for the comment. Apparently someone has said that indexedDB doesn't keep information indefinitely, like I have thought, so maybe I need to check that part. It was something about when application is not a PWA or browser not Firefox
I don't really think it is needed for lots of apps, but, I when you build offline friendly app and some other use cases like mine it sooooo much better DX wise at least.
Use typeorm and make an app where you ship the entire database to the client for complete offline capabilities. But you can also keep full server side capabilities without shipping all the data. Maybe. Now that's a good use for an ORM. 😁
Very good video! I didn’t even know that indexedDB exist, but I don’t understand the need for storing the data locally if the user doesn’t verified, the should came from the server anyway to be the most updated data. also you can use react query and it is automatically stores the data in cache for you
Reading from the database is not an issue, in my case most of the content for the website is static. But allowing anonymous writing is a bad practice since you open the gate to your database to put whatever data anyone wants. So I believe you are not arguing that authentication is needed. Another way which was also available at the time of writing was to use anonymous authentication using Firebase, but I have decided to use indexedDB. What is shown in the video is more of a leftovers of another experiment with data that I had. So for me its just more convenient than localStorage. Regarding react-query, I didn't know about it at the time, also I am not sure it will cache outbound data as well, especially if that data is failed to be uploaded. Also cache is not exactly the same thing as storage you can read/write to at will, so even now I do not see how using react-query will benefit me, but, on the other hand, adding it to the project would be a better idea instead of what I was using so far :)
In my opinion the IndexDB service is very good for big apps in general but not for small application, and also depends on the type of data you want to store, images, or just plain objects in my experience with it i didn't realy had "fun" while using it but it gets the job done very well
@@real23lions Sorry, but I am not a native speaker, "no-brainer" does sounds better. I meant that using it with native API is not comfortable experience, using idb is better but Dexie is my choice here.
I really want to write my own indexeddb library so I can use it purely for state management in react instead of having to duplicate the database and manage the state separately. Not quite a good enough developer to accomplish that yet!
That is not the reason to not write the library. Start making one today and you will become a better developer at the end of that path. Start small and improve and change interface over time. Just find that piece of state you want/need to share in your app and try to do it via indexedDb and see if you like it :)
@@LifeLoveAndMonads Didn't mean to imply I wasn't trying. I'm just not a good enough developer to get it to work yet. I really don't like the idea of having to maintain a state plus the indexeddb, I really want to just use the indexeddb, since the state should not change unless the indexeddb transaction was successful.
There are two different things we are talking about here, whether or not you are a good developer and whether or not you making progress with the library. Whether you are good or bad developer is very subjective, everyone changes. You can be better than someone else at something and be worse at something else. Thats life, and because of that best way is to compare with yourself. It is so easy to be intimidated by others. There are lots and lots of developers out there who are way better than me, and I know there are lots and lots of those who are "worse" than me. But that doesn't make me good or bad developer, only how I perceive myself. Regarding library - keep trying - but maybe also evaluate the idea, why do you think its great? Or not great. Since state management and state persistence are two different while potentially related problems. Not all the state have to be persisted. But if you want it to be persisted then of course indexedDb is an option.
@@LifeLoveAndMonads Perhaps I'm over thinking it, but having to maintain both the state and the persistent data is an area with potential for error. Since the end result writes to an intel hex file for engine calibrations, and it needs to have some measure of version control I figure indexeddb is the best solution. The application state needs to persist as well, so that if the window gets closed, all the settings, changes, etc are maintained and the application opens back up to where it was.
I think this could be an interesting and inspirational read if you are not yet familiar with it: tanstack.com/query/v4/docs/framework/react/plugins/persistQueryClient
You can find repo where I use it here: github.com/PompolutZ/wuclub_monorepo
The company where i work uses indexed db to store the data for an offline application, and believe me indexed db is such a great tool in these scenarios. I am thinking to create an offline application myself from scratch to have a better understanding. Thankyou for the video.
Thank you for the comment. Apparently someone has said that indexedDB doesn't keep information indefinitely, like I have thought, so maybe I need to check that part. It was something about when application is not a PWA or browser not Firefox
This is great! Even though it has been in support for quite some time I have never used it. Thanks!
I don't really think it is needed for lots of apps, but, I when you build offline friendly app and some other use cases like mine it sooooo much better DX wise at least.
Use typeorm and make an app where you ship the entire database to the client for complete offline capabilities. But you can also keep full server side capabilities without shipping all the data. Maybe. Now that's a good use for an ORM. 😁
Maybe something worth exploring! But I generally do not like ORMs :)
Your app would only have one endpoint /login
Void of data security
Awesome video. I just found out about this as a self taught web dev.
Glad it was helpful!
IndexDB is used in the AWS Amplify backend framework in their Datastore offline first solution, it syncs with DynamoDB, just an fyi!
Firebase uses it as well. This is how they store some auth information at least
Very good video! I didn’t even know that indexedDB exist, but I don’t understand the need for storing the data locally if the user doesn’t verified, the should came from the server anyway to be the most updated data. also you can use react query and it is automatically stores the data in cache for you
Reading from the database is not an issue, in my case most of the content for the website is static. But allowing anonymous writing is a bad practice since you open the gate to your database to put whatever data anyone wants. So I believe you are not arguing that authentication is needed. Another way which was also available at the time of writing was to use anonymous authentication using Firebase, but I have decided to use indexedDB. What is shown in the video is more of a leftovers of another experiment with data that I had. So for me its just more convenient than localStorage.
Regarding react-query, I didn't know about it at the time, also I am not sure it will cache outbound data as well, especially if that data is failed to be uploaded. Also cache is not exactly the same thing as storage you can read/write to at will, so even now I do not see how using react-query will benefit me, but, on the other hand, adding it to the project would be a better idea instead of what I was using so far :)
In my opinion the IndexDB service is very good for big apps in general but not for small application, and also depends on the type of data you want to store, images, or just plain objects
in my experience with it i didn't realy had "fun" while using it but it gets the job done very well
For me using it with Dexie was a dealbreaker, because their API is so nice.
@@LifeLoveAndMonads I assume you don't mean dealbreaker because that means you won't use it. Did you mean "no-brainer"?
@@real23lions Sorry, but I am not a native speaker, "no-brainer" does sounds better. I meant that using it with native API is not comfortable experience, using idb is better but Dexie is my choice here.
I really want to write my own indexeddb library so I can use it purely for state management in react instead of having to duplicate the database and manage the state separately. Not quite a good enough developer to accomplish that yet!
That is not the reason to not write the library. Start making one today and you will become a better developer at the end of that path. Start small and improve and change interface over time. Just find that piece of state you want/need to share in your app and try to do it via indexedDb and see if you like it :)
@@LifeLoveAndMonads Didn't mean to imply I wasn't trying. I'm just not a good enough developer to get it to work yet. I really don't like the idea of having to maintain a state plus the indexeddb, I really want to just use the indexeddb, since the state should not change unless the indexeddb transaction was successful.
There are two different things we are talking about here, whether or not you are a good developer and whether or not you making progress with the library.
Whether you are good or bad developer is very subjective, everyone changes. You can be better than someone else at something and be worse at something else. Thats life, and because of that best way is to compare with yourself. It is so easy to be intimidated by others. There are lots and lots of developers out there who are way better than me, and I know there are lots and lots of those who are "worse" than me. But that doesn't make me good or bad developer, only how I perceive myself.
Regarding library - keep trying - but maybe also evaluate the idea, why do you think its great? Or not great. Since state management and state persistence are two different while potentially related problems. Not all the state have to be persisted. But if you want it to be persisted then of course indexedDb is an option.
@@LifeLoveAndMonads Perhaps I'm over thinking it, but having to maintain both the state and the persistent data is an area with potential for error. Since the end result writes to an intel hex file for engine calibrations, and it needs to have some measure of version control I figure indexeddb is the best solution. The application state needs to persist as well, so that if the window gets closed, all the settings, changes, etc are maintained and the application opens back up to where it was.
I think this could be an interesting and inspirational read if you are not yet familiar with it: tanstack.com/query/v4/docs/framework/react/plugins/persistQueryClient