A blog post about GraphQL in an enterprise setting, that fails to address the biggest GQL feature for enterprises. Not unlike most material on HN about microservices. Federated supergraph is the killer feature imo.
Think half an abstraction layer higher. You're on the right track with multiple PHP virtual runtimes on a single VM - that could conceptually be viewed as a sort of precursor to function runtimes.
The serverless function has higher-order features included as part of the package: you get an automatic runtime (just as with PHP but in this case it can be golang or dotnet), the function gets a unique endpoint URL, it can be triggered by events in other cloud services, you get execution logging (and basic alerting), multiple functions can be chained together (either with events or as a state machine), the function's compute can be automatically scaled up depending on the traffic, etc.
Think of it as: What do I have to do, in order to scale up the conpute of this URL? For hardware it's a call to DELL to order parts, for VMs or containers it's a matter of scaling up that runtime, or adding more instances - neither of those processes are simple to automate. One key characteristic of the function is that it will scale horizontally basically however much you want (not fully true, aws has a limit of 1500 instances/second iirc, but that's pretty massive), and it will do it automatically and without the request sources ever noticing.
Functions are also dirt cheap for low/burst traffic, and deployment is almost as easy as in the PHP FTP example. Personally I also think they are easier to test than traditional apps, due to their stateless nature and limited logical size (one endpoint). The main downsides are cost for sustained load, and latency for cold starts.
With that said, they are not "endgame". Just a tool - a great one for the right job.
Do you mean figuratively that OP is replacing Cobol? Because I don't see that in the article. It mentions other technology that I would not associate with a super-conservative stack - like Databricks, JSON, Postgres and Google Analytics. So I'm a bit confused by your comment. And by all the downvotes, honestly.
I just pointed out that personally I would not consider Lambda - which has been a stable and popular technology for 10 years - to be cutting-edge. It's not old but also not cutting-edge imo. I would reserve that term to newer technology. Apparently a controversial view on HN, which is interesting.
To respond to your question, I did work for a bank in 2017 with moving certain burst-type processing to a set of Lambdas.
I don't agree that it's useless either, but I would expect the test macro to match what I do while working: Opening multiple PRs in new tabs all the time, cloud vendor portal tabs, looking through logs and metrics, scrolling (more than watching) some YT video, lots of scrolling and switching of the 15 open tabs, navigating enterprise software portals that are badly written web apps (looking at you, Salesforce)... this is a normal workflow for me and I feel that it questions the crazy in the crazy macro. It also questions the sanity in me, but that's beside the point.
Having a good amount of background processes running (terminal stuff, IDE, Slack, Google Drive, OneDrive, VPN etc. is probably hard to test without introducing more variance, but I can imagine they could play a part. Especially on an 8 GB unified memory MacBook.
Is this an LLM? :) The question was rhetorical. Both of these proposals have problems. But the main issue is that the author of the article is missing an angle of toasts as a UX concept.
The solutions seem to rely on a user that doesn't navigate before the action is completed. Does he propose locking the UI in the meantime, or to optimistically show the user a success result?
Sorry, something was probably lost in interpretation. You wrote:
> RTO for giants is a must because they die without the office.
Are you referring to tech giants here? That's what the thread was about I believe (interviewing for tech roles, at least). Just to make sure - you are not including Starbucks here.
> Offices are the last meaningful /.../ [stuff that I probably agree with] /.../
> Essentially if we WFH for all eligible jobs we re-create a SMEs economy killing the giants
This is what sounded like conspiracy to me. Would RTO due to "saving Starbucks" really be an argument line that Apple pursues?
They don't want to hire someone who knows Pandas specifically. They want someone who can identify this technology, learn it and then possibly implement it. And more importantly - someone who can do the same when the situation calls for some other technology. This is the crux imo.
The wide range of offers you received may not necessarily reflect a "crapshoot" in tech hiring. Instead, it likely demonstrates the diverse needs, prioritizations, resources, and role definitions across different companies. Especially if the openings varied in company size/location/industry/division/business area/etc.
For example, one hiring team maybe prioritized specific technical skills for a certain role, which affected your outcome in that particular process.
Sorry I probably used the wrong term, not a native English speaker. I didn't mean lack of complexity or lack of "features" but rather the lack of carefully thought-through feature "depth". Like, we can infer generic arguments which is nice, but then we try doing that with some keyof complex type and it doesn't work. And later we find an issue on GitHub saying that it's not implemented. Which is fine, I love TS anyway and it's evolving.
Certainly advanced, but not mature in my experience. Using e.g. classes and inferred generic function arguments, quickly reveals a lot of features that are missing. Often some similar feature is present but it lacks depth/completeness. Lots of good discussions to read in TS repo on GitHub if you're interested: Optional generic type inference, extends oneof, generic values, keyof a subset, conditional types, etc.
I want to emphasize that the reason we keep running into "ceilings" is probably because of its advanced type system. Libraries and frameworks are using those type features and when we can't keep building on the type - we end up casting to unknown and reconstructing it. Which feels worse than not being able to construct that complex type at all.
I have mixed feelings about this. While I do use TS with Node.js today and absolutely like the concept, its type system is still far from something mature and stable like C#. We keep running into ceilings (EDIT: lack of completeness/depth, not lack of complexity) all the time, and TypeScript questions on Stack Overflow is basically a library of workarounds. Mostly bad ones. So if I worked on Node.js I would prefer it to evolve more before actually marrying and having kids with it. But at the same time, I like the direction Node.js is taking.
How many underlying services and clients was the GQL layer catering to? How many different digital products and independent teams? You referred to "the backend team" (one) and did not mention stitching/federation. This makes it likely that you were using GraphQL to address a set of needs that may not be aligned with the goals of GraphQL. Just like the author of the article - it sounds to me like he probably has been working in contexts where he would not have been able to see the org/collab/infra benefits of GraphQL. Much like the case with microservices. Enterprise tech/arch solve more than just technical problems.
Silly. Many big corporations trust Microsoft touching their code. There are enterprise policy controls for Copilot, which includes data privacy.
If you want to make this argument, then the realistic reason would be that Copilot hasn't yet completed the SOC 2 compliance process. That would be a valid reason to wait, for corporations that are listed on Nasdaq or work with very sensitive data. But that's far off from the comment I'm replying to.
I was writing SPAs with jQuery in 2008. By then they were already well-established. We used UI component libraries (mostly custom) on frontend and AJAX for server updates in XML/JSON format. They were hard to build compared to today, but "less than 10 years" of SPA development is simply incorrect.