6 ms·

I never get why CRUD work is looked down upon by many on this site amongst others. Most applications are a variation on CRUD. A well done CRUD app should be pre

by collyw 5y ago

I never get why CRUD work is looked down upon by many on this site amongst others. Most applications are a variation on CRUD. A well done CRUD app should be pretty simple, but simplicity is not something that our industry encourages, the interview process often selects for the ability to produce complexity. As a result most CRUD apps (certainly the ones I have inherited) are an over engineered mess.

Cthulhu_ 5y ago
It's because people get bored. With CRUD apps, the challenge is (should be) in the domain, wrangling that into a comprehensible shape. The various layers and code should be boring - input, validation, API, business logic, persistence. It's the kinda thing that can already be built using visual programming tools, drag and drop interfaces or a single config file churning out a fully functional CRUD API with all bells and whistles. But that's boring. I'm a software developer, I want to write code. If my code is too easy, if it's just what it's supposed to do, where's the challenge? I know, let's use a difficult language! I know, I'll take this chunk, this is now mine, I call it a microservice and it's my baby. An overview of the whole architecture? Pfft that's boring. Netflix does it like this, look they have over a hundred microservices, clearly they must be doing something right, right?
- collyw 5y ago
  I am trying to work out if you are being ironic in your reply or not. I am a software engineer. My job is to solve problems, not to "write code". It just happens that most of the solutions will involve code. The less code that can be written to solve a problem the better. More code is a liability not an asset.
  - dvfjsdhgfv 5y ago
    > More code is a liability not an asset. Unfortunately not all managers agree on that point,
    - anfilt 5y ago
      Generally, that less code means relying on someone else's code which depending on the circumstance could be a bigger liability.
      - collyw 5y ago
        Using well tested libraries is likely more reliable than something I have written myself. Though in my personal experience Python (or Perl) libraries seem to be far higher quality than JavaScript libraries.
        gorjusborg 5y ago
        I used to feel this way, strongly. Now I think about whether the downsides of relying on third party dependencies are outweighed by the upsides. Supply chain attacks are real. Project maintenance suffers for many projects in the long term. If you can write a left-pad function, just write left-pad. If you are implementing a 200 page open spec for a system that needs to interoperate with 100s of other systems, consider looking for a community effort to rely on and contribute to.
        collyw 5y ago
        Yes, I am pretty much in agreement with you there. It's a balance, and as you say smaller things may well be better without a library, but larger things maybe not. And there are going to be exceptions to this rule of thumb.
  - blowski 5y ago
    I'd say @Cthulhu_ is giving the real reason we'd tell our friends in the pub, rather than the bullshit justifications we give our managers.
    - Frost1x 5y ago
      Definitely not a BS reason, at least for me. The less code I write, the less I have to work (in general). If I can reduce total effort, accomplish the goals for those who pay me, and still pull in good income, I'm happy. If I get bored because I've been so efficient at making the people who pay me happy that I have bored free time, I'll use all that slack time I've buffered up to try something different or new without time pressures, otherwise, maybe I'll just go to the gym or for a walk. I like programming, but I don't want me entire life to be nothing but programming. I don't know how some code 60+ hours a week every week. I did that when I was a kid and was mesmerized by the computing industry and wanted to know how things worked--I'm no longer mesmerized. The mysticism is gone and for me, it's just about solving interesting problems using computers that improve people's lives. The less code I have to write to survive, the more choice of direction I have in any additional desires to code. If you're doing theoretical CS work then by all means, pursue the mysticism, but that typically isn't in code, that's in developing foundational theory. I don't want interesting problems in my code if it can be avoided, I want my code to help with interesting problems in the real world. Interesting problems in my code means I have complexity to deal with and makes my software more prone to issues, difficulty maintaining, difficulty adapting. The simpler the solution where feasible, the better. Some roles don't give you this sort of flexibility to make sure you're not bored and in those roles, that's where you see these elaborate overly complicated systems where people tuck things into the deliverables when they're unneeded. To me, that's a management and/or structural problem. I don't think my desires are all too different than most peoples desires, no matter what people in professional environments say to make sure they still get paid and are professionally progressing.
- shrikant 5y ago
  I often used to say (somewhat in jest) that it takes a million microservices to build one service.
golergka 5y ago
> A well done CRUD app should be pretty simple Should it? I'm currently building a "simple" CRUD app as a side-project. My background is in game development and backend, and I decided to learn React and React Native in the process. But at one point I realised that I want to app to be functional while the user doesn't have internet and sync afterwards, and now I'm in hell. Now, I have to make all post requests idempotent, cache them on the client in case there's no internet, serialise and deserialise this cache when app quits and turns back on, display optimistic updates on the client as well but at the same time make it transparent in UI that those updates were not yet synced on the server, and handle request queue in such a way that when I send two requests that modify the same client-server object response to the first request that comes after optimistic update from second request doesn't override it, but a failure of one of the requests cancels all subsequent ones. I think I just got a headache writing that sentence. I also need invalidate local client cache of different server objects based on what mutation did I attempt to do and what result did I get from the server — when you create an object of some kind, different collections of these objects are invalid now, some can be updated optimistically, some need to be refetched. And I also need to invalidate these caches based on different kinds of errors returned from the server: authorisation, authentication, network problems, invalid user input and unknown problems that probably signify errors in my code all need to be handled differently. May be I'm missing something, but implementing all of that functionality properly still seems like an unsolved problem out of the box. I've already prototyped solutions using useSWR, React Query and Redux, and I'm still not satisfied, as not of all these cases are handled properly. However, now I understand why so many web and mobile apps have so many bugs: based on the state of the tools and libraries, it seems that most developers simply don't care for all these cases and mostly stay on the happy path, cutting their workload by the factor of 10.
- barbarbar 5y ago
  Keep state on the server. Start with zero javascript.
  - golergka 5y ago
    And how would my app work without internet, I that case?

