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.
The author states that in their experience, most downstream services are REST, so adding a GQL aggregation layer on top isn't very helpful. It seems possible they would have a different opinion if they were working with multiple services that all implemented GQL schemas.
In that (common) case, the advantage is the frontend/app developers don’t need to know what a hot mess of inconsistent legacy REST endpoints the backend is made of, only the GQL layer does. Which also gives you some breathing room to start fixing said mess.
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 worked for a company that went all in on Lambda as well. The knots they had to twist themselves into so that everything ran nice and smooth in Lambda environment was mindboggling. We have certain actions like orders that would pass through 8 Lambdas before completion because of execution time or just the big code base would result in 7 seconds start up time (node) so it would get broken down. If any of them failed, and it felt like failed a ton due to Amazon backend stuff, it was a nightmare to resolve.
All of it could probably been handled by larger node application in docker container somewhere but AUTO SCALING, FAILOVER, SERVERLESS!
Once I started as SRE for a new team, we built a larger monolith using Node and docker on EC2. We would get massive complements for our uptime and reliability but there were some architects extremely unhappy when I revealed in division presentation that it was just Docker + m4.xlarge running Ubuntu 18.04. When I left, more and more Lambdas were being broken down into docker running on EC2. They are probably on some container managed solution now.
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.
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?
Debouncing is a known development tool for most non-immediate actions. It's related UI concept of locking individual UI elements is also well understood by many users (not by that technical name, but by "it's working on my action" kind of understanding).
> optimistically show the user a success result?
I don't particularly like React, but this a core feature of such JS frontend frameworks, optimistically "succeed" while async network and back-end work happens to give the illusion of speed: https://react.dev/blog/2024/04/25/react-19#new-hook-optimist...
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.
From my perspective there was nothing rhetorical about that question as I occasionally encounter it as a serious thing. Some colleagues really do not want optimistic UI events. Some swear by them.
I don’t have any strong feelings one way or another as long as there is proper inline feedback.
Came here for exactly this, the post is proposing a solution while only understanding one half of the problem.
Toasts are a global UI feedback mechanism for non-blocking/fallible/undo-able actions. That does make them out-of-place by default, but at least consistently so.
A solution I'd accept is local-view-first with toasts-as-fallback when the view is dismissed. That said, loading indicators _might_ make users hesitant to dismiss a view.
This isn’t allowed in the US, not sure about the new EU rules regarding this specifically. Best they can do is show a “deduction” only on web/other platforms that shows they’re getting it cheaper than iOS iirc.
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.
Believe it or not, once you start hanging around in management circles, you'll learn there are modes of communication that despite not involving direct exchanging of words between two individuals, nevertheless, conveys information. In fact, people are selected for the management class many times for their lack of acknowledgement of said mechanisms, as it gives everyone else the cover they need to play ignorant when, having toyed with the levers of power causing something bad to happen, they can play the ignorance card.
So no. They are not asserting that everyone has a secret meeting at midnight. They are pointing out the incentives and dependencies that lead to a pathological state; one that creates a hell of a pot of institutionsl inertia against a WFH paradigm shift.
I think not, there are some official meetings, like those hosted by the WEF, casually renamed https://www.worldgovernmentsummit.org to be a bit more modest but there is no special need to meet someone like you to understand your common interests. If you are a blacksmith you know your "cohort" interests without the need to meet some competitor/colleagues. You might occasionally meet them anyway, for lobbying, for a common cause (like the farmers against John Deere for the right to repair their tractors, or to be more precise the tractors they have bought but they do not really own anyway), some meetings might be public, some others behind closed doors, but the common interests of a category are well known by all belonging to that category.
The cohort who seems unable to understand it's own common interests are the 99% of the people who apparently, as usual, fails to see where are their enemy and their potential allies, regularly fighting against their own interests...
I suggest if you have a bit of patience an old book from 1841 by Clinton Roosevelt, The Science Of Government, Founded On Natural Law, it's strange at first bug get clear quickly and it's very fast to read: https://dn790002.ca.archive.org/0/items/sciencegovernme00roo... try and you'll see in a succinct and crystal clear the TODAY world, economy, with anything we have. Another good reading would be Eduard Bernays Propaganda and to complete the game a bit of modern network theory like some Albert-László Barabási.
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?
In particular, because they are the most impacted, but it's still valid for all big financial actors starting from real estate.
> This is what sounded like conspiracy to me.
A conspiracy typically is made by some who want to overthrow and substitute a power not by the those who rules against their subjects, that's instead called political agenda. As opposite to a conspiracy it's mostly public, the "sharing economy" is described everywhere, the industrie 4.0 is even a book (more than one), and so on. The agenda can be described simply as "you'll own nothing" where the "you" part means those who pronounce such sentence count to own anything and "rent" anything. In the IT world the cloud+mobile "the sole integrated platform" (actually not at all, but that's what advertised) have already "users" who own essentially nothing and very few giant owners, big enough to steer the IT world simply with their developments, in the physical world it's slowly happen "hey, try our new shiny autonomous taxis", "you do not need a car, just use our app and a car will arrive to bring you whatever you want", obviously the toward-rent trends in cities for both commercial and personal real estate that obviously does not fit much in a spread society, the ready made food downtown for the commuters instead of eating at home what personally prepared, to the point many new city "goshiwon alike" condos have essentially no kitchen but just a small fridge for bottled drinks and something to quickly heat already made food, no dishwasher, common washing machines with some kind of card-based auth to use in the condo basement and so on even "smart locks" for apartments and main entries. It's definitively NOT a conspiracy since it happen under plain Sun light publicly advertised as a good and needed evolution.
But it's not that easy to made people owning nothing, accepting things like abolish the concept of inheritance (a relatively recent PR trend, with some famous testimonials) before, stating that anyone should start with his own arms in an open arena, now stating that successions taxes should exists and be higher and higher, selling "property rights" time limited at 99-years and so on. Remote work is the rock in a running mechanism, because if it spread it obviously push most remote workers outside the expensive, degrading and chaotic city, and actually in the western world potential remote workers are a very BIG slice of the population, also a wealthy and acculturated slice. So the obvious political need is to stop it or the entire big actors common interest informal agenda will derail.
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.
