Launch HN: Scaphold.io (YC W17) – GraphQL Backend as a Service
At the time, we were working at Microsoft and started hacking on what eventually became Scaphold at night and on weekends. We were driven by this vision to be the foundation for people's apps, the scaffolding of their masterpieces. We were lucky to get accepted into the YC Fellowship program last April and launched our first version of Scaphold last May. We learned a lot. The Fellowship program helped us gain initial traction and after several months of focusing on product and strong growth, we reapplied to the YC Core program and were fortunate enough to be given an opportunity to join the winter batch and to continue the dream.
Since then we have been hard at work improving the platform and have reconstructed it from the ground up. Today, Scaphold powers thousands of apps and we think it solves a lot of the problems of BaaS platforms that came before it. We're really excited about what we have built and would love for you to try it out. It's free to sign up and development tier stays free forever so you can get straight to building apps.
We'd love to hear your feedback and are happy to answer any questions. Thanks!
94 comments
[ 4.5 ms ] story [ 209 ms ] threadAlso, is this a special type of post to allow links in top level story description? Regular Ask/Show posts don't get http:// links auto formatted into links.
https://news.ycombinator.com/item?id=13366964 was the first one, and this is the second one, so far.
They'll still have voting and commenting like regular stories.
Edit (2020): in the end, I didn't get around to writing that code and users didn't turn out to mind the occasional case where a launch ad and a job ad are on the front page at the same time. If it becomes an issue at some point, we can still implement that bit.
For this to succeed they'll need to add a lower level interface to the mix. Something like AWS' Lambda.
Question for the founders, will there be an extension platform, something like Parse cloud or the Heroku app store?
In a real app you would want to first validate the email, then make sure the user has permission to join the team, then persist the object to the database, then using the generated ID create an M-M association with the team and maybe even asynchronously send push notifications to all the other users in the team. Flows like this are why we built Logic. You can host your business logic anywhere and Scaphold essentially acts as a runtime for your microservices.
This new feature is particularly powerful so I'd be happy to discuss it more in depth if you'd like.
Yep, and that's because they solve a really really challenging problem you can almost never solve yourself, whether it's payment processing or search.
Creating a simple barebones back-end may be tedious (though I'll argue it's trivial), but it will never be an unsolvable problem for many. Maybe for pet projects, but never for any critical production applications.
It is true that companies can often build their own backends but it is often extremely time consuming and expensive. It takes time to develop these systems and build them to scale and often they run into a problem where early assumptions change while the underlying system is hesitant to.
One of the core value props of a platform like ours is the speed at which you can iterate and develop something while also being given the tools to pivot when you need to. We are focused on building features that allow you to extend the platform to make it achieve what you need so that you can spend more resources developing the value that is important to your customers instead of the pipes underneath.
Of course our solution cannot work for everyone but the companies that we have worked with thus far have told us that increased their application throughput by 8x compared to when they built backend themselves with frameworks like rails/django/node.
Our mission is to make software development like playing with Lego. You're combining existing services like Stripe, Algolia (...) to quickly build your own applications. GraphQL is the common denominator between all these components and provides an incredible developer experience.
On a more general note what distinguishes Graphcool from other services: We're optimizing for the best possible developer experience (DX) while maximizing the degrees of freedom what's possible to build with Graphcool.
I think the focus on integrating with a variety of services really plays to the strengths of GraphQL, and addresses some of the concerns people usually have with backend as a service platforms!
But their generated Schema felt better to me. getUsers instead of this viewer stuff, feels much cleaner.
But the generated Schema is nice if you don't use Relay.
However, at second glance, you could argue that Scaphold actually creates a new take on PaaS. Previous services have faltered at trying to do too much in one platform by essentially wrapping and containing all the services you need underneath one shell. So we're treading in unfamiliar territory where we think there's actually a lot more value in providing an interface for all your data across the web, as opposed to a complete wrapper around it in a self-contained manner. This way, developers can actually get the best of both worlds:
1) Having the benefits of using a backend as a service platform that offers value-added services like hosting, performance monitoring, tooling, app management, etc. And... 2) Flexibility in picking and choosing what services you need (like Auth0 or Stripe), tying in your own custom logic (through a provider like AWS Lambda), and even perhaps the database layer as well.
Essentially, the vision is to allow developers to think as if they were rolling their own backend, while stripping out the time-consuming aspect of connecting these pieces manually. It's a much more modular approach where we sit as the hub of all your data across the web.
To bring this back to the original point about TAM, this would ultimately open the door for us to a much larger market that includes any cloud service customer since they're not married to Scaphold as a backend. Scaphold essentially becomes an extremely versatile way to tie in your data that's hosted just about anywhere and combine it with the existing services you already use. That also reduces the pieces that we have to manage as well.
My answer is by no means supposed to be a definitive way of thinking about TAM, but merely one way that we're evaluating it. If you or anyone reading this has any thoughts on this, we'd love to talk more privately about this and the direction we're taking Scaphold.
The new custom logic feature is looking great but what if I want to implement a custom query or mutation that isn't necessarily tied to a `Node`?
For example, what if I wanted to add a query that ran a ranking algorithm and returned a feed?
Forgive me if I am simply uninitiated, but what are the general advantages of graphQL over a typical backend powered by a SQL database?
One of the biggest promises of GraphQL is in its ability to consolidate disparate data and this I think is how we are going to stand out from the BaaS platforms that have come before us. This is just the beginning. The GraphQL type system opens up so many possibilities in the types of developer tools that people can build. Apollo (http://www.apollodata.com/) is already building amazing tools and expect to see more from many more companies.
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 of PaaS.
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 there, but the speed at which you build apps on Scaphold is undoubtedly faster. We give you the ability to think about your data in a modular way by appending large pieces of functionality to your app without having to write any server-side code. But you also get the flexibility to bind your custom logic to the same API through your own hosted microservices. Out of any BaaS platform on the market, we provide the most feature-rich platform that can actually help you launch into production and scale to large workflows. So far we already have a few large customers aboard and growing fast.
If you're interested to hear more about our feature set, I'd love to chat with you more directly about your specific use cases and see how we can address those. Feel free to join our Slack and PM me directly (http://slack.scaphold.io). I'm @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.
The db that we use is Amazon Aurora MySQL db.
Thanks for the support!
We’ve tried all available GraphQL BaaS and now use Graphcool which doesn’t have all the features Scaphold provides but the ones they have are very stable and mature. Also their API seemed by far the best one we’ve tried yet (e.g. they are providing an extra endpoint for Apollo client).
To your point about the extra endpoint, I know they have different ones for simple, Relay, files, and from what you're saying not Apollo Client. To me personally, it seems a bit counterintuitive that they offer so many different endpoints when one of the premises of GraphQL was to have a single endpoint that was decoupled from the client. Open to your thoughts here to see how we can improve your experience as a developer from the client perspective!
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.
We want to get the best information from HN and not advertisements.
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, the (gorgeous) site feels similar to if Shopify had launched with messaging focused on its use of Rails on the backend.
It feels like you could also be targeting the type of less-sophisticated business programmers for whom VBA is often a weapon of choice. However, when I read your site, the fact that I don't use GraphQL makes me want to move on.
Anyhow, best wishes again on your launch!