Tell HN: The case for CRUD apps in the age of AI
But, people forget that CRUD apps can be as complex or simple as they need to be. A CRUD app is identified as such by its purpose, not the sophistication of it.
Right now I'm wring a web app that's basically manages some domain data in a central db, but guess the kinds of things I have had to deal with. Here a a few (there are many more), in no particular order:
- Caching and load balancing infrastructure.
- Crafting an ORM that handles caching, transactions, and, well, CRUD, but in a consistent, well-typed, and IO-provider-agnostic manner (IO providers could be: DBs like Postgres, S3-compatible object stores, Redis, Sqlite, Localstorage, Filesystems, etc. Yes, I need all those).
- Concurrent user access in manner that is performant and avoids conflicts.
- Db performance for huge datasets (so consideration of indexes, execution plans, performant queries, performant app architecture, etc, etc)
- Defining fluent types for defining the abstract API methods that form the core of the system
- Defining types to provide strong typing for routes that fulfill each abstract API method.
- Defining types to provide strongly-typed client wrappers for each abstract API method
- How to choose the best option for application- and API security (Cookies?, JWT?, API keys? Oauth?)
- Choosing the best UI framework for the requirements of the app. I actually had to write a custom react-like library for this.
- Media storage strategy (what variants of each media to generate on the server, how to generate good storage keys, etc.
- Writing tooling scripts that are sophisticated enough to help me type-check, build, text, and deploy the app just in the way I want
- Figuring out effective UI designs for CRUD pages, with sorting, filtering, paging, etc built in . This is far from simple. For just one example, naive paging is not performant, I need to use keyset pagination.
- Doing all the above with robust, maintainable, and performant code
- Writing effective specs and docs for all my decisions and design for the the above
And many many more! I've been working on this "CRUD" app for years as a greenfield project that will be the flagship product of my startup. The techniques I have to evolve to solve various challenges could easily fill entire books.
But:
This description sounds less like "I am making a CRUD app" and more like "I am making a generic CRUD app framework/dev tool".
Which is fine, and yes LLMs are not yet good enough to vibe their way at that scale, but it's not the same thing as any specific, concrete, CRUD app that such a tool may or many not also produce.
Actually, it gets worse:
> - Choosing the best UI framework for the requirements of the app. I actually had to write a custom react-like library for this.
Danger, Will Robinson, danger!
UI frameworks sure are fun to write. Done it loads of times myself. But one of those times was before jQuery existed, and was because it was before jQuery existed. Another was before Cocos2d existed, and because it was before Cocos2d existed.
If this was a fun side project then sure, have at it, but as a startup? I've seen people want to reinvent every part of their stack, as you are doing, and it took them 14 years to ship as Early Access.
Unless you're literally one of the FAANG companies, then devs — including ones you may need to hire, even if I'm reading the wrong thing between the lines and this isn't a CRUD-maker, you'll probably need to hire people at some point — aren't going to want to learn yet another UI framework to customise the output of your product.