4 ms·
a thing a I tried, and ran out of steam with, was writing SQL queries in my client side code but statically extracting them with babel, so you have some code li
by phpnode 5y ago
a thing a I tried, and ran out of steam with, was writing SQL queries in my client side code but statically extracting them with babel, so you have some code like this:
const users = await sql.query`select * from users`;
console.log(users);
and in production this becomes something like
const users = await fetch('/query?id=19a1f14efc0f221d30afcb1e1344bebd');
console.log(users);
and the query itself stays on the server so you don't have to deal with the problem of unbounded complexity / DoS.
This is the same approach Facebook uses for GraphQL. The only reason I gave up with this idea is that getting the developer experience right is hard work and it does introduce some very tight coupling!
- 33degrees 5y agohttps://blitzjs.com/ https://blitzjs.com/ does something similar, where you can write server side code inside components and it turns it into an API
- vaughan 5y agoThis doesn't help with optimistic UI updates though. The article is less about remotely executing SQL, but more about having a relational data model as a cache in the frontend. However, when sending the query through to the backend on a cache miss, would be useful to only allow queries that have been extracted like so. Its similar to how Apollo does query [caching][1]. I really like it! [1]: https://www.apollographql.com/docs/apollo-server/performance/apq/ https://www.apollographql.com/docs/apollo-server/performance...
- WrtCdEvrydy 5y agoWe've done this with octo-cli and OpenFaaS now. Legacy codebases are hard to remove because it's difficult but once you turn every SQL call into an HTTP call... the remaining part is the logic which can be rewritten into something more modern.