by collyw 5y ago

Cthulhu_ 5y ago

It's because people get bored. With CRUD apps, the challenge is (should be) in the domain, wrangling that into a comprehensible shape. The various layers and code should be boring - input, validation, API, business logic, persistence. It's the kinda thing that can already be built using visual programming tools, drag and drop interfaces or a single config file churning out a fully functional CRUD API with all bells and whistles. But that's boring. I'm a software developer, I want to write code. If my code is too easy, if it's just what it's supposed to do, where's the challenge? I know, let's use a difficult language! I know, I'll take this chunk, this is now mine, I call it a microservice and it's my baby. An overview of the whole architecture? Pfft that's boring. Netflix does it like this, look they have over a hundred microservices, clearly they must be doing something right, right?

collyw 5y ago
I am trying to work out if you are being ironic in your reply or not. I am a software engineer. My job is to solve problems, not to "write code". It just happens that most of the solutions will involve code. The less code that can be written to solve a problem the better. More code is a liability not an asset.
- dvfjsdhgfv 5y ago
  > More code is a liability not an asset. Unfortunately not all managers agree on that point,
  - anfilt 5y ago
    Generally, that less code means relying on someone else's code which depending on the circumstance could be a bigger liability.
    - collyw 5y ago
      Using well tested libraries is likely more reliable than something I have written myself. Though in my personal experience Python (or Perl) libraries seem to be far higher quality than JavaScript libraries.
      - gorjusborg 5y ago
        I used to feel this way, strongly. Now I think about whether the downsides of relying on third party dependencies are outweighed by the upsides. Supply chain attacks are real. Project maintenance suffers for many projects in the long term. If you can write a left-pad function, just write left-pad. If you are implementing a 200 page open spec for a system that needs to interoperate with 100s of other systems, consider looking for a community effort to rely on and contribute to.
        collyw 5y ago
        Yes, I am pretty much in agreement with you there. It's a balance, and as you say smaller things may well be better without a library, but larger things maybe not. And there are going to be exceptions to this rule of thumb.
- blowski 5y ago
  I'd say @Cthulhu_ is giving the real reason we'd tell our friends in the pub, rather than the bullshit justifications we give our managers.
  - Frost1x 5y ago
    Definitely not a BS reason, at least for me. The less code I write, the less I have to work (in general). If I can reduce total effort, accomplish the goals for those who pay me, and still pull in good income, I'm happy. If I get bored because I've been so efficient at making the people who pay me happy that I have bored free time, I'll use all that slack time I've buffered up to try something different or new without time pressures, otherwise, maybe I'll just go to the gym or for a walk. I like programming, but I don't want me entire life to be nothing but programming. I don't know how some code 60+ hours a week every week. I did that when I was a kid and was mesmerized by the computing industry and wanted to know how things worked--I'm no longer mesmerized. The mysticism is gone and for me, it's just about solving interesting problems using computers that improve people's lives. The less code I have to write to survive, the more choice of direction I have in any additional desires to code. If you're doing theoretical CS work then by all means, pursue the mysticism, but that typically isn't in code, that's in developing foundational theory. I don't want interesting problems in my code if it can be avoided, I want my code to help with interesting problems in the real world. Interesting problems in my code means I have complexity to deal with and makes my software more prone to issues, difficulty maintaining, difficulty adapting. The simpler the solution where feasible, the better. Some roles don't give you this sort of flexibility to make sure you're not bored and in those roles, that's where you see these elaborate overly complicated systems where people tuck things into the deliverables when they're unneeded. To me, that's a management and/or structural problem. I don't think my desires are all too different than most peoples desires, no matter what people in professional environments say to make sure they still get paid and are professionally progressing.
shrikant 5y ago
I often used to say (somewhat in jest) that it takes a million microservices to build one service.

golergka 5y ago

> A well done CRUD app should be pretty simple Should it? I'm currently building a "simple" CRUD app as a side-project. My background is in game development and backend, and I decided to learn React and React Native in the process. But at one point I realised that I want to app to be functional while the user doesn't have internet and sync afterwards, and now I'm in hell. Now, I have to make all post requests idempotent, cache them on the client in case there's no internet, serialise and deserialise this cache when app quits and turns back on, display optimistic updates on the client as well but at the same time make it transparent in UI that those updates were not yet synced on the server, and handle request queue in such a way that when I send two requests that modify the same client-server object response to the first request that comes after optimistic update from second request doesn't override it, but a failure of one of the requests cancels all subsequent ones. I think I just got a headache writing that sentence. I also need invalidate local client cache of different server objects based on what mutation did I attempt to do and what result did I get from the server — when you create an object of some kind, different collections of these objects are invalid now, some can be updated optimistically, some need to be refetched. And I also need to invalidate these caches based on different kinds of errors returned from the server: authorisation, authentication, network problems, invalid user input and unknown problems that probably signify errors in my code all need to be handled differently. May be I'm missing something, but implementing all of that functionality properly still seems like an unsolved problem out of the box. I've already prototyped solutions using useSWR, React Query and Redux, and I'm still not satisfied, as not of all these cases are handled properly. However, now I understand why so many web and mobile apps have so many bugs: based on the state of the tools and libraries, it seems that most developers simply don't care for all these cases and mostly stay on the happy path, cutting their workload by the factor of 10.

barbarbar 5y ago
Keep state on the server. Start with zero javascript.
- golergka 5y ago
  And how would my app work without internet, I that case?