Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

vjpr.medium.com

Post reply on HN
Print view View original

161–170 of 184 posts

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

#161

Post by kpmah »

The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data.

SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database.

A practical way to use SQL would be to expose the subset of data that is visible to the user and allow that to be queried by SQL, just like it would be by GraphQL or REST.

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

#162

Post by christkv »

kpmah wrote: post #161

The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data. SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database. A practical way to use SQL would be to expose the subset of data that is visible to the user and allo…

We are doing this under the covers in our app using https://github.com/kofrasa/mingo to let us write data queries on the SPA side.

It lets us build reports and other configurable data queries in a standard way for our case.

I can completely see how this makes sense using SQL although I think the complexity of the implementation might be a fair bit higher than mingo.

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

#164

Post by ainiriand »

conrs wrote: post #90

I think we've all wondered this at some point in our careers. It's something you should never do. Off the top of my head: 1) Security (as has been beaten to death here) 2) Interface versioning. If you expose a generalized SQL interface to your consumers directly, good luck ever making a change to your database schema. You'll have no idea whose workflows you break. This high coupling becomes very painful very fast. 3)…

Totally valid points. I think this can be solved by a change of layout. If you do use sql queries in the frontend but have a layer between your front and your database to map which queries are valid and how to map your queries to your own DB representation.

You solve a big chunk of your problems that way.

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

#165

Post by billytetrud »

I basically did this for tixit.me with mongo. I even wrote a module to parse mongo queries on the frontend so we could query our cache identically to our back end. https://github.com/fresheneesz/mongo-parse

It was a pretty big pain to write the middle ware necessary to make this happen. So I kind of agree.

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

#166

Post by cies »

Hasura puts an GraphQL interface on top of my PG. It adds authorization, has plug in based authentication, comes with a decent SQL schema editor, has some migration system built in, and can serve as a proxy to other services. Use hasura-backend-plus and authentication (including email verification, forgot password, etc.) all just works.

Then I generate my client code from the GraphQL schema. I like strong typing so I use Elm on the front end. Now I have strong typing from SQL table to frontend code.

This is a game changer! I dont even want stringly typed SQL, not in the backend not in the front end. I want strong types guarding me against my own stupidity.

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

#167

Post by dimeatree »

kpmah wrote: post #161

The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data. SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database. A practical way to use SQL would be to expose the subset of data that is visible to the user and allo…

I made the mistake of reading the comments before the article, and was stuck with the thought process of "but it's insecure"

Then I remembered my experience of working with an SQL-like based API, that was a pleasant surprise and joy to work with.

I do not see why we can't use it from a client-side perspective, and safely re-cast it server-side.

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

#168

Post by atom_arranger »

cies wrote: post #166

Hasura puts an GraphQL interface on top of my PG. It adds authorization, has plug in based authentication, comes with a decent SQL schema editor, has some migration system built in, and can serve as a proxy to other services. Use hasura-backend-plus and authentication (including email verification, forgot password, etc.) all just works. Then I generate my client code from the GraphQL schema. I like strong typing so I…

People interested in this can also checkout Postgraphile.

I’ve been using both the past few weeks and have preferred Postgraphile.

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

#169

Post by jokethrowaway »

Unpopular opinion: I'd like to have no code or as little code as possible on the frontend (think a tiny library - or a minimal browser) and define application flow / logic on the backend.

I don't want to have SQL on the frontend, I want to have no-frontend.

I'm not advocating to the good old days of backend + HTML and full page refresh, a small layer which smartly dynamically load different pages / submit requests would be acceptable.

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

#170

Post by cies »

atom_arranger wrote: post #168
cies wrote: post #166

Hasura puts an GraphQL interface on top of my PG. It adds authorization, has plug in based authentication, comes with a decent SQL schema editor, has some migration system built in, and can serve as a proxy to other services. Use hasura-backend-plus and authentication (including email verification, forgot password, etc.) all just works. Then I generate my client code from the GraphQL schema. I like strong typing so I…

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?
Post reply on HN