6 ms·
No, I'm with you and prefer SQL for many tasks. SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale". SQL as a languag
by mathgladiator 6y ago
No, I'm with you and prefer SQL for many tasks.
SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale".
SQL as a language within other languages is a nightmare from a security standpoint, and if language integrated query was more common across languages earlier on then this wouldn't have been an issue.
Databases generally depend on normalization, but normalization comes with interesting scaling problems and how do you replicate normalized schemas. Thus denormalization became a thing, and then the emergence of NoSQL and document stores started to infect everywhere. The JOIN was a killer too, and then the discipline required to do sharding made it annoying to manage, so easier to manage solutions became a thing.
I'm looking at databases in a different light these days with more appreciation, but now the hot new thing is GraphQL makes things... interesting. I don't view GraphQL as a server-side solution, but a client solution to overcome the limits of HTTP/1.1. However GraphQL clients are exceptionally complicated, and I'm not sure they are worth it. The only problem is that to overcome them requires engineers "to know how to do things", but that is a hostile stance. People want to go fast and make progress, and GraphQL enables that.
- unodgs 6y agoRecently I tried using SQL directly on the frontend: https://medium.com/@unodgs/sql-on-the-frontend-react-postgres-and-rls-part-1-76bbe4f97353 https://medium.com/@unodgs/sql-on-the-frontend-react-postgre... as an alternative to GraphQL which I also find too complicated. You might find this interesting.
- simonw 6y agoI've been experimenting with SQL as an API language - including client-side SQL constructed in JavaScript - fir a couple of years with my Datasette project. I'm using similar security tricks to you: read-only queries with a time limit, against SQLite rather than PostgreSQL. More here: https://simonwillison.net/2018/Oct/4/datasette-ideas/ https://simonwillison.net/2018/Oct/4/datasette-ideas/ and https://github.com/simonw/datasette https://github.com/simonw/datasette
- unodgs 6y agoGreat to see that! Did it work well for you?
- shean_massey 6y agoIt took me a solid month before graphql finally "clicked" but there's no going back now, I absolutely prefer it over rest now. 10/10 would do again and do suggest everybody give it a try.
- devxpy 6y agoThis makes a ton of sense to me, thanks for sharing your learnings. I see very little value in using GraphQL, when you can just write SQL on the client! We desperately need frameworks to better facilitate this, like Hasura or Django -- DB migrations, permissions, authentication, real-time subscriptions, Admin UI. My most wanted feature is SQL type providers, like Rezoom.SQL - https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL
- wmichelin 6y agoGraphQL and SQL are not mutually exclusive at all. GraphQL is, in no way, faster than any REST alternative in terms of implementation speed. If anything, it is slower, as you need to be extremely methodical with your API changes, as (same with REST I suppose) deprecating fields / entities, for mobile clients specifically, is a PITA unless your clients have really nicely built out forced upgrades. What GraphQL _does_ give you, is type safety and extreme client flexibility . It is a better solution than REST in almost every scenario, other than the initial learning curve, which takes a couple weeks and then you know it forever. Would I recommend some startup write a GraphQL API for their MVP? No, just get something working. Are you at a more medium-sized company looking to build out your much more permanent API? Then yes, you should probably strongly consider GraphQL.
- virtue3 6y agoMVP? Just use your apollo/GraphQL server as the node monolith and be done with it.
- watwut 6y agoI have seen startup using GraphQL for mvp, precisedly because they could change and crank ui fast. They already knew GraphQL, I did not when I joined and learned to modify already existing one in a day or so.
- Draiken 6y agoToo bad nobody thinks whether or not they need the flexibility in the first place. MVPs with single clients using GraphQL for flexibility that is not needed or used are common. GraphQL is a hammer, and now every project is a nail. Anecdotal, of course, but the first thing all FE developers I've ever worked with do when they start/join a project is add/suggest GraphQL/Apollo. Nobody considers how awful things look on the back-end when you need to cache or make magic happen to avoid thousands of N+1 queries. I believe unfortunately it has become the only way many front-end developers learn to interact with any back-end, and now everyone's forced to use it regardless of its drawbacks. Same with React. Facebook managed to get free training for all of their future hires. I hate the company but that was a genius move.
- Zamicol 6y agoWhat is a good "web scale" solution?
- nl 6y agoThese days, SQL. It's true that in the 2000-2010 period many SQL implementations struggled to scale with growth in websites (many other parts of the webstack did too).
- falcolas 6y agoGiven that I’ve seen 25TB MySQL databases, RDBS scale up juuuuust fine. Just... have someone on hand who understands them if you’re going to go that high.
- mathgladiator 6y agoThese days, anything. The question is what is it going to cost in either licensing solutions or engineering effort.
- brynjolf 6y agoWhat are examples of those "easier things"?
- mathgladiator 6y agoMongoDB could be an example, but it introduces yet another empire. Redis is also easier. The key is what are you designing against. If you design against a DB, then you may find that scaling beyond a single host with gotchas. But, if you have the discipline to keep everything within a document, then you can scale up easier as the relationships between documents is more relaxed. However, cross document indexing and what-not creates more problems, and that in and of itself is an interesting challenge.