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

211–219 of 219 posts

Re: Apollo Layoffs

#211

Post by dventimihasura »

andrewingram wrote: post #210
dventimihasura wrote: post #209

Earlier quoted context omitted.

I'm trying to follow you. Are you saying that different UIs should (or may) have different data models, which themselves are different from but still derived from and related to the persisted data model?

Say you have a web app, an iOS app and an android app. And let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data in the database. It means somewhere between the database and the UI template you’re going to be transforming from one model to another. What you don’t want to do is have the equivalent transformation implemented…

First, let's take these two propositions.

> Say you have a web app, an iOS app and an android app

and

> let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data

Question: If we stipulate that the UI models are different from the persistent model, are the UI models are different from each other or are they they same? What I mean is this. Do the web app, iOS app, and android app models differ from each other? This is important for my reasoning that follows.

Re: Apollo Layoffs

#212

Post by reducesuffering »

dventimihasura wrote: post #205
satvikpendem wrote: post #204

Earlier quoted context omitted.

If you work for a certain company and you recommend it, you should disclose that you work for said company. Your comments are also near copy-pastes of each other so I wouldn't call them merely related at all. For the record I have used Hasura before, both cloud and self-hosted versions. At the time Hasura didn't have serverless functions so it was very difficult to do anything custom even with workarounds. Now it see…

> If you work for a certain company and you recommend it, you should disclose that you work for said company. I see no good reason to accept that proposition. Moreover, I'm not recommending Hasura in this thread (see below). That would be odd, given that I have also said good things about competing products (Potgraphile and Supabase). > Your comments are also near copy-pastes of each other I made 4 comments originall…

> If you work for a certain company and you recommend it, you should disclose that you work for said company.

>> I see no good reason to accept that proposition.

You should absolutely disclose that you work for Hasura when talking about Hasura. Like the other commenter mentioned, this is basic decency on this medium. Failure to do so will reflect very poorly on you and your employer here.

Re: Apollo Layoffs

#213

Post by andrewingram »

dventimihasura wrote: post #211
andrewingram wrote: post #210

Earlier quoted context omitted.

Say you have a web app, an iOS app and an android app. And let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data in the database. It means somewhere between the database and the UI template you’re going to be transforming from one model to another. What you don’t want to do is have the equivalent transformation implemented…

First, let's take these two propositions. > Say you have a web app, an iOS app and an android app and > let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data Question: If we stipulate that the UI models are different from the persistent model, are the UI models are different from each other or are they they same? What I me…

Generally no, they’re not different. For example, the consumer Twitter apps; or when I worked there, Depop.

The situation may change if you also add internal tools to the mix, since they’re often operating on a superset of data that the consumer apps might have access to - though still not necessarily the same model as the persistence layer.

Re: Apollo Layoffs

#214

Post by dventimihasura »

andrewingram wrote: post #213
dventimihasura wrote: post #211

Earlier quoted context omitted.

First, let's take these two propositions. > Say you have a web app, an iOS app and an android app and > let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data Question: If we stipulate that the UI models are different from the persistent model, are the UI models are different from each other or are they they same? What I me…

Generally no, they’re not different. For example, the consumer Twitter apps; or when I worked there, Depop. The situation may change if you also add internal tools to the mix, since they’re often operating on a superset of data that the consumer apps might have access to - though still not necessarily the same model as the persistence layer.

Ok. Thanks for that clarification.

In any case, your requirement can be satisfied by SQL views, which transform the persisted model (tables), and which are 'below' the GraphQL server.

Re: Apollo Layoffs

#215

Post by dventimihasura »

reducesuffering wrote: post #212
dventimihasura wrote: post #205

Earlier quoted context omitted.

> If you work for a certain company and you recommend it, you should disclose that you work for said company. I see no good reason to accept that proposition. Moreover, I'm not recommending Hasura in this thread (see below). That would be odd, given that I have also said good things about competing products (Potgraphile and Supabase). > Your comments are also near copy-pastes of each other I made 4 comments originall…

> If you work for a certain company and you recommend it, you should disclose that you work for said company. >> I see no good reason to accept that proposition. You should absolutely disclose that you work for Hasura when talking about Hasura. Like the other commenter mentioned, this is basic decency on this medium. Failure to do so will reflect very poorly on you and your employer here.

Why? No, seriously. Why? Have I tried to persuade people to use Hasura? No. Have I tried to persuade people that it's good or better than the competition? No. In fact, I only mentioned it in equal terms along with two other competitors, which I DON'T work for (Postgraphile and Supabase, both good products).

