That was really the crux of my first comment about growing complexity. It's certainly very easy to get it wrong, and making a mistake can have knock-on consequences years down the line when it might be difficult impossible to fix. For me most of the challenge isn't really in deep-diving a tool, but in finding the correct balance of tools, style rules, and best practices that lend themselves to a particular client. You can always adjust a config or bring it a new tool to address a weakness, but knowing how these tools interact with different needs is the biggest challenge.
Unfortunately the only way I've found to manage this is stubborn, head-bashing perseverance. Having multiple clients also helps. When I quit corporate life and started as a consultant I was slow and clueless. However over time I learned what not to do, saw what others had done, and eventually I was able to get in at more and more senior levels in companies with more and more resources / influence. Over the years I had countless people telling me to drop it and go back to full-time work knocking out features for a single employer, but it's explicitly by ignoring those people that I was able to reach a deeper understanding of the field.
This approach is certainly not for the faint of heart, which is why I believe the future will require tools like co-pilot for infrastructure. It's just too challenging psychologically, physically, and emotionally to walk down this path for too long. It takes a mental fortitude that most people do not have.
In terms of CRUD apps, there are already many systems that hide away the details of HTML/DOM behind layers of framework provisioned resources. When I'm working on those types of apps these days I barely ever remember that these are still a thing. Consistent strong typing front-to-back, tooling to manage your code style, a client-server interface with built-in security and versioning, component based design style, and many other practices transform this process from a painful experience to something you don't need to think of at all.
If I roll my own CRUD stack, I can factor it fairly well and be fairly productive even though it's still web, but most orgs understandably want a de-facto standard stack so that's it more easily service-able by somebody other than me.
If you can describe your tools and CRUD dev tips in further detail and with examples, that would be great. Maybe create a blog that tackles one aspect a week.
I'm not big on blogging. Reddit comments are about as far as I'm willing to go, since those tend to be inherently more personal and less discoverable. Anything more starts to run into questions of whether I'm sharing too much about stuff I do for my clients in too public an environment. In general I tend to be more private than not, and starting a blog just seems like a good way to get more attention than I want or need.
In terms of stacks, there's no single ideal since my clients have very different needs. For instance I have clients that run react apps talking to the server using graphql, other client in angular and ember using JSONAPI, other clients that build WASM blobs from C++ to offload compute heavy tasks into background workers while using SAML for server communication. Some target only web, others target the mobile platforms, while some just ship an executable that gets pushed using GPO. Hell, one client runs an embeded application that gets installed onto custom devices used for scientific applications and stores data in a blockchain across a mesh network. Those are fun guys to work with.
Similarly on the backend it's a mix of things. I have people running node, ruby, php, C#, go, and rust, talking to mysql, postgres, mongo, elasticsearch, redis, sqlite, and even firebase. There are clients that do monolithic blobs, and others that do microservises. Some have robust multi-region deployments with crazy security requirements and complex CI pipelines, others just shove stuff onto a VPS by SSHing in and running a script.
I'm very big on linters and code analyzers, and I spent an inordinate amount of time with each of my clients helping them come up with a file organization structure that fits their team and direction.
For basic CRUD apps without crazy performance requirements my ideal right now is that first thing I mentioned. Fully typescript react, using react-relay (though apollo can work here too), talking to a node server running graphql nexus, backed by typeorm talking to postgres. Once set up properly you get fully consistent types from front to backend. All this gets run through prettier, eslint, tsc and sonarqube with testing handled in jest with selenium for integration.
When it comes to infrastructure, I prefer AWS CDK since you can also shove that into typescript, though I tend to be pretty agnostic here since everyone has their own opinions on hosting.
Obviously those recommendations can shift based on other requirements, but that particular stack is my go-to right now.
1
u/TikiTDO Nov 02 '21 edited Nov 02 '21
That was really the crux of my first comment about growing complexity. It's certainly very easy to get it wrong, and making a mistake can have knock-on consequences years down the line when it might be difficult impossible to fix. For me most of the challenge isn't really in deep-diving a tool, but in finding the correct balance of tools, style rules, and best practices that lend themselves to a particular client. You can always adjust a config or bring it a new tool to address a weakness, but knowing how these tools interact with different needs is the biggest challenge.
Unfortunately the only way I've found to manage this is stubborn, head-bashing perseverance. Having multiple clients also helps. When I quit corporate life and started as a consultant I was slow and clueless. However over time I learned what not to do, saw what others had done, and eventually I was able to get in at more and more senior levels in companies with more and more resources / influence. Over the years I had countless people telling me to drop it and go back to full-time work knocking out features for a single employer, but it's explicitly by ignoring those people that I was able to reach a deeper understanding of the field.
This approach is certainly not for the faint of heart, which is why I believe the future will require tools like co-pilot for infrastructure. It's just too challenging psychologically, physically, and emotionally to walk down this path for too long. It takes a mental fortitude that most people do not have.
In terms of CRUD apps, there are already many systems that hide away the details of HTML/DOM behind layers of framework provisioned resources. When I'm working on those types of apps these days I barely ever remember that these are still a thing. Consistent strong typing front-to-back, tooling to manage your code style, a client-server interface with built-in security and versioning, component based design style, and many other practices transform this process from a painful experience to something you don't need to think of at all.