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!
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?
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.
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.
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.
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!
But the generated Schema is nice if you don't use Relay.
But their generated Schema felt better to me. getUsers instead of this viewer stuff, feels much cleaner.
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.
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.
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.
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.)
>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?
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?
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.
https://news.ycombinator.com/item?id=13366964 was the first one, and this is the second one, so far.
As a businessman, I am concerned at the commercial realities of building persistence-level products for developers. There is a 'Death Valley' in pricing: you have to be very good at $0/mo (i.e. usable in production), and virtually infallible at $1,000/mo (and even then the first CTO's task will be to replace you). Being that good costs a lot of expensive engineering cycles. You guys a clearly smart, or you wouldn't get Scaphold to this impressive point so quickly nor get YC to support you. Yet other brilliant teams had crashed and burned in this 'Death Valley', with the most recent one being RethinkDB - also backed by YC, and among the most impressive ones for me. I wish you all the tailwinds in the industry, and encourage you to read the RethinkDB post-mortem to harness those winds better -> http://www.defstartup.org/2017/01/18/why-rethinkdb-failed.ht...
The question was framed slightly differently in that that person asked about TAM, so this is what I responded below and I think it's still a valid explanation to repost here:
"Great question, that's something that we've been thinking about for a while and I want to start out by defining what our market is. Given the various categories of offerings in the market today amongst managed hosting, DBaaS, and PaaS, Scaphold falls under the PaaS side of things. We do offer plenty of value-added features that attempt to make server-side development a lot more hands-off.
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."
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.
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!
My only words of advice are focus on the business and finances just as much as the coding. Unfortunately the best engineers and technology don't always win (see RethinkDB). I'll be tinkering around tomorrow with Scaphold, might work out well for a side project of mine. Best of luck!
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!
Also, 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.
