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

Launch HN: Scaphold.io (YC W17) – GraphQL Backend as a Service

news.ycombinator.com

Post reply on HN
Print view View original

91–95 of 95 posts

Re: Launch HN: Scaphold.io (YC W17) – GraphQL Backend as a Service

#91

Post by sapeien »

geoffschmidt wrote: post #90
sapeien wrote: post #84

I don't buy into the GraphQL hype. Actually it is a rehash of older technologies like RDF & SparQL, but marketed to a newer generation who didn't know that old things exist. I'd wager that the 20-something "engineers" who designed it didn't give a shit about prior art either. I'm sure that Facebook employees think it solves a lot of problems for them. But I'm not convinced that a single vendor technology is going to…

The GraphQL ecosystem has grown amazingly quickly over the last year. It's definitely not a single-vendor technology at this point. Check out this list of GraphQL libraries, tools, and implementations: https://github.com/chentsulin/awesome-graphql The majority of people who are using GraphQL are using an implementation from someone other than Facebook (on either the client or the server, or in many cases both). (And…

I didn't say that Facebook's reference implementation is the only one (it is in fact the most popular based on downloads), everyone else is performing free labor for Facebook. The point is that they can make any change they want to the spec for themselves and imposing their will, bypassing standards processes because there are none.

>fetching all of the data for a screen in a mobile app in a single round trip without coupling your backend to your UI - and second, the focus on tooling and developer experience

There is no reason why one can't do this with existing web technologies as an additional feature. There was no reason to ignore what already exists and works for the web at large.

I think you should disclose that you are founder of Meteor and have a vested interest in GraphQL. So when is the Facebook acquisition?

Re: Launch HN: Scaphold.io (YC W17) – GraphQL Backend as a Service

#92

Post by ruslan_talpa »

vning93 wrote: post #54
samblr wrote: post #51

Have been trying BaaS lately - few questions. What databases are supported - like can I use oracle database with Scaphold. Is there support for websockets. Why Scaphold ? I see there are many companies in this space since last few years - what unique selling points will help a customer choose Scaphold. Dont you think rise of PaaS will make BaaS redundant easily going ahead. Since BaaS is now a very small layer on top…

Hey those are great questions. To answer them in list order: 1) You currently can't use Oracle DB with Scaphold. We have a hosted database that comes along with each app right from the get-go. 2) There is support for websockets through GraphQL Subscriptions. Each new type that you create in your schema will expose the ability to subscribe to events of that type. 3) There are a bunch of PaaS services that exist out th…

Hi Vince

You said each app comes with a hosted DB, do developers get direct access to this db or is it a big shared one? Are you planning on providing this direct access in the future? Can you disclose the exact DB (MySql/PostgreSQL/MongoDB)?

Congratulations on the launch, you are doing a good job education developers in regard to this new way of building APIs which helps everyone competing in this space (myself included) and the YC backing helps with credibility to this domain. Keep up the good work.

Re: Launch HN: Scaphold.io (YC W17) – GraphQL Backend as a Service

#93

Post by ruslan_talpa »

sapeien wrote: post #91
geoffschmidt wrote: post #90

Earlier quoted context omitted.

The GraphQL ecosystem has grown amazingly quickly over the last year. It's definitely not a single-vendor technology at this point. Check out this list of GraphQL libraries, tools, and implementations: https://github.com/chentsulin/awesome-graphql The majority of people who are using GraphQL are using an implementation from someone other than Facebook (on either the client or the server, or in many cases both). (And…

I didn't say that Facebook's reference implementation is the only one (it is in fact the most popular based on downloads), everyone else is performing free labor for Facebook. The point is that they can make any change they want to the spec for themselves and imposing their will, bypassing standards processes because there are none. >fetching all of the data for a screen in a mobile app in a single round trip without…

While I also have a vested interest in GraphQL (competing in the same space as Scaphold) I agree partially with what you stated above but it's not all that bad as you seem to imply.

Yes, FB does have the power (now) to change the spec over night but so far it was mostly stable and whatever changes were added were only for the better. No new technology comes to life as a standard, it needs someone inventing it, maintaining it, promoting it up to the point where people can get behind it and form a group and make it a standard. Let's give FB a chance, so far it has done an excellent job with the GraphQL standard. On the other hand, graphql-js and Relay are not that stable yet and their interfaces are changing very fast and probably for people that use them it's a bit frustrating but it's only been a year and i bet they will get to a stable interface in 2017 enough for people to be able to really depend on them.

>There was no reason to ignore what already exists and works for the web at large.

GraphQL came to life (and a lot of people adopted it practically over night) precisely because the things that "already existed" did not work really well (REST for SPA/Mobile). When a lot of your business logic (whatever that means :)) moves to the frontend (browser/mobile), the backend API tend to become very complex in order to support the frontend and REST can not express very well that complexity. Whenever people "sell/promote" GraphQL, they bring up 2 main benefits, fetching the data you need in a single request and integrating multiple backends/microservices. If you look at GraphQL only form this perspective i would agree with you that it brings nothing radically new to the table. You can have a REST api flexible enough to be able to get only the data you need in one request (see http://postgrest.com) and you can integrate multiple microservices behind it, we've also seen in the past "typed" schemas (WSDL and things like that).

Imo what makes GraphQL so nice is the the simplicity (Rich Hickey's definition), how you immediately get what a query does, how it relates to JSON and the shape of the response you get back. Making something "simple" is very hard work and i think FB nailed it.

Re: Launch HN: Scaphold.io (YC W17) – GraphQL Backend as a Service

#94

Post by vning93 »

ruslan_talpa wrote: post #92
vning93 wrote: post #54

Earlier quoted context omitted.

Hey those are great questions. To answer them in list order: 1) You currently can't use Oracle DB with Scaphold. We have a hosted database that comes along with each app right from the get-go. 2) There is support for websockets through GraphQL Subscriptions. Each new type that you create in your schema will expose the ability to subscribe to events of that type. 3) There are a bunch of PaaS services that exist out th…

Hi Vince You said each app comes with a hosted DB, do developers get direct access to this db or is it a big shared one? Are you planning on providing this direct access in the future? Can you disclose the exact DB (MySql/PostgreSQL/MongoDB)? Congratulations on the launch, you are doing a good job education developers in regard to this new way of building APIs which helps everyone competing in this space (myself incl…

Hi there, great questions. Developers currently do not get direct access to this db, and we are thinking about ways to allow you to do so in some fashion in the future.

The db that we use is Amazon Aurora MySQL db.

Thanks for the support!

Post reply on HN