What I have done is present not matters of judgment, but matters of fact.

Fact: Apollo is not _the_ GraphQL company.

Fact: Apollo isn't the only one with a GraphQL client library

Fact: Apollo isn't the only path to creating a GraphQL server

As matters of fact, these are either true or false, but readers are free to evaluate which they are on their own. They shouldn't trust me, because I'm a stranger on the Internet. But then again so are you and so are most or all people here.

You say that if I don't disclose who I work for people will trust me less. That's silly, because people here shouldn't trust me at all, nor should they trust you, or anyone else, for the reasons I just gave.

In short: don't accept without careful scrutiny anything you read on the Internet, no matter who says it.

Re: Apollo Layoffs

#216

Post by reducesuffering »

dventimihasura wrote: post #215
reducesuffering wrote: post #212

Earlier quoted context omitted.

> If you work for a certain company and you recommend it, you should disclose that you work for said company. >> I see no good reason to accept that proposition. You should absolutely disclose that you work for Hasura when talking about Hasura. Like the other commenter mentioned, this is basic decency on this medium. Failure to do so will reflect very poorly on you and your employer here.

Why? No, seriously. Why? Have I tried to persuade people to use Hasura? No. Have I tried to persuade people that it's good or better than the competition? No. In fact, I only mentioned it in equal terms along with two other competitors, which I DON'T work for (Postgraphile and Supabase, both good products). What I have done is present not matters of judgment, but matters of fact. Fact: Apollo is not _the_ GraphQL com…

> Apollo Server absolutely can be beat by … https://hasura.io/

> Have I tried to persuade people to use Hasura? No.

> Have I tried to persuade people that it's good or better than the competition? No.

Re: Apollo Layoffs

#217

Post by dventimihasura »

reducesuffering wrote: post #216
dventimihasura wrote: post #215

Earlier quoted context omitted.

Why? No, seriously. Why? Have I tried to persuade people to use Hasura? No. Have I tried to persuade people that it's good or better than the competition? No. In fact, I only mentioned it in equal terms along with two other competitors, which I DON'T work for (Postgraphile and Supabase, both good products). What I have done is present not matters of judgment, but matters of fact. Fact: Apollo is not _the_ GraphQL com…

> Apollo Server absolutely can be beat by … https://hasura.io/ > Have I tried to persuade people to use Hasura? No. > Have I tried to persuade people that it's good or better than the competition? No.

I consider that to be misleading selective editing. Here's a more faithful representation of that missive:

> For the back-end, Apollo Server absolutely can be beat by tools that don't require you to write any code:

> https://supabase.com/blog/pg-graphql

> https://www.graphile.org/postgraphile/

> https://hasura.io/

The careful reader will note that I presented three alternatives, with the one provided by my company last. Moreover, what I wrote is in fact a matter of fact. If you wish to have a GraphQL server without having to write server code to do it, as fine a product as Apollo is you cannot use Apollo to do it because that's not what Apollo does.

Re: Apollo Layoffs

#218

Post by andrewingram »

dventimihasura wrote: post #214
andrewingram wrote: post #213

Earlier quoted context omitted.

Generally no, they’re not different. For example, the consumer Twitter apps; or when I worked there, Depop. The situation may change if you also add internal tools to the mix, since they’re often operating on a superset of data that the consumer apps might have access to - though still not necessarily the same model as the persistence layer.

Ok. Thanks for that clarification. In any case, your requirement can be satisfied by SQL views, which transform the persisted model (tables), and which are 'below' the GraphQL server.

Can be, sure. But SQL, whilst very capable, isn’t the language I’d reach for in order to define my entire business logic layer. Sometimes these transforms are fairly involved and pull in things from multiple data sources and APIs, yes these can be done with advanced SQL wrangling, but at some point you’re just using the wrong tool for the job.

Re: Apollo Layoffs

#219

Post by 0x457 »

adolph wrote: post #148
0x457 wrote: post #100

Earlier quoted context omitted.

There is a sweet spot for how many people should be on a team. That number depends entirely on a nature of tasks. I would even go as far as to say - in a good environment up to that sweet spot, productivity gain is linear. And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything abou…

The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability". https://developers.redhat.com/blog/2022/10/21/coming-terms-t... I think a well composed small team can have greater than linear improvement in effectiveness b…

Huh, didn't know there is a term for that.

What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0.

Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times).

Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you).

You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.

Post reply on HN