What is the optimal flow for guest to user functionality

Storing guest data temporarily in a database is a common practice in web development, and it can be a viable option for your app as well. Here are some potential benefits of this approach: It can provide a better user experience: When a guest creates an itinerary, they expect their data to be saved somewhere, even if they don't sign in. If you're only using sessionStorage, there's a chance that the user's data could be lost if they accidentally close the browser window or navigate away from the page. By storing the data in a database, you can provide a more reliable and consistent user experience. It can simplify your code: Your current approach requires you to handle the guest itinerary separately from the user itinerary, which can lead to more complex code and potentially more bugs. By storing all itinerary data in the same database table (with a flag indicating whether the user is signed in or not), you can simplify your code and reduce the risk of errors. It can provide more flexibility for future features: If you decide to add new features to your app (such as the ability to share itineraries with other users), storing all itinerary data in a single database table can make it easier to implement these features. That being said, there are some potential drawbacks to storing guest data in a database: It can increase storage costs: If you have a large number of guests creating itineraries, storing all of this data in a database can increase your storage costs. It can introduce security risks: If you're not careful, storing guest data in a database can introduce security risks (such as SQL injection attacks). Make sure to sanitize all user input and use prepared statements or an ORM to prevent these types of attacks. Overall, I would recommend storing guest itinerary data in a database if possible. However, make sure to consider the potential drawbacks and take steps to mitigate any security risks.