СУБД на стороне клиента разработчику нужно воспринимать только в качестве разновидности кеша данных, для которого по счастливому случаю предусмотрен API в виде SQL.
Какие проблемы?
- Все те, что есть у любой подсистемы, что обеспечивает кеширование. То есть, нужно следить, чтобы в ней находились только актуальные данные. Обеспечивать своевременную синхронизацию данных с сервером, решать конфликты кеша и данных сервера. Если у вас для пользователя предусмотрено ведение учетной записи, то в локальную базу данных не должно загружаться никаких данных, не предусмотренные правами доступа пользователя.
В любом случае, у вас эксклюзивная часть приложения, в которой, например, ведутся сведения об учетных записях пользователей, хранится состояние лицензий, должна находится на сервере. И там будет нормальная, взрослая СУБД.
Суть в том, что имеющие SQL запросы (INSERT, JOINT LEFT - RIGT) делать на стороне клиента, и я задался вопросом себе, насколько это нужная задача, и какие аргументы мог бы противопоставить, что это нужно - не нужно?
Если вы хотите собирать текст запросов на клиенте, передавать на сервер, и там исполнять.
Не самый хороший вариант, но терпимо только в одном случае, если учетная запись пользователя в точности соответствует учетной записи в СУБД, и доступ к данным в СУБД четко ограничен правами доступа - из учетной записи в СУБД нельзя дотянуться ни до каких данных, не принадлежащих только этому пользователю.
Но такое редко бывает, так что воздержитесь от этой практики, воспользуйтесь лучше GraphQL/TreeQL, чтобы ограничить API только тем функционалом и теми данными, которые необходимы для конкретного пользователя.
