[mattlondon]

State management is harder to do when running an app with a 50/50 split across browser and server.

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.

[swiley]

I've written apps like this and have to wonder what on earth you're doing because this is very straight forward.

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.

[fetbaffe]

Yes, lots off apps today have the entire schema replicated in the browser, which means that every schema change you do in the backend must be replicated in the frontend. Madness.

If your UI is a copy of the database why not just give the user a phpmyadmin login instead?

[reportgunner]

> why not just give the user a phpmyadmin login instead?

The guy at the previous company said we can't do that.

[pitay]

You can use one of the many servers that manage the users session for you and only override it if needed. Is there any real problem with a server that uses a cookie to only store the users session ID, storing the other data related to the session ID on the server? For most sites I wouldn't think there would be any issues with it.

[fetbaffe]

Why would you need all that state management in the frontend if most of the rendering is on the backend?

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.

[quanticle]

>You also now need two teams to code the front end - one that knows HTML etc, and one that knows the backend-frontend language

Or, you could hire some full-stack developers and let them split the work more efficiently.