5 ms·

I think "CRUD" applications are getting an undeserved bad rap. There's always interesting challenges involved, which sadly gets dismissed as "business logic".

I think "CRUD" applications are getting an undeserved bad rap. There's always interesting challenges involved, which sadly gets dismissed as "business logic". If CRUD apps were really so brainless, there would have been a race-to-the-bottom plethora of platforms/tools by now that allow domain experts to create their own applications. Another way to look at is that CRUD apps put food on the table for you guys. Be grateful!

ak39 11y ago
Putting food on the table is still insulting it. I love CRUD apps. I especially love CRUD apps that are so simple that end users love using the app. And the best part about such projects/apps? The data that you collect over the months and years. With properly designed data models, the accumulated data for analytics and interactive feedback is worth gold. Then let's see who calls it CRUD anymore.
humanrebar 11y ago
CRUD applications are developed brainlessly. They're more challenging than it seems. It's interesting that people develop CRUD applications in garbage-collected languages because manual memory management is a pain, but they'll gladly expose manual data management to the end user without worrying about analogous data bugs. If data bugs are important, you need your data management system to have some qualities of a garbage collection system (tracing, reference counting) or it needs to be self-repairing (fill in missing data on demand). This is actually a challenging problem, assuming your data is important. This is why cache invalidation is one of the Two Hard Things in programming according to Martin Fowler.
- crispyambulance 11y ago
  Thanks! that's a remarkably insightful way to look at it.
- OpenDrapery 11y ago
  Interesting. Would love to learn more about these kinds of ideas. Is this something you've been kicking around in your own mind? Or has someone put a more formal framework around these concepts? Where can I read more about it?
  - humanrebar 11y ago
    Thanks. These are mostly my ideas (not that there are any truly new ideas), but they are more-or-less the result of trying to write idempotent services. That is, making sure the same request always returns the same response (modulo incremented sequences). Analogizing data issues to memory management is very useful to software developers that haven't been beat up by data availability and consistency issues in the past. It's also useful to study functional programming concepts, especially data immutability and data structures that work within that limitation, to identify possible design patterns for organizing things that themselves don't change. For more inspiration, learn about the plumbing of git if you haven't already. The fact that commits never change buys git all sorts of things. How do I model this in a database? I treat (table, sequence_id) pairs like I would memory addresses (or git objects). And I try to design append-only tables as much as possible. No UPDATE queries. Only INSERT (malloc) and DELETE (free). There are a lot of nice benefits here, including the ability to shard based on the age of data, being able to aggressively cache partial results and recalculate only when things change, etc. To that end, most data is best modeled as a time series if data consistency is an issue (and it is if you need to scale). There are exceptions for axiomatically true things, like mathematical calculations, but for the most part things like "how many users like sandwiches" change depending on when you ask them. So the right question is "how many users like sandwiches as of 11:32:23 today?". Or maybe "how many users liked sandwiches when you ran calculation job 432342?" Then you can collate timestamps or sequence IDs to see if some data is stale, if unused data can be cleaned up, etc.
fridek 11y ago
CRUD apps are 90% brainless. The only challenge not solved by phpMyAdmin or others alike is UI and nice connections between the data. There were already attempts at generating this 90% just to decorate with UI and additional logic, but I feel it will take some time to do it well. People got burned by GWT and other backend + frontend solutions. Also "CRUD apps put food on the table for you guys. Be grateful!" is a really broken way of thinking. Salary after a certain point doesn't increase happiness that much [1] so there is no good reason to work on CRUD apps if one doesn't like that and can cover their needs otherwise. [1] http://content.time.com/time/magazine/article/0,9171,2019628,00.html http://content.time.com/time/magazine/article/0,9171,2019628...
- lgieron 11y ago
  > so there is no good reason to work on CRUD apps if one doesn't like that and can cover their needs otherwise. Early retirement.
- emilburzo 11y ago
  > People got burned by GWT [...] What do you mean?
  - crispyambulance 11y ago
    Back in the day, there were few javascript libraries and none of them could handle differences between browsers consistently. This was when people had to "roll their own" javascript, explicitly use xmlhttprequest (ajax) and web development was a pain in the ass. People will laugh when I say this now, but for a time GWT was seen as an AWESOME alternative. The proposition that you could just write java and just have GWT shit out html and javascript for you was incredibly compelling. ... until you started using it!
    - emilburzo 11y ago
      > .. until you started using it! I've been building stuff using GWT for the past 5 years, so I'm either doing it wrong or I'm completely missing something. So, what's wrong with GWT?
