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 mix. Something like AWS' Lambda.

Question for the founders, will there be an extension platform, something like Parse cloud or the Heroku app store?

"Services like Stripe, Algolia, Datadog, Pusher, Mapbox, Imgix etc all make a lot of sense"

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.

Thanks for the comment!

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.

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 and to join a specific team.

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.

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 :)

That's a really good point and the foundation for what we're building with Graphcool (https://www.graph.cool). It's basically combining a GraphQL BaaS with AWS Lambda (or similar services). We take away the pain of configuring and maintaining your database + GraphQL schema so you can focus on implementing your business logic.

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.

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, 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!

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?

as a data point, i had no idea what GraphQL was.

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.

As a developer, and the lead for our GraphQL efforts since the day the JS codebase was released, I applaud your efforts. To us, GraphQL offers a smarter way to frame API contracts and gives a significant competitive edge by increasing our dev agility. Spread the joy around!

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...

Hi there, thanks for the support and feedback! I believe someone earlier on this thread raised the same concern and as a matter of fact, linked the same resource about RethinkDB :)

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."

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.

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

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.

My team and I have a medium sized dev shop from Southern California. We've been using Scaphold in production now for several months, and have been absolutely blown away by how much more efficient we've become. All projects in the pipeline will be using Scaphold going forward. Take my money.

Amazing! It's one of the most heartwarming things to hear someone like yourself talk about how Scaphold truly helps you in your job with real production workloads. And it sounds like many of them as well! Happy to chat more with you on Slack about your future apps (http://slack.scaphold.io)

Congrats! The website looks great!

Forgive me if I am simply uninitiated, but what are the general advantages of graphQL over a typical backend powered by a SQL database?

Hey thats a great question! These things are actually not mutually exclusive. You can think of GraphQL as REST 2.0. GraphQL provides a type system and standardized query language that make it much easier to consume APIs from the perspective of the client application. For example, the GraphQL language itself is very powerful and essentially eliminates the need of SDKs making GraphQL a great choice for any platform including embedded systems, VR, and more. GraphQL does not make any assumptions about where your data lives however. In fact, we run multiple databases (including SQL) each of which serves a specific purpose and we are able to expose all them to you via GraphQL. This is also how we are able to pull in things like Stripe, Algolia, Push Notifications and more into the same API that powers the rest of your application.

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.

If you code while working for another company dont they own that IP? Unless specifically stated on your employment contract? Just curious! Thanks

Joel Spolsky has a good write-up on this: https://www.joelonsoftware.com/2016/12/09/developers-side-pr...

not if you code outside of working hours with your own equipment

My apologies for contradicting you, but this is too simplistic an answer. The answer depends on the laws in your state, whether it was coded on your own time, whether it was coded with any resources of their company, whether ideas in your product can be shown to possibly have come from the work you did for the company, and what your NDA/employment letter/employee agreement states. Unless you run that document by a lawyer and get specific set asides carved out, they might very well be able to take you to court. Some states are really good for you though, like CA. FWIW, I am not a lawyer, and this does not constitute legal advice.

Exactly. We never spent time on the company's dime working on it and my employer actually knew I was working on a side project and permitted me to continue doing so.

And if you are not creating anything related to your work. Like if you work at a game company and you make a game on your own time with your own equipment, the game company you work for can claim your work as their own.

The new website looks pretty cool but I wasn’t blown away by the product. The API feels very weird when actually building an app and unfortunately most integrations didn’t work for me.

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).

Those are great points you make and we'll take it to heart to assuage your concerns. If I may ask, what in particular was weird about the API? We're built to the Relay spec, which has become the open standard for GraphQL APIs.

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 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.

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.)

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?

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.

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 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!

[1] http://venturebeat.com/2011/08/10/nodesocket/

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!

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

This is exactly what I've been looking for to backend some of my projects - awesome service guys!

Thanks! Really appreciate the support. Feel free to test drive the service and let us know what you think.

Congrats on the launch, the new website looks really nice!

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!

Thanks for the support! Agree with your sentiment, we talked to many users about how best they like to extend their API, and found that the modular approach was best for popular services like Stripe, Auth0, and so on. And for the rest of the custom workflows, we've provided the ability to extend your API with your own custom logic through synchronous and asynchronous hooks that can call out to any web service that you may have hosted anywhere, whether it be on AWS Lambda, Azure Functions, Webtask, or even self-hosted. If you're in the portal, you can check it out under the "Logic" tab.

I spent some time with the founders and they are really great. Without parse and google owning fire base they way has been paved for a new IAAS/PAAS. I hope Michael and Vince can lead the way.

