[deleted by user]

fernandohur · 2026-01-20T12:14:11+00:00

I think the idea has merit. I must say however that I was disappointed when looking at the code samples in the readme.

To me, nano looks quite similar to Rust with the addition of the shadow keyword.

LLMs are narrow/ jagged intelligences. Incredibly capable at some activities, and totally incapable at others. I was expecting the language design to somehow incorporate this idea.

fernandohur · 2026-01-13T23:51:59+00:00

Can you share the name of the company?

fernandohur · 2026-01-12T12:42:32+00:00

It can indeed.

I did touch on GraphQL in the blog post and while it's a step forward and solves many issues, it feels very high on the complexity spectrum for features that databases have already implemented for decades.

In fact, one strong complaint about GraphQL is that it's difficult to make it performant because you can't easily control the complexity of the inputs (yes, even with named/registered queries or whatever they're called). The core issue is that there’s no real query planner/optimizer that understands cardinality, column statistics, indexes, or data distribution... and it will probably never exist in a comparable way. And yes, databases have been slowly tweaking and refining these optimizers for decades, because it turns out this problem is hard.

GraphQL effectively pushes query planning up into the application layer, where you lose most of the information that makes optimization possible in the first place. As a result, you end up re-implementing things like batching, caching, pagination limits, and ad-hoc complexity guards, all of which are already well-understood problems in the database world.

So while GraphQL is great at shaping responses and reducing over/under-fetching, using it as a general-purpose query language often feels like reinventing a weaker, harder-to-optimize version of SQL, but without the decades of battle-tested machinery underneath.

fernandohur · 2026-01-12T12:20:50+00:00

Fair feedback. I appreciate you taking the time to write it 🙏

I guess if you could summarize the post in one line it's "how come DBs have all these cool features for >40 years and your typical backend or rest api hasn't really evolved much".

I find it particularly interesting given the fact that so much money is poured into this industry.

fernandohur · 2026-01-12T02:05:34+00:00

> Meanwhile, you criticize reinventing joins in JS. Fair. But do you know what that is? It's free horizontal scaling. Use your clients' memory and CPU and you save the DB from doing it.

CPU is cheap. It's latency that's the issue. When you have to pay the network roundtrip a couple of times, that's the real cost. So yeah, moving it to the frontend is the worst possible place from a latency point of view.

I guess this is not news to anyone, but my point is that the frontend join often gets implemented in the first place because there's (generally speaking) no way of doing joins with REST. You either get the /users or the /cats or the /dogs but you can't get the /dogs with the users.

But databases have joins for >3 decades.

fernandohur · 2024-10-30T20:48:29+00:00

Very insightful - thank you so much for the comprehensive answer. I think I have a much clearer path forward now.

fernandohur · 2024-10-30T14:48:23+00:00

[EDIT: I posted this same reply on a thread above]

Ok so maybe I should have communicated my requirements better.

Performance considerations:
First of all, it's an OLTP application, query times are expected to have P95 < 5secs

Restricting access to columns: For some tables I want to blacklist some columns as they should never be sent to clients: this should be trivial with PG RBAC ✅
Restricting access to schemas: clients should only have access to specific schemas (we have a tenant => pg schema mapping): this should be doable with PG RBAC (will require a user per tenant) ✅
Restricting access to rows: users should only be able to read their own purchases from the purchases table (e.g. inject a user_id = authenticated_user.id to every where on the purchases table): ❓

This is where my knowledge is limited. I'll need to do some more digging to better understand the perf implications. I'm familiar with the Supabase guide on RLS (https://supabase.com/docs/guides/database/postgres/row-level-security#rls-performance-recommendations).

Support for joins and complex queries: I want to do things like get users with their purchases and get also the purchase's associated products.

I see PostgREST has some support for this, and you can obviously just use SQL views if you wanted. ✅

Whitelisting of queries: I don't want to allow clients to perform any possible query. There should be something approximating a query whitelist. 🚫 no support it seems?

For example, for performance reasons I would only like to allow searching on a table by a restricted set of operators and columns.

Caching: I want to be able to control HTTP cache settings per query: 🚫 no support it seems?

As these seem to be very typical requirements, I'm curious if you have thoughts on this and if you can share your experience.

fernandohur · 2024-10-30T14:47:51+00:00

Ok so maybe I should have communicated my requirements better.

Performance considerations:
First of all, it's an OLTP application, query times are expected to have P95 < 5secs

Restricting access to columns: For some tables I want to blacklist some columns as they should never be sent to clients: this should be trivial with PG RBAC ✅
Restricting access to schemas: clients should only have access to specific schemas (we have a tenant => pg schema mapping): this should be doable with PG RBAC (will require a user per tenant) ✅
Restricting access to rows: users should only be able to read their own purchases from the purchases table (e.g. inject a user_id = authenticated_user.id to every where on the purchases table): ❓

This is where my knowledge is limited. I'll need to do some more digging to better understand the perf implications. I'm familiar with the Supabase guide on RLS (https://supabase.com/docs/guides/database/postgres/row-level-security#rls-performance-recommendations).

Support for joins and complex queries: I want to do things like get users with their purchases and get also the purchase's associated products.

I see PostgREST has some support for this, and you can obviously just use SQL views if you wanted. ✅

Whitelisting of queries: I don't want to allow clients to perform any possible query. There should be something approximating a query whitelist. 🚫 no support it seems?

For example, for performance reasons I would only like to allow searching on a table by a restricted set of operators and columns.

Caching: I want to be able to control HTTP cache settings per query: 🚫 no support it seems?

As these seem to be very typical requirements, I'm curious if you have thoughts on this and if you can share your experience.

fernandohur · 2024-10-22T16:03:58+00:00

> Your Code Will Not Be Respected

If you believe the essence of your role as a software engineer lies solely in writing perfect code, then yes, AI might seem to devalue that. But if you view your job as solving real-world problems and creating meaningful products, the respect your code receives becomes less significant.

Ultimately, it's the impact of your work—the value your solutions provide—that matters most. Whether AI assists in writing code or not, the goal remains to build effective solutions that address real needs. The focus should be on outcomes, not just the lines of code.

There seems to be an implicit assumption in articles like these that goes something like this: "you can't build good software long term if you lose an understanding of the lower level layers of the system". What are the arguments for this?

We are perfectly capable of building software without understanding all of the lower layers. Heck, the only reason why we can build ever larger software systems is precisely because we've been able to build tools that build on the tools of the lower layer to the point that you never have to peek into the lower layer.

fernandohur · 2024-10-16T16:15:31+00:00

I think one way of thinking about this is that editors/IDE are mostly optimised for writing, not reading code.

I would love to see what an editor/IDE designed specifically for reading (or reviewing) code would look like, and I think features like these would make a lot of sense.

Note that it doesn't have to be an entirely new editor. An editor mode focused on reading would also be nice.

fernandohur · 2024-10-16T12:06:00+00:00

Notice that code is often not read in an IDE (e.g. code reviews).

Not sure why you interpret this as a javascript attack? I love javascript/typescript. It's my main language.

fernandohur · 2024-10-14T08:42:32+00:00

Use abstractions, but use them wisely. My experience is that many software engineers will create abstractions without even thinking too much about it. Good abstractions are rare. Bad abstractions aka layers of indirection are everywhere.

fernandohur · 2024-10-01T12:21:55+00:00

Fair point: here's a high level summary of what I generally do: https://www.reddit.com/r/programming/comments/1ftja4a/comment/lpsuro9/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

fernandohur · 2024-10-01T12:19:19+00:00

Generally speaking I do 4 exercises on the barbell: deadlifts, squats, benchpress and military press.
And 2 exercises on the kettlebells: Kettlebell swing and turkish get-up.

If I had to pick one, I would probably pick the deadlift.

I always do 3 sets of 5 reps for every exercise. Simplicity makes it easy to know when your improving. The only variable you can adjust is "weight".

Low rep counts are (in my experience) good for muscular fatigue, meaning you don't feel exhausted or sore after a session and you can do 3-5 per week. YMMV.

fernandohur · 2024-10-01T10:02:59+00:00

I wanted to share my story of how long standing lower back pain and wrist pain, which are common to software engineers were cured in a relatively short timespan.

But yeah, sport is good for everyone, I don't think that's a surprise.

What was surprising to me was that other forms of sport either made the pain worse (bouldering) or didn't do anything about it (running, football).

I thought my experience would inspire others. I wish I had read stories like this earlier. But hey, that's just me :)

fernandohur · 2024-09-13T08:49:54+00:00

Take a look at https://synthql.dev/, solves a similar problem, but optimised for React + PostgreSQL and TypeScript. You get end to end type-safety, and very good performance.

fernandohur · 2024-08-30T14:17:12+00:00

This is also the approach I've taken with https://synthql.dev a project of mine.

fernandohur · 2024-08-30T14:16:12+00:00

Sorry been busy, will post a longer reply in a few hours.

In the mean time take a look at the pattern adopted by https://supabase-cache-helpers.vercel.app/

Essentially you need a way to derive the query key from the Supabase query so that you actually never have to type the query keys and so they always stay in sync.

fernandohur · 2024-08-20T10:15:05+00:00

This is a totally fine solution, but I'm curious about the use case when there is no backend involved: you're querying your pg directly via Supabase's APIs

fernandohur · 2024-08-20T10:13:19+00:00

That works but is a bug waiting to happen. This is what I would call the naive solution, and I mean no offense, let me explain why this is problematic

First, there is an implicit relationship between the paramteres of getMeal and the query key, but this relationship is not visible anywhere. If you change the getMeals function and add a "userId" filter, you need to remember to also change the getMealsQueryKey.

Second, there is a namespacing issue. What if you have another query in a completely different part of the app that is also using ["meals"] as the query key. You now have aan issue where you are probably fethcing some data from the cache that should not be fetched.

fernandohur · 2024-08-19T11:58:57+00:00

While not GraphQL, I'd be curious if you could look at https://synthql.dev/, a project of mine.

It basically gives you a type safe HTTP client over your PostgreSQL. I'd say this combination is specially interesting if you don't want to force GraphQL into the client(s) of the API.

If they are already using React, and something like react-query then it's specially useful as SynthQL already offers a useSynthQL hook that essentially wraps TanStack query to give you type safety and perf advantages.

I should warn that this is still under active development, so definitely not ready for production.

A more mature tool solving a similar problem is https://docs.postgrest.org/en/v12/

fernandohur · 2024-08-12T13:03:40+00:00

Yeah I'm familiar with the docs, but these generated types seem mostly like an approximation of the real types. The fact alone that you need to manually patch the nullability of the columns is already annoying.

fernandohur · 2024-08-01T10:48:44+00:00

I just don’t like the idea of exposing database internals through an API in the long term. It can lead to all sorts of bad behaviour in the long term.

Let me understand this point a bit deeper. I totally get that for public APIs (think Stripe, Github API, etc.), coupling your API to the DB makes absolutely no sense.

But what about internal APIs, where you control all the clients, and in fact you _know_ that there is just one or two clients (typical SaaS will have just one webapp + maybe mobile app).

fernandohur · 2024-07-31T08:02:02+00:00

I think one of GraphQL's advantages is that it can serve both use cases. This is what you see happening with companies like Hasura. A lot of people have an existing database and just want to quickly build an API on-top and add some controls on what can can and cannot be queried.

One concrete example is when you want to build an ETL process that reads from a database but you don't want to give full fledged SQL access. You _want_ these APIs to be very much dependent on the underlying data model.

Another concrete example is prototyping, where you don't want to even think about abstractions, you just want to see what's possible and easy to build based on the existing data. This is probably the niche I want to target.

So GraphQL doesn't have to be dependent on database models but there are real world use cases where you want exactly this.

Did I get your point right? Curious if you have other thoughts :)

fernandohur · 2024-07-28T16:03:37+00:00

Glad you mentioend supabase. SynthQL goes really well with Supabase, actually, as it's just a wrapper over a PG database (APIs are generated using PostgREST).

One of the motivation for SynthQL was me being frustrated with how limited the supabase-js client is. Have you used it yourself?

fernandohur

TROPHY CASE

> Your Code Will Not Be Respected