Who is trying to switch to GraphQL? Especially for service to service, internal calls?
Nobody who writes software to solve an actual problem, but that's a very small subset of software companies :)
Building for the 99% Developers
151–160 of 310 posts
Re: Building for the 99% Developers
#152In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…
Greatly successful projects often have horrible(from developers perspective) codebase that barely doesn't fall apart. They call it technical debt and fix il later when things stop moving fast.
I think it's happening because successful projects focus on the product delivering on the reason it exists(i.e. facilitate file transfer in the most intuitive way possible) and to do that quickly as possible for the lowest cost possible engineers hack together solutions derived from the existing tools without focusing on the technical or ideological perfection. Also, they cannot focus on the technical stuff anyway because to needs and direction change all the time, therefore it's not possible to crystallise an optimised and well built solution anyway.
What Microsoft or other companies do is to built versatile tools that that engineers can bend and stick together to accomplish the tasks in hand very quickly and if it looks like the thing is here to stay they can design and implement an optimised and elegant solution later on. At first it may look ugly but it is usually an original work done by domain experts who are exploring technical solutions to the problem in hand. Once the solution is found, experts in computer programming and architecture can step in and make it elegant but that last step is not needed for the wast number of solutions.
An example for this is UK's covid case tracking early on. Apparently they quickly implemented a central Excel spreadsheet that would collect the CSV data sent from the test centres. Unfortunately, the solution they implemented was way too hacky and they lost data once they reached the limits of the spreadsheet format they have chosen. Had they chosen a better format, their solution would have worked up until much higher scale and once they have a better understanding of the nature of data collection etc. then they could have implemented a clean sheet solution with "perfect" code and scalability, maybe years later for the future pandemics and write blog posts about the enormous challenges and their ingenious solutions. They couldn't have start by firstly building the perfect data collection solution because they wouldn't know how things will pan out and if they tried to force their way(i.e. mandatory formats by the tests centres) it would have been too big of a projects.
Re: Building for the 99% Developers
#153> Too many people believe that aiming for good software quality means you need to fully adopt that new technology, whether it’s microservices, GraphQL, or distributed tracing. You’re not done until you’ve switched fully over to the ideal technology.
This. We are constantly presented with new and shiny things. And then, barely a year later, there is the next ideal technology. And the next, and the next, and the next.
We have seen this with everyhing: Languages, coding standards, paradigms, editors, organisational methodology, interview methodology, frameworks, databases, security, design basics,...the list is endless.
But here is some truth:
C is still written. As is pure JS. Imperative/Prodecural code never went away. Websites on servers we can physically touch are still deployed. People still write working implementations for almost everything under the sun from scratch. Information-Dense, slim, efficient interfaces that get jobs done are still there. As are monolithic architectures. Good 'ol RDBMS still work great. bash is still the dominant shell. grep/cut/awk are still great for analysing logs. Water still flows downhill.
"new" and "better" are 2 different words, with different meanings. Something that's new could be better. But he fact that it's new, in itself, doesn't automagically make it better. And even if its better in one scenario, its doesn't have to be better in all scenarios.
Re: Building for the 99% Developers
#154In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…
In other words, does a16z ask for startups to attack MS on their home turf?
There can be a niche for the product creation stage. But how does a company scale in MS's market? Sooner or later, it's a Slack vs MS Teams situation.
Re: Building for the 99% Developers
#155We way over complicate things. SQLite can be used for 95% of real world use cases. And whenever WAL2 + BEGIN CONCURRENT get merged into main, it will be able to handle 99% use cases. And don’t fool yourself into believing you’re not in that 1%.
You're not the only commenter saying this, so I gotta ask: whatever VM that SQLite DB is on, is your business cool with a business disruption, dataloss, or both when that VM goes down, when that AZ goes down, or that disk fails? Or am I missing something? If you have some sort of fail-over-to-last-backup plan, is that not just a distributed database with more steps, and why not something like RDS, or CockroachDB? (Fr…
The customers we have today can tolerate some degree of outage. VM snapshots are usually the path.
Our roadmap has replication being done at the application level (i.e. business logic is aware of other nodes and policy around replication). Those specific entities which absolutely must survive would be synchronously replicated to additional witnesses on the network.
Note that this is about non-repudiation, not operational uptime. If we cared about always on operations, we would take a radically different path.
Abstractly, I think the role of ensuring business data survives some incident is not something to be pushed down to the database layer. When you pull this concern into business logic, you can produce far more robust solutions.
Re: Building for the 99% Developers
#156I am not sure what the point of the article really is. I mean it’s not wrong, we all live in that real world (my job is literally migrating off stuff) and recognize everything the author says. It’s just that I don’t see those myths being myths in the first place. In fact, thinking that the 1% is any different is perhaps the biggest myth in the article. Sure they have distributed crap to handle and uptime commitments…
You may be lucky, surrounded by sane people. Having new joiner stating on 2nd day that the whole system has to be moved to microservices on graphql with blue/green continuous deployment to solve all past and future problems is a real problem, it does exist. Some people seem to fall into this trap described in the article of reading some blog post on some approach and fixating on it in religion-like mindset. It makes…
>- use N-order thinking
what does this mean?
Re: Building for the 99% Developers
#157Earlier quoted context omitted.
How do you implement this using a stateless stack (eg PHP)?
I think what bob1029 meant was just that opening multiple connections doesn't increase concurrency so don't do it unnecessarily (by using a connection pooling library for example). With PHP you have one "process" per request, so you'd just need to make sure you only open a single SQLite connection per request (using the singleton pattern for example).
PS: If this is incorrect, I'd love to know why instead of getting downvoted :)
Re: Building for the 99% Developers
#158Earlier quoted context omitted.
I think what bob1029 meant was just that opening multiple connections doesn't increase concurrency so don't do it unnecessarily (by using a connection pooling library for example). With PHP you have one "process" per request, so you'd just need to make sure you only open a single SQLite connection per request (using the singleton pattern for example).
PS: If this is incorrect, I'd love to know why instead of getting downvoted :)
The traditional pattern of one connection per transaction is actually a strong anti-pattern when working with SQLite in particular.
This is because SQLite is just a file, not a network connection or named pipe. Obtaining and releasing file handles is a non-trivial task that takes significantly longer than reusing the same one.
Re: Building for the 99% Developers
#159Earlier quoted context omitted.
PS: If this is incorrect, I'd love to know why instead of getting downvoted :)
The traditional pattern of one connection per transaction is actually a strong anti-pattern when working with SQLite in particular. This is because SQLite is just a file, not a network connection or named pipe. Obtaining and releasing file handles is a non-trivial task that takes significantly longer than reusing the same one.
That's what I meant with "opening multiple connections doesn't increase concurrency so don't do it unnecessarily (by using a connection pooling library for example)". I was suggesting to only use a single connection for the entire request and NOT to use a connection pooling library.
Now, PHP doesn't share memory between requests so there's no way to re-use the same connection across requests. That's just a sad fact about PHP and I don't think there's a reasonable way around it other than not using PHP.
PS: I haven't used PHP in over a decade so my knowledge might be outdated.
Re: Building for the 99% Developers
#16099% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%". Whether this distinction is relevant to you depends on where you sit. If you are a startup sellin…
For the last few days I've been rewriting one of the company's legacy WordPress plugins to work better with modern WooCommerce. That's right: PHP, baby. Ugly, hacky, sticky, oozing PHP. Oh woe is me, etc etc, but you know what? It makes the customers money, which makes the company money, which makes me money. I've gotten used to eating and living indoors, so this is a good thing. It's not serverless, there is no Grap…
PHP is the OG serverless