It is somewhat more complex to handle more pages in your code base, but each page is short and simple.
It is somewhat more complex to handle more pages in your code base, but each page is short and simple.
You end up with a lot of complexity around cookies/local storage (and trying to persuade users that cookies are not bad and that their virus checker should not delete the cookies please ...) or encoding the session ID in the URL and hoping that users do not share links or bookmark pages, and then of course you end up with the "please only click once" links around buttons etc.
You also now need two teams to code the front end - one that knows HTML etc, and one that knows the backend-frontend language (although could be nodejs of course). It is an extra interface that needs to be designed and maintained with all the opportunities for screwups that come with it.
We already have two teams today, one for the overly complex frontend and one for the backend. Solution to that is server side rendering and full stack developers.
Or, you could hire some full-stack developers and let them split the work more efficiently.
Put a session id in a cookie and use a relation table to point at the tables owned by the user. This takes very little code. The alternative is managing a distributed database, half of which has to run in the browser. That actually sounds much harder (although not surprising for a startup.)
If users are deleting first party cookies than it's their own fault. Tracking state on the website you've visited is the entire point of cookies. If the user throws their phone on the ground really hard your website also won't run on it.
If your UI is a copy of the database why not just give the user a phpmyadmin login instead?
The guy at the previous company said we can't do that.