thirdsun 11y ago
Well said. Furthermore aren't most apps at the core actual CRUD apps? Surely, if we remove all those layers of abstraction that make an app feel pleasant to use, there won't be much remaining that distinguishes it from those CRUD apps. Isn't that the actual challenge?

ak39 11y ago

Putting food on the table is still insulting it. I love CRUD apps. I especially love CRUD apps that are so simple that end users love using the app. And the best part about such projects/apps? The data that you collect over the months and years. With properly designed data models, the accumulated data for analytics and interactive feedback is worth gold. Then let's see who calls it CRUD anymore.

humanrebar 11y ago

CRUD applications are developed brainlessly. They're more challenging than it seems. It's interesting that people develop CRUD applications in garbage-collected languages because manual memory management is a pain, but they'll gladly expose manual data management to the end user without worrying about analogous data bugs. If data bugs are important, you need your data management system to have some qualities of a garbage collection system (tracing, reference counting) or it needs to be self-repairing (fill in missing data on demand). This is actually a challenging problem, assuming your data is important. This is why cache invalidation is one of the Two Hard Things in programming according to Martin Fowler.

crispyambulance 11y ago
Thanks! that's a remarkably insightful way to look at it.
OpenDrapery 11y ago
Interesting. Would love to learn more about these kinds of ideas. Is this something you've been kicking around in your own mind? Or has someone put a more formal framework around these concepts? Where can I read more about it?
- humanrebar 11y ago
  Thanks. These are mostly my ideas (not that there are any truly new ideas), but they are more-or-less the result of trying to write idempotent services. That is, making sure the same request always returns the same response (modulo incremented sequences). Analogizing data issues to memory management is very useful to software developers that haven't been beat up by data availability and consistency issues in the past. It's also useful to study functional programming concepts, especially data immutability and data structures that work within that limitation, to identify possible design patterns for organizing things that themselves don't change. For more inspiration, learn about the plumbing of git if you haven't already. The fact that commits never change buys git all sorts of things. How do I model this in a database? I treat (table, sequence_id) pairs like I would memory addresses (or git objects). And I try to design append-only tables as much as possible. No UPDATE queries. Only INSERT (malloc) and DELETE (free). There are a lot of nice benefits here, including the ability to shard based on the age of data, being able to aggressively cache partial results and recalculate only when things change, etc. To that end, most data is best modeled as a time series if data consistency is an issue (and it is if you need to scale). There are exceptions for axiomatically true things, like mathematical calculations, but for the most part things like "how many users like sandwiches" change depending on when you ask them. So the right question is "how many users like sandwiches as of 11:32:23 today?". Or maybe "how many users liked sandwiches when you ran calculation job 432342?" Then you can collate timestamps or sequence IDs to see if some data is stale, if unused data can be cleaned up, etc.

fridek 11y ago

CRUD apps are 90% brainless. The only challenge not solved by phpMyAdmin or others alike is UI and nice connections between the data. There were already attempts at generating this 90% just to decorate with UI and additional logic, but I feel it will take some time to do it well. People got burned by GWT and other backend + frontend solutions. Also "CRUD apps put food on the table for you guys. Be grateful!" is a really broken way of thinking. Salary after a certain point doesn't increase happiness that much [1] so there is no good reason to work on CRUD apps if one doesn't like that and can cover their needs otherwise. [1] http://content.time.com/time/magazine/article/0,9171,2019628,00.html http://content.time.com/time/magazine/article/0,9171,2019628...

lgieron 11y ago
> so there is no good reason to work on CRUD apps if one doesn't like that and can cover their needs otherwise. Early retirement.
emilburzo 11y ago
> People got burned by GWT [...] What do you mean?
- crispyambulance 11y ago
  Back in the day, there were few javascript libraries and none of them could handle differences between browsers consistently. This was when people had to "roll their own" javascript, explicitly use xmlhttprequest (ajax) and web development was a pain in the ass. People will laugh when I say this now, but for a time GWT was seen as an AWESOME alternative. The proposition that you could just write java and just have GWT shit out html and javascript for you was incredibly compelling. ... until you started using it!
  - emilburzo 11y ago
    > .. until you started using it! I've been building stuff using GWT for the past 5 years, so I'm either doing it wrong or I'm completely missing something. So, what's wrong with GWT?

thirdsun 11y ago

Well said. Furthermore aren't most apps at the core actual CRUD apps? Surely, if we remove all those layers of abstraction that make an app feel pleasant to use, there won't be much remaining that distinguishes it from those CRUD apps. Isn't that the actual challenge?