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

201–210 of 219 posts

Re: Apollo Layoffs

#201

Post by satvikpendem »

dventimihasura wrote: post #196
satvikpendem wrote: post #180

Earlier quoted context omitted.

Urql client is great, however for the backend, Apollo Server really can't be beat, at least for a NodeJS backend.

Rubbish. For the backend, 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/

Do you work for Hasura, based on your username? You've been spamming the same comment looking at your comment history.

Anyway, these are all tools to generate a backend based on your database which might work for simple situations but breaks down for more complicated ones. I also don't want to give my backend away to Hasura or Supabase either.

Re: Apollo Layoffs

#202

Post by amrocha »

UncleMeat wrote: post #188
amrocha wrote: post #71

Earlier quoted context omitted.

"Institutions that can weather the storm" like Google? Like Facebook? Amazon? The entire industry has had layoffs, regardless of size. In fact, in my experience there's plenty of startups that are still growing and hiring the laid off talent from the big institutions. Apollo was not one of those companies, but it doesn't seem like it being a startup had any impact.

Google hasn't had layoffs in meaningful quantity.

You're right, my bad. Most big companies have had them so I must have somehow thought Google did too.

Re: Apollo Layoffs

#203

Post by dventimihasura »

satvikpendem wrote: post #201
dventimihasura wrote: post #196

Earlier quoted context omitted.

Rubbish. For the backend, 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/

Do you work for Hasura, based on your username? You've been spamming the same comment looking at your comment history. Anyway, these are all tools to generate a backend based on your database which might work for simple situations but breaks down for more complicated ones. I also don't want to give my backend away to Hasura or Supabase either.

Yes. I do work at Hasura. Why is that relevant?

No. I have not been spamming the same comment. I have made several related comments, which I'm free to do just as anyone else is.

Now, YOU'RE free not to use Hasura Cloud (a fine cloud-managed product by a company I work for) or Supabase (a fine cloud-managed product by a company I don't work for). You're also free to use Hasura CE (a self-hosted OSS Docker image), Supabase (another self-hosted OSS Docker image), or Postgraphile (another self-hosted OSS Docker image) if you don't want Hasura or Supabase to host your application. You're even free to believe these tools work only for simple situations but break down for more complicated ones. The thing is, other people are equally free to make other judgments.

Re: Apollo Layoffs

#204

Post by satvikpendem »

dventimihasura wrote: post #203
satvikpendem wrote: post #201

Earlier quoted context omitted.

Do you work for Hasura, based on your username? You've been spamming the same comment looking at your comment history. Anyway, these are all tools to generate a backend based on your database which might work for simple situations but breaks down for more complicated ones. I also don't want to give my backend away to Hasura or Supabase either.

