Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apollo Layoffs

apollographql.com

Post reply on HN
Print view View original

81–90 of 219 posts

Re: Apollo Layoffs

#81

Post by Aeolun »

celtain wrote: post #6
rubyist5eva wrote: post #3

> I am very sad to make this decision. It’s a consequence of the approach that Matt and I took in scaling the company over the last year, and we take full responsibility for the impact that will have on the lives of our departing team members. Why do CEO's always say this empty nonsense. If you accept responsibility, you accept consequences - what consequences is Geoff Schmidt going to be facing? Hurt feelings? Give…

What would you prefer that they say instead? "I made no wrong decisions, I have no regrets leaving all of you unemployed."?

“Some of you will be fired, but it’s a sacrifice we’re willing to make.”

Re: Apollo Layoffs

#82

Post by Aeolun »

quonn wrote: post #50
AtNightWeCode wrote: post #43

Apollo should cease to exist. It is a terrible product and basically designed for being a DDOS attack vector. Never design things like this. They are on the opposite track to the entire web industry.

Can you expand on this? Is this a generic criticism of GraphQL? Apollo server? Client? And what do you mean by opposite track? I really like GraphQL but agree that it‘s not trivial to implement well. I also think it recently became a bit less relevant for web applications (React server components come to mind) but it‘s still very useful for some web apps, mobile apps and generally for designing nice APIs.

I think he takes issue with the theoretically infinite cost of a graphql query.

Re: Apollo Layoffs

#83

Post by nawgz »

AtNightWeCode wrote: post #63
quonn wrote: post #50

Earlier quoted context omitted.

Can you expand on this? Is this a generic criticism of GraphQL? Apollo server? Client? And what do you mean by opposite track? I really like GraphQL but agree that it‘s not trivial to implement well. I also think it recently became a bit less relevant for web applications (React server components come to mind) but it‘s still very useful for some web apps, mobile apps and generally for designing nice APIs.

We use GraphQL a lot for static content. Most content on modern webs should be static, or at least deterministic. What I am saying is that GraphQL should not be used at runtime to do these dynamic magic queries, which is the key feature in Apollo.

> Most content on modern webs should be static, or at least deterministic

What does this even mean?

> What I am saying is that GraphQL should not be used at runtime to do these dynamic magic queries, which is the key feature in Apollo.

What does this even mean?

How are you defining "dynamic magic" and "deterministic content"? GraphQL sends a query to a server that resolves it into the requested data. Is it not true that if you plug this into something like PostgreSQL via Hasura, you naturally have "determinism" in the same way Postgres offers it?

Please, expand, I have no idea what you're saying and I'm a full time web guy

Re: Apollo Layoffs

#85

Post by dudul »

Aeolun wrote: post #82
quonn wrote: post #50

Earlier quoted context omitted.

Can you expand on this? Is this a generic criticism of GraphQL? Apollo server? Client? And what do you mean by opposite track? I really like GraphQL but agree that it‘s not trivial to implement well. I also think it recently became a bit less relevant for web applications (React server components come to mind) but it‘s still very useful for some web apps, mobile apps and generally for designing nice APIs.

I think he takes issue with the theoretically infinite cost of a graphql query.

Maximum complexity control is a thing though.

Re: Apollo Layoffs

#86

Post by leesalminen »

xwdv wrote: post #78
johnvanommen wrote: post #74

Earlier quoted context omitted.

I had a layoff like that, they gave me the option of choosing. Lump sum or "stay on the payroll but have no access." I went with the latter because it paid better. For a while I was always stressed out about background checks, because it showed that I was working two jobs. (I got a job to replace it almost immediately, but continued to get paid by the old place.)

Sorry but where exactly would a background check show you have two jobs?

The payroll companies sell your data to prospective employers sometimes included in a background report bundled deal.

Re: Apollo Layoffs

#87

Post by throwaway019254 »

xwdv wrote: post #78
johnvanommen wrote: post #74

Earlier quoted context omitted.

I had a layoff like that, they gave me the option of choosing. Lump sum or "stay on the payroll but have no access." I went with the latter because it paid better. For a while I was always stressed out about background checks, because it showed that I was working two jobs. (I got a job to replace it almost immediately, but continued to get paid by the old place.)

Sorry but where exactly would a background check show you have two jobs?

Usually company doing a background check calls all your previous employers to verify dates of your employment.

Re: Apollo Layoffs

#88

Post by ctvo »

Aeolun wrote: post #77
tshaddox wrote: post #16

Earlier quoted context omitted.

If you're talking about Brooks's law, that's a pretty specific observation that doesn't seem like it applies here. It's very specifically about adding workers to a project that is already behind schedule. It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."

I’m fairly certain that even without them all working on the same thing, 2.5x more employees will never be 2.5x faster.

Did anyone claim a linear (let alone 1:1) gain?

This was the relevant part of what you replied to:

> It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."

Re: Apollo Layoffs

#89

Post by wintogreen74 »

Rooster61 wrote: post #5

Why are software companies still grappling with the mythical man month? You'd think by now we'd have learned our lesson. More hands /= more productivity, at least on a linear scale

this seems more like a systems problem with a reinforcing and a balancing feedback loop: you're hiring for the future based on current demand, but there's a delay between the syncs of supplying capacity (hiring) and demand.

Re: Apollo Layoffs

#90

Post by subpixel »

trollerator23 wrote: post #39

I have no idea what Apollo Graph QL is, but it was interesting to search by URL and see the progression of related HN titles and their engagement. 2018 July. Apollo server 2 released woo! (mostly ignored) 2019 Feb. We switched away from Slack woo! . . . (Some PRs everybody ignored) 2019 June. We got a $22M investment woo! . . . (Many PRs everybody ignored) 2022 Dec. Oops, we are laying of lots of people...

The folks who made Meteor!
Post reply on HN