5 ms·

I really like web apps that are just CRUD forms. It obviously doesn't work for everything, but the "list of X -> form -> updated list of X" user experience work

I really like web apps that are just CRUD forms. It obviously doesn't work for everything, but the "list of X -> form -> updated list of X" user experience works really well for a lot of problem domains, especially ones that interact with the real world. It lets you name your concepts, and gives everything a really sensible place to change it. "Do I have an appointment, let me check the list of appointments". Contrast that, to more "app-y" patterns, that might have some unifying calendar, or mix things into a dashboard. Those patterns are also useful!! And of course, all buildable in rails as well. But there is something nice about the simplicity of CRUD apps when I end up coming across one. So even though you can build in any style with whatever technology you want: Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity" Next.js (+ many other FE libraries in this react-meta-library group) feels like it _prefers_ you build "1 task/view = mixed concepts to accomplish a task = 1 specific screen"

andrei_says_ 2y ago
Figma, online photo and video editors, canva and browser based games are the only non-CRUD examples I can think of from recent memory.
philip1209 2y ago
Yeah, I agree. Too many degrees of freedom can degrade an experience, if not used properly.
zdragnar 2y ago
The problem with 1 model = 1 rest entity (in my experience) is that designers and users of the applications I have been building for years never want just one model on the screen. Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly. If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing. I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).
- cosmic_cheese 2y ago
  This may be a misunderstanding on my part, but something that’s kept me away from GraphQL is how it makes for a hard dependency on GraphQL client libraries in clients. I find that very unappealing, it’s nicer to be able to e.g. just use platform/language provided networking and JSON decoding (e.g. URLSession + Swift Codable on iOS) and keep the dependency list that much shorter.
- grncdr 2y ago
  > If you have a single page front end setup, and a "RESTful" backend Rails really doesn't encourage this architecture, quite the opposite in fact. > designers and users of the applications I have been building for years never want just one model on the screen. ... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as: <%= render @product.reviews.order(created_at: :desc).limit(5) %> Of course this can have the opposite problem of bloated views taking forever to load, but Rails has lots of caching goodies to mitigate that. --- Going back to the GP post > Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity" That's definitely the simple path, but there are very few constraints on what you can do.
- LargeWu 2y ago
  Why the assumption that an API endpoint should be a 1:1 mapping to a database table? There is no reason we need to force that constraint. It's perfectly legitimate to consider your resource to encompass the business logic for that use case. For example, updating a user profile can involve a single API call that updates multiple data objects - Profile, Address, Email, Phone. The UI should be concerned with "Update Profile" and let the API controller orchestrate all the underlying data relationships and updates.
  - wahnfrieden 2y ago
    Rails began that trend by auto-generating "REST" routes for 1:1 table mapping to API resource. By making that so easy, they tricked people into idealizing it Rails' initial rise in popularity coincided with the rise of REST so these patterns spread widely and outlasted Rails' mindshare
adsteel_ 2y ago
Rails is set up for that, but it doesn't force you to build like that. You're free to build in other patterns that you design yourself. It's nice to have simple defaults with the freedom to opt into more complexity only if and when you need it.
globular-toast 2y ago
> I really like web apps that are just CRUD forms. I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.
- searls 2y ago
  As someone who co-founded one of the most successful Ruby on Rails consultancies in the world: building CRUD apps is a _fantastic_ business. There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive. I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it. IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender. Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.
  - andrei_says_ 2y ago
    Similar experience here. I see unnecessarily overengineered SPAs everywhere - from blogs to CRUD-only SAAS and read about devs starting each project as an SPA by default. Including blogs and static websites. The choice to spend 10x-50x the resources and deal with the agony of increasing complexity doesn’t make sense to me. Especially in the last few years since Rails’ Hotwire solves updating page fragments effortlessly.

andrei_says_ 2y ago

Figma, online photo and video editors, canva and browser based games are the only non-CRUD examples I can think of from recent memory.

philip1209 2y ago

Yeah, I agree. Too many degrees of freedom can degrade an experience, if not used properly.

zdragnar 2y ago

The problem with 1 model = 1 rest entity (in my experience) is that designers and users of the applications I have been building for years never want just one model on the screen. Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly. If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing. I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).

cosmic_cheese 2y ago
This may be a misunderstanding on my part, but something that’s kept me away from GraphQL is how it makes for a hard dependency on GraphQL client libraries in clients. I find that very unappealing, it’s nicer to be able to e.g. just use platform/language provided networking and JSON decoding (e.g. URLSession + Swift Codable on iOS) and keep the dependency list that much shorter.
grncdr 2y ago
> If you have a single page front end setup, and a "RESTful" backend Rails really doesn't encourage this architecture, quite the opposite in fact. > designers and users of the applications I have been building for years never want just one model on the screen. ... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as: <%= render @product.reviews.order(created_at: :desc).limit(5) %> Of course this can have the opposite problem of bloated views taking forever to load, but Rails has lots of caching goodies to mitigate that. --- Going back to the GP post > Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity" That's definitely the simple path, but there are very few constraints on what you can do.
LargeWu 2y ago
Why the assumption that an API endpoint should be a 1:1 mapping to a database table? There is no reason we need to force that constraint. It's perfectly legitimate to consider your resource to encompass the business logic for that use case. For example, updating a user profile can involve a single API call that updates multiple data objects - Profile, Address, Email, Phone. The UI should be concerned with "Update Profile" and let the API controller orchestrate all the underlying data relationships and updates.
- wahnfrieden 2y ago
  Rails began that trend by auto-generating "REST" routes for 1:1 table mapping to API resource. By making that so easy, they tricked people into idealizing it Rails' initial rise in popularity coincided with the rise of REST so these patterns spread widely and outlasted Rails' mindshare

adsteel_ 2y ago

Rails is set up for that, but it doesn't force you to build like that. You're free to build in other patterns that you design yourself. It's nice to have simple defaults with the freedom to opt into more complexity only if and when you need it.

globular-toast 2y ago

> I really like web apps that are just CRUD forms. I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.

searls 2y ago
As someone who co-founded one of the most successful Ruby on Rails consultancies in the world: building CRUD apps is a _fantastic_ business. There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive. I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it. IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender. Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.
- andrei_says_ 2y ago
  Similar experience here. I see unnecessarily overengineered SPAs everywhere - from blogs to CRUD-only SAAS and read about devs starting each project as an SPA by default. Including blogs and static websites. The choice to spend 10x-50x the resources and deal with the agony of increasing complexity doesn’t make sense to me. Especially in the last few years since Rails’ Hotwire solves updating page fragments effortlessly.