Live data from Hacker News

Don’t we all just want to use SQL on the front end?

vjpr.medium.com

181–184 of 184 posts

Re: Don’t we all just want to use SQL on the front end?

#182

Earlier quoted context omitted.

> It also requires you to have one database user per external user. So? You are adding a database entry per external user, along with data identifying their roles/permissions in the app, one way or the other. You can either use custom code you’ve built on top of the DB engine to apply this, or you can use the far more battle-tested code in the database engine. I’m not sure why so many developers believe reinventing t…

How many millions, or billions, of database users are you comfortable managing? 0 millions for me. I'll stick with the well tested and explored method of having a users table with foreign keys on the ID to other tables to identify data ownership. The idea of using one DB user per end user is, at best, novel and untested. We don't know where or how it will fail. Scaling would be a real bear too. And I'm fairly certain…

Looks like you have some knowledge hole. Let’s start with MSSQL you can use AD groups and those are the one and only thing that database setups are concerned with. On the AD side users get added/removed all the time. I have personally managed this kind of system with nearly “0” overhead on the DB side. Group assignment is the maintained by team managers decentralizing the whole thing.

For non Kerberos Linux systems using LDAP to synchronize group membership is the only extra automation needed.

It is possible and fairly easy to manage a very large number of accounts IF done properly.

Re: Don’t we all just want to use SQL on the front end?

#183

Earlier quoted context omitted.

I’ve seen replicache before and definitely very interested to use it. Will replicache be self-hostable in the future?

As of a month or so, it's even better: Replicache has no server side component at all. It's client-side software that talks directly to your server. See: https://twitter.com/replicache/status/1359690468892626944?s=... for more. (We've shipped this now, but not re-announced it yet).

Yeah I went through the docs and saw that now it's client-side. Very exciting!

Re: Don’t we all just want to use SQL on the front end?

#184
post #170

Earlier quoted context omitted.

People interested in this can also checkout Postgraphile. I’ve been using both the past few weeks and have preferred Postgraphile.

Could you explain what you preferred in Postgraphile?

I've tried building the exact same app using Hasura and Postgraphile after having built another app in Postgraphile:

  - Postgraphile has better Relay support, stuff like returning added edges, returning deleted nodes, good global ID support.
  - Hasura didn't support something like adding a currentUser field when using the Relay support. The pagination in the non-Relay mode was very basic and didn't comply with the Relay pagination spec.
  - Comparatively even when not using Postgraphile's Relay support it still supports both the Relay pagination API and the easy "nodes" pagination API.
  - With Hasura I initially liked the UI for management but found it tedious as I continued working.
  - I came across some bugs with Hasura's pagination API's, which was the final thing that made me decide to switch to Postgraphile.
Post reply on HN