Yes. I do work at Hasura. Why is that relevant? No. I have not been spamming the same comment. I have made several related comments, which I'm free to do just as anyone else is. Now, YOU'RE free not to use Hasura Cloud (a fine cloud-managed product by a company I work for) or Supabase (a fine cloud-managed product by a company I don't work for). You're also free to use Hasura CE (a self-hosted OSS Docker image), Supa…

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 seems Hasura has serverless functions now but now I feel that I shouldn't need to tie my backend and code to a database product lest anything happen to said product, lock-in sucks. That they are OSS or self-hosted does not make them any less susceptible to lock-in. I could also use, for example, Vue, also an OSS product, but if something happens to the primary contributor and no one else wants to maintain it, now I either have to deal with bugs slowly creeping in over time or rewrite my frontend.

So, no thanks, I'd rather keep my own backend and not use a BaaS product.

Re: Apollo Layoffs

#205

Post by dventimihasura »

satvikpendem wrote: post #204
dventimihasura wrote: post #203

Earlier quoted context omitted.

Yes. I do work at Hasura. Why is that relevant? No. I have not been spamming the same comment. I have made several related comments, which I'm free to do just as anyone else is. Now, YOU'RE free not to use Hasura Cloud (a fine cloud-managed product by a company I work for) or Supabase (a fine cloud-managed product by a company I don't work for). You're also free to use Hasura CE (a self-hosted OSS Docker image), Supa…

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 originally:

1. rejecting the claim that Apollo is "_the_" GraphQL company: https://news.ycombinator.com/item?id=34007957

2. rejecting the claim that Apollo client is the only one to use: https://news.ycombinator.com/item?id=34008121

3. answering the question of what to use on the backend besides Apollo: https://news.ycombinator.com/item?id=34018101

4. rejecting the claim that Apollo can't "be beat" on the backend: https://news.ycombinator.com/item?id=34018095

Numbers 3 and 4 are similar but not the same, given their contexts.

For the record, Hasura has never had serverless functions. It never had them before and it still doesn't have them now. We view that as a product decision, but you're free to view it however you like. As for your other reasons for not wanting to use Hasura, you're free to have them just as others are free to reject them. My objective has never been to persuade people to use Hasura. Use whatever you want. My objective was counter claims that I believe are untrue.

Re: Apollo Layoffs

#206

Post by andrewingram »

dventimihasura wrote: post #200
andrewingram wrote: post #198

Earlier quoted context omitted.

Personally I wouldn’t advocate for these as I don’t believe it’s a good idea to automatically generate a GraphQL schema based on your database (I haven’t worked on anything in years where this would’ve been a good idea). But YMMV as always.

Can you give reasons for why you believe that?

In a world where you have multiple clients, you want to minimise duplicate work of derived state. Unless your UI-level data model is 1-1 with your persistence layer (rare, in my experience), there’ll need to be a transformation somewhere, and since your GraphQL server provides a common interface for UI clients, this transformation should happen at or below the GraphQL layer.

Re: Apollo Layoffs

#207

Post by satvikpendem »

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…

> I see no good reason to accept that proposition.

It's basic decency on Hacker News or elsewhere. Feel free to accept it or not but know that others will think less of your comments' veracity and trustworthiness by not doing so.

> * 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).*

Even if you recommend other products, merely linking to it in a list while not disclosing you work there is distasteful.

> I made 4 comments originally:

Regardless of what the claims you were responding to were, your comments themselves for 3 and 4 are copy pasted in content. That is what someone means when they say one's comments are copy-pastes, or said another way, spam. Out of 4 comments, if 50% of them are the same, that's pretty spammy to me.

> For the record, Hasura has never had serverless functions. It never had them before and it still doesn't have them now.

That's funny, I just googled it now and it does seem to have support for them, at least a page that says so. If that's not really using serverless functions (while literally being titled "Using serverless functions") then perhaps they should change the title and clarify the content [0]. I also don't mean that Hasura should have serverless functions itself, like AWS Lambda, I meant that there was not a good way to trigger database events and if you wanted to write custom logic, the recommended way was running a whole other server, which at that point, I'll just write my own backend myself [1].

All this leads me to believe you're shilling for Hasura, don't actually work there, or some combination of both.

[0] https://hasura.io/docs/latest/event-triggers/serverless/

[1] https://news.ycombinator.com/item?id=23320711

Re: Apollo Layoffs

#208

Post by dventimihasura »

satvikpendem wrote: post #207
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…

> I see no good reason to accept that proposition. It's basic decency on Hacker News or elsewhere. Feel free to accept it or not but know that others will think less of your comments' veracity and trustworthiness by not doing so. > * 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).* Even if…

> That's funny, I just googled it now and it does seem to have support for them, at least a page that says so

That documentation page says that you can use serverless functions with Hasura, which is true. Hasura custom events call a web-hook, which can be and often is implemented with a serverless function, thought it need not be.

> I also don't mean that Hasura should have serverless functions itself, like AWS Lambda

Thank you for clarifying.

> your comments themselves for 3 and 4 are copy pasted in content

No. I typed out comments 3 and 4 independently "long hand." No copy/paste was involved, save for copying the URLs over.

As for the rest...let's just score that as "a difference of opinion" and call it a day, shall we?

Re: Apollo Layoffs

#209

Post by dventimihasura »

andrewingram wrote: post #206
dventimihasura wrote: post #200

Earlier quoted context omitted.

Can you give reasons for why you believe that?

In a world where you have multiple clients, you want to minimise duplicate work of derived state. Unless your UI-level data model is 1-1 with your persistence layer (rare, in my experience), there’ll need to be a transformation somewhere, and since your GraphQL server provides a common interface for UI clients, this transformation should happen at or below the GraphQL layer.

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?

Re: Apollo Layoffs

#210

Post by andrewingram »

dventimihasura wrote: post #209
andrewingram wrote: post #206

Earlier quoted context omitted.

In a world where you have multiple clients, you want to minimise duplicate work of derived state. Unless your UI-level data model is 1-1 with your persistence layer (rare, in my experience), there’ll need to be a transformation somewhere, and since your GraphQL server provides a common interface for UI clients, this transformation should happen at or below the GraphQL layer.

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 3 times — once per app; instead you want to do this transform at or below the common interface that they call operate against, ie the GraphQL server.

In my experience it’s very uncommon for anything other than simple prototypes to not have at least some divergence between the UI model and the persistence model.

Post reply on HN