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

21–30 of 95 posts

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

#21

Post by chrdlu »

hiraki9 wrote: post #16

How did you find your first customers, and how did you get them to trust you enough to build their apps on your infrastructure?

I found them after Parse shut down. I tested them out with a small meeting for coffee app and found it to work very well. After the recent add of custom logic via AWS Lambda, I am using them to build a larger travel app.

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

#24

Post by mparis »

hiraki9 wrote: post #16

How did you find your first customers, and how did you get them to trust you enough to build their apps on your infrastructure?

Hey that is a great question. Our very first customers were actually some of our friends. We promised them free service for their trust which helped us identify pain points and iterate before we initially launched last May. Since then we have seen a lot of our users find us through tutorials and other educational content that we've written. In terms of how we got users to trust us, Slack has been an invaluable tool. We have a really friendly community of developers that we speak to every day and I think that has gone a long way to developing trust. It wasn't always smooth sailing and the platform has grown a lot but we try to be as transparent as possible and address problems as soon as they arise. We've dedicated a lot of time to building out our architecture, security, and scalability and I'm happy to discuss that with those interested. We are really passionate about what we are building and we hope that our customers see that and can rest easy knowing that we are working around the clock to make sure their applications run smoothly.

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

#26

Post by baby_wipe »

mparis wrote: post #14
tschellenbach wrote: post #9

I just don't believe in the 1 backend to rule them all approach. Services like Stripe, Algolia, Datadog, Pusher, Mapbox, Imgix etc all make a lot of sense. It's easy to plug them in to your existing backend and extend your app's functionality. Using someone else's backend for your app is a terrible decision though, the lock-in is just too large. For this to succeed they'll need to add a lower level interface to the m…

Hey that is great feedback! To address your point about the lower level interface, as part of today's launch we released our Logic features that lets you do exactly this. The new features allow you to add compositions of custom microservices to any mutations in your Scaphold API. For example, assume you were building Slack and you were setting up the createUser onboarding flow. A new user might be invited to Slack an…

But I've found this is where you start to want a full-blown web framework, at least in my experience. Logic sounds very close to what Cloud Code is on Parse Server, is that right?

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

#27

Post by vning93 »

mparis wrote: post #24
hiraki9 wrote: post #16

How did you find your first customers, and how did you get them to trust you enough to build their apps on your infrastructure?

Hey that is a great question. Our very first customers were actually some of our friends. We promised them free service for their trust which helped us identify pain points and iterate before we initially launched last May. Since then we have seen a lot of our users find us through tutorials and other educational content that we've written. In terms of how we got users to trust us, Slack has been an invaluable tool.…

Feel free to join our Slack as well if you haven't already. You can invite yourself here: http://slack.scaphold.io/

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

#28

Post by vning93 »

bh13731 wrote: post #25

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

Thanks for the support! If you have some time, would love for you to check out Scaphold as well. With the latest release of our custom logic workflows, we're feature-complete and can handle real workloads that require advanced permissioning, real-time subscriptions, performance monitoring, and more.

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

#29

Post by vning93 »

chrdlu wrote: post #21
hiraki9 wrote: post #16

How did you find your first customers, and how did you get them to trust you enough to build their apps on your infrastructure?

I found them after Parse shut down. I tested them out with a small meeting for coffee app and found it to work very well. After the recent add of custom logic via AWS Lambda, I am using them to build a larger travel app.

Great to hear that things are working out well for you! Let me know when you launch. Would love to show it off on our community page.

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

#30

Post by mparis »

baby_wipe wrote: post #26
mparis wrote: post #14

Earlier quoted context omitted.

Hey that is great feedback! To address your point about the lower level interface, as part of today's launch we released our Logic features that lets you do exactly this. The new features allow you to add compositions of custom microservices to any mutations in your Scaphold API. For example, assume you were building Slack and you were setting up the createUser onboarding flow. A new user might be invited to Slack an…

But I've found this is where you start to want a full-blown web framework, at least in my experience. Logic sounds very close to what Cloud Code is on Parse Server, is that right?

It's similar but we think it improves upon cloud code in a couple of ways. We designed logic after techniques that we use internally to create robust, yet maintainable GraphQL resolvers. Mainly that means we structure each resolver as a composition of functions. This means that the functions in the composition associated with the mutation are able to pass information down the chain giving you a lot of flexibility in how you implement features with microservices. Another distinction from cloud code is that you can use virtually any stack. You can host logic using a full fledged web framework like Rails or you can use new serverless services like lambda. This also gives a lot of flexibility and lets you reuse existing infrastructure if you have it. The comparison is a fair one but we still have a few features in store that will keep building on the functionality and hopefully make the distinction more apparent :)
Post reply on HN