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.

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.

Yeah right, "Just the Facts". With text like this: "I am willing to outright say that ... the removal was ... massively botched."

Replacing Google Photos with hard drives? What. And replacing Google Drive with a client-based sync tool...? Maybe too high expectations but I was hoping for some level of similar functionality.

Would be interesting to get advice on how an actual user of the Google ecosystem can do this kind of move. There are a lot of applications to research, e.g. Photoprism for replacing Google Photos. A bit overwhelming to review the options and make feature/setup comparisons, considering how many products I use on a daily basis. But it would be nice indeed, to own the data. If the overhead is manageable.

Source confirming your statement, please, that Tegnell has been "wrong about almost everything". Because that is false and this is not Reddit.

In my opinion he _lacks_ charisma. He's just a scientist. Which is good.

Lots of bashing here. Please provide clear examples, based on facts. I'm not very interested in how complex you think serverless architecture seems to be. Instead, let us know: What did you try, what was the aim, why did you choose serverless, what was your experience, what did you learn? Make an addition to the discussion.

I'm a solution architect in an environment where 20 teams of five developers each are deploying API- and web-oriented code daily, and have been for a year, on a 100 % serverless architecture. The teams are able to deliver MVPs within days, from scratch. We don't pay for any allocated capacity, only usage. Aside from bonuses such as being able to spin up a complete set of services as a temporary environment, in minutes and for free, the production environment is also incredibly cheap.

I can't say whether this stack would have been as effective if we weren't at the size of benefitting from a microservice way of working, with independent team responsibilities and explicitly defined ownerships. But what I can say is that in my 12+ years in IT, I've never seen developers be this productive. Especially considering the complete development lifecycle.

I'm sure plenty of this would have been possible using a traditional architecture, but having 500 lambdas in production and knowing that you can go home and not get a phone call... pretty nice. The reason being that they are small and thus easily testable and securable, in addition to the obvious (fully managed, auto-scaling etc).

We've had to solve issues of, course. Some silly, some unfortunate. But I wanted to provide a counterweight to the apparently popular opinion that serverless is complicated. To me, that's like looking at a car and complaining that it's more complicated than a train. Both have their use cases.

"Terms of use" returns 404, which I find bit funny for a service in a gray zone

I felt there was so much potential for that movie! The plot in e.g. AC2 is intricate. It's easy to stand on the sideline of course — I understand that this stuff is really hard to get right. It obviously is. But in my opinion, an actually great movie, movie series or series based on the plot lines in AC is still a good idea.

How would you define "overvalued"? Is it the current average price compared to a very low price three months from now? What if it recovers a few weeks after that — would that change the fact that it was once "overvalued"? Valuation is not based on nothing, in vacuum. The challenge is to understand the underlying factors. The post you replied to actually tried to shed some light.

I still have my reading list from when I started out with React. Here are some of the most valuable resources that helped me grok React: http://krasimirtsonev.com/blog/article/react-js-in-design-pa... http://chibicode.com/react-js-introduction-for-people-who-kn... https://medium.freecodecamp.com/the-5-things-you-need-to-kno... https://www.fullstackreact.com/30-days-of-react/

These also helped to understand specific React concepts: https://medium.com/@dan_abramov/smart-and-dumb-components-7c... https://medium.com/@dan_abramov/mixins-are-dead-long-live-hi...

Related tech but also helped me learn React: https://brigade.engineering/what-is-the-flux-application-arc... https://egghead.io/courses/getting-started-with-redux

If the company finds a person that they want to recruit, and that person happen to live in a high-cost location, they will need to pay up in order for the recruitment to happen. The only alternative would be to offer relocation to a lower-cost region. It doesn't have anything to do with any requirement. It's just a result from the way the world works.

I'm not hearing a counter-argument. The company needs to get good people to work for them. And this is a way of getting someone from a high-cost location to work for them. If the location's higher living expenses aren't covered for, the person would be unable to take the job. I don't know if you mean that the company should adjust their lowest pay according to the world's most expensive location, but that would probably not sustain the business.