Live data from Hacker News

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

news.ycombinator.com

81–90 of 95 posts

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

#81

Congratulations on launching Scaphold. I tried my hand at founding a Node.js PaaS startup (NodeSocket)[1] in 2011, and while promising in terms of attention, silicon valley media, VC meetings, there was never a path to a sustainable PaaS business. Howerver, things have changed. Technology and mindsets have evolved, and Firebase, Parse, and Serverless.com have shown there is perhaps a future in BaaS. My only words of…

Thanks for those words of advice! We'd love to talk more about this and hear more about your experience with nodesocket. If you're interested please feel free to email me at michael@scaphold.io and we can setup a call!

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

#82

How do you solve the problem of different clients needing different permissions (i.e. one user shouldnt be able to query for a different users data)? Took a quick look through the website and didnt see anything about that, sorry if I missed it. That aside, it looks pretty cool! Good job!

Great question. We have a variety of ways to implement permissioning. You can get pretty granular with how you wish to implement your rules whether they be role-based or relational. Feel free to poke around our docs here to learn more about the use cases for each with examples: https://scaphold.io/docs/#permissions-authorization

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

#83
post #73
post #72

Earlier quoted context omitted.

And how much of the "rapid app development" messaging were you able to glean away from checking out our site? Was it confusing for you not having known what GraphQL was upon reaching our page?

Not the OP, but I also didn't know what GraphQL was/is and had to watch your video before fully realizing what you were offering.

Got it, thanks for the feedback. It's a fine line between placing too much emphasis on GraphQL as a technology that empowers us vs. sending the message that we're a rapid app building platform. But we'll certainly make that more clear.

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

#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 be viable on the web. Web standards come about through standardization processes, with multiple stakeholders reviewing and revising drafts. Facebook one day puts up the GraphQL spec out of nowhere and defines the "standard" by themselves, based on their own implementation.

A little history: Facebook tried to subvert HTML with FBML, a proprietary markup language designed for use within the Facebook ecosystem. Long story short, it didn't work out. The various SDKs and APIs by Facebook have been notoriously unstable.

People tend to excel at short-term thinking, kudos to Facebook for that, and lack the foresight for long-term thinking, except for a few visionaries. The architecture of the web has lasted a few decades already, it will outlast a single vendor specification.

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

#85
post #47
post #25

I've been using a similar service https://www.graph.cool for a while and it's been amazing. Good luck guys.

Thank’s for the support bh13731! If anybody has tried both Graphcool and Scaphold I would love to se an objective comparison between the two services.

The UI of graph.cool is a bit clunky.

But the generated Schema is nice if you don't use Relay.

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

#86
post #56

Edit: on reflection, I reversed this and put the original comment back ( https://news.ycombinator.com/item?id=13476120 ). I don't think it's in very good taste to promote your thing in someone else's launch thread. We detached this comment from https://news.ycombinator.com/item?id=13474424 and marked it off-topic.

I think it's bad taste to do this kind of moderation.

We want to get the best information from HN and not advertisements.

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

#87
post #54
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…

Thank you for the reply.

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

#88
post #86
post #56

Edit: on reflection, I reversed this and put the original comment back ( https://news.ycombinator.com/item?id=13476120 ). I don't think it's in very good taste to promote your thing in someone else's launch thread. We detached this comment from https://news.ycombinator.com/item?id=13474424 and marked it off-topic.

I think it's bad taste to do this kind of moderation. We want to get the best information from HN and not advertisements.

On reflection, you're right—that was a mistake on my part. Sorry! I've put the comment back.

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

#89
post #66
post #63

Congratulations on your launch! Please take this constructively, but I can't help but think that the prevalence of GraphQL in your messaging is a huge distraction. It seems like the real value in Scaphold is letting people build applications faster, with less effort. In fact, in your post's description of the problem you're solving, you don't mention GraphQL at all (until you start talking about solutions). Right now…

Thank you for that note. I think there is a lot of room for improvement in our messaging and we will take this to heart. I'm glad you were able to understand the value prop from our description and you are exactly right that our core value is rapid application development. We are solely focused on a building a platform that is both easy to start and that is capable of growing with your business. Thanks again.

So many great questions and well wishes in this thread, allowing them to explain and market their product in detail. Am I alone in finding this attention to be totally contrived? Other products are launched and get zero attention. Or is it a benefit of being in the YC machine that you get so much FREE support?

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

#90
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 for what it's worth, I did see a "Why not RDF" slide in one of Lee Byron's decks, and those of us at Meteor who are working on GraphQL are definitely aware of the RDF/SparQL roots. I think what's driving GraphQL's growth is, first, it addresses a very timely problem - 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 which has been a weakness for SparQL.)

Post reply on HN