storafrid

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.

Yes, but I'm surprised that they attribute "cutting-edge" to Lambda. It's about as old as Docker.

Hi, thanks for sharing. A question: What is the advantage of this approach compared to the tool I'm using right now - continue.dev ?

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?

I hope the automatic price offset is separated out and labeled in the cart/checkout as "Apple's user fee".

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?

I pointed out the lack of description of those incentives.

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.

Do you mean that there is a secret quarterly meeting where Starbucks are lobbying RTO policy to Apple in order for "us big sharks to thrive"?

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.