Thanks for the support! Really appreciate it. It's an amazing time to be in this space right now with all the opportunities and directions to take the product.

This looks really interesting. Thanks for sharing! I checked out the Projects page, but they look mostly like tutorial or hackathon types - is anyone running scaffold.io in production?

Hey! Yes we have an number of larger production apps on the platform. We actually power 4 National Geographic domains in Europe as well as some cool new startups like http://cheddr.com/. We are working on getting more in depth customer profiles that will go on the community page soon!

Big fan of what you are doing! But can you elaborate a bit on TAM? Isn't the possible market too small? https://github.com/coffeemug/defstartup/blob/master/_posts/2...

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.

At a glance it does sound like a very small potential market which makes me curious as to why YC would fund them. Perhaps there's a belief that the market will grow as these tools lower the barriers to entry (facilitated by GraphQL) for building applications?

The fast-growing cloud service market at large is one we're trying to tackle, and you're correct in that GraphQL does indeed provide a lot of value in helping us get there.

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 of PaaS.

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 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

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.

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!

Thank you for the reply.

Is the name pronounced "scaffold"?

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.

Yes the name is pronounced "scaffold" with the "ph" for GraphQL. When we first started the project we liked the image of scaffolding going up around a building. In our case the buildings were your apps and we wanted to create the foundation upon which you build them.

I initially parsed the name as 'scaphoid', one of the carpal bones. I thought they were making a joke about reducing typing...turns out I just can't read properly.

We fight with the scaphoid bone on google every day ;). The name comes from the original vision to build a foundation upon which others can rapidly build. We saw the platform as a sort of scaffolding. One that helps you build your application and then melts away so you can focus on what is valuable to your customer.

I was just looking for something like this, great timing!

Awesome! Let me know if there is anyway I can help!

I think the "Customer stories" section needs to be updated. The bio picture and link for the Nat Geo reference points to Bonnier.

Thanks for the feedback. We didn't want to be misleading though since we actually run several of Nat Geo's domains in Europe through Bonnier. They own the licenses to them in that particular region. Here's a piece that explains their relationship: http://en.bonnierpublications.com/national-geographic-0

If we were to build an app, how portable is this application if we were to self-host it later or move to a similar provider?

One of the nice things about GraphQL is that it is the same everywhere. This reduces vender lock-in significantly over previous BaaS platforms. We also adhere our API to the relay spec so it will look familiar to most GraphQL users. That is to say that if you grow so large that you want to move to a self hosted solution then we can help you with that. of course you will lose our admin features, integrations, analytics and logic but if you're building it yourself things must be going well and we won't prevent you from growing!

Nice work. Excited to give it a spin in prod

Glad to hear it. Appreciate any and all feedback after you've checked it out!

Have been following you guys for a while, really excited to see what's next for Scaphold

Thanks for the support!

Hey thanks for the kind words! That is coming soon. You will be able to use the same Logic infrastructure to create you own custom queries and mutations!

Thanks for the prompt reply! I'm currently refactoring our GraphQL API and if you guys had this feature I would've gone off our infrastructure and used Scaphold. Will definitely keep an eye out for when you guys add this.

Do you fancy an intern this Summer?

Hey! We're preparing to start hiring so very possibly! You can reach out to me @michael on our slack (slack.scaphold.io) and I'll keep you in the loop!

when do you plan to start the referral program?

Referrals should already work. You can find them here: https://scaphold.io/referral. Let me know if you have any problems.

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.

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.

I liked your UI much more than the graph.cool thing.

But their generated Schema felt better to me. getUsers instead of this viewer stuff, feels much cleaner.

Hey, so the reason for the viewer is due to the Relay spec. It's a standard that was developed at facebook that provides some best practices in terms of schema design but I understand liking the simpler schema especially if you use Apollo and not Relay. We've thought of providing a non-relay schema for this reason as well but have yet to get around to it. Thanks for the feedback.

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.

"Launch HN"? That's new.

Yes, it's something we're trying out for YC W17.

https://news.ycombinator.com/item?id=13366964 was the first one, and this is the second one, so far.

So, it's preferential access to the front page in the same way as YC job ads, but no special comment moderation?

Yes, assuming I'm reading you correctly. We'll make it so there isn't a launch post and a job ad on the front page at the same time, once I get time to write some code—that way there won't be any more slots reserved for YC than before (i.e. one at a time). Since launches are more broadly interesting than job ads, this feels like a win-win.

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.

Yep this makes total sense. Thanks!