mparis

A freebie online using python: http://www.oreilly.com/programming/free/files/functional-pro...

A freebie online using Haskell: http://learnyouahaskell.com/chapters

I don’t write much Haskell any more but learning it will force FP into your brain. Good luck :)

May I ask for a clearer definition of “better off”. From whose perspective? Also does this imply that since going public, google has not been following its mission?

It’s certainly seems true that companies are able to survive on private funding longer than they were a decade or two ago. The longer the company stays private, the larger the IPO leads to bigger payouts for investors and employees that stick around long enough to see the liquidity event and/or have enough cash to exercise their options should they choose to leave. With a strong team, perhaps the lack of public shareholders leads them to pursue more moonshots, shut down fewer products, and find more success but I also think there are downsides.

Chief among them, I think, is that employees generally assume the downside of additional private funding as VCs often get to maintain their pro-rata rights (get to maintain their ownership percentage) while employees get diluted with additional funding. As private valuations rise, option strike prices increase without any guarantee of liquidity in the future. That means employees either need to stick around longer or need to pay significantly higher strike prices for their options without a guarantee they will be worth anything in the future. RSUs (basically options with a $0 strike price) are very employee friendly and many engineers seek them out as they are as good as cash.

As with many things it’s probably a trade off. Perhaps they stay more “true” to the mission without going public, but I would guess many google employees would have missed the wealth brought about by the liquidity from the IPO.

Good question. What do you think?

Fun: Rossignol black ops gamer 118 skis. They shred.

Coffee: Kalita 185 pour over coffee maker. Inexpensive, high quality coffee. Also the porlex mini burr grinder.

Software: IntelliJ Ultimate/Clion for rust dev. Historically a VS Code guy but jetbrains products are great when you have enough horse power to run them.

Speakers: UE mega boom 3. Waterproof & great sound.

Book: Victor Frankls man’s search for meaning.

Food: Eggplant for this parm https://www.bonappetit.com/recipe/bas-best-eggplant-parmesan

Charity: Donating to Wikipedia. We need them.

Congrats to the Apollo Team and contributors for all the awesome work that went into this release. The majority of our customers at Scaphold (https://scaphold.io) are using Apollo to power their applications with amazing results.

We're excited to keep working to push the limits of GraphQL by supporting awesome features like subscriptions, persisted queries, and much more!

If you're in SF come to meteor tonight for the GraphQL meetup and let's talk about what's coming next.

And https://scaphold.io!

Congrats on the launch guys! Bitrise is THE CI tool for iOS apps.

Hey Ryan

Congrats on the launch! Super impressed by what you have accomplished as a solo founder. Keep up the good work! What would you say has been the most difficult aspect of flying solo? Have you been leveraging platforms like UpWork or a PaaS/BaaS to help with development on so many different platforms?

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!

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!

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.

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.

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

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.

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

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.

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!

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

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.

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!

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.

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

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.

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!

I think the site is really cool. We build a lot of tutorials as well and you have a simplicity to your style that I think will resonate with readers esp. those newer to programming.

We just wrote a tutorial on building a simple realtime react app with GraphQL Subscriptions. If you're interested I'd love to hear your thoughts as well.

https://scaphold.io/blog/2016/11/09/build-realtime-apps-with...

Facebook's Relay.js implements a pretty ingenious caching layer that is designed to work with GraphQL. It might be worth a look (https://facebook.github.io/relay/).

Great suggestion. We are currently working on getting this setup on our side!

We're mostly a javascript shop and run on node.js with babel so we can leverage all the modern goodies of EMCA 2015!

Yes absolutely! We will update the docs asap! You can find the video on the home page as well as on youtube here (https://www.youtube.com/watch?v=bJ8pnYd6jPQ).

We were actually able to get everything started in under 5 minutes!

Hey guys,

This is Michael from the Scaphold team.

We are excited to officially launch today and would love to hear any and all feedback on the platform.

A little about us. We are a member of this summer's YC Fellowship class and are pumped to be moving full steam ahead with Scaphold. Over the past few years, my co-founder and I have built numerous REST APIs to back services ranging social music apps to community book swapping programs. Each time, we found that we were running into many of the same problems and building much of the same thing over and over again. We used REST because we didn't know any other way, but something was definitely left to be desired. Last year, after reading a HN post on this little thing called GraphQL, we knew this was the future. A few months later, we set out to build the world's most powerful GraphQL-as-a-Service platform and today we are sharing it with you.

Thank you HN for the support and we can't wait to see what you build!

PS. If you are an experienced React or Relay dev we would love to hear from you as your feedback would invaluable to us. You can connect on our Slack page here (https://scapholdslackin.herokuapp.com) or via our the chat tool on our homepage.