HN user

vning93

72 karma

Restless.

Nabis (YC W19) Scaphold.io (YC W17)

Posts14
Comments54
View on HN

Our solution is both software and infrastructure. On the infrastructure side, we our own distribution license, fleet of trucks, warehouses, and more. And that's all wrapped under our web portal to help make shipping and compliance easy.

We're METRC approved and working on the integration now. API is on its way too.

Thanks for sticking with Scaphold. We'll be bumping up the power of permissioning soon! We've been focused on implementing more features with our schema and custom logic in the meantime :)

Hi there! If you're interested in synchronous mutation callbacks (https://docs.scaphold.io/custom-logic/) and have multi-region deployment (https://docs.scaphold.io/app-management/multi-region/), you should check out Scaphold.io (https://scaphold.io)! We were in the most recent YC batch and have more features for schema management like enums and interfaces as well. If you have any questions, feel free to reach out on Intercom or Slack.

It's always good to see more companies push for GraphQL.

There are a few others like this, one of which I co-founded, called Scaphold.io (https://scaphold.io), and we're huge proponents of GraphQL and Serverless as well. It truly is the future of app development.

If you're interested in learning more about using Serverless with GraphQL, feel free to join the Serverless GraphQL Meetup that we're hosting (https://www.meetup.com/serverless-graphql).

Hi Lee, Vince here from Scaphold.io.

I can help put you in touch with the guys who run the channel and manage the Q&As. We're actually doing one ourselves on April 27.

I'll reach out on the GraphQL Slack channel.

Great question! There are great libraries like Create-GraphQL (https://github.com/lucasbento/create-graphql) that can help you scaffold an app on the server side pretty quickly, and it's fairly un-opinionated. That one in particular works with Mongo, but I believe they're rolling out support for other data sources as well soon.

In addition, if you're looking for a hi-fidelity way of building apps without having to worry about the server-side, Scaphold.io (https://scaphold.io) is a GraphQL backend as a service that can help. I work full-time here, and we help you get from zero to GraphQL in a matter of minutes.

And with this you have two options:

1) If you want to use the service, by all means :)

2) We're built to the open standard / Relay spec, meaning that if you want to create an app to learn about how the API is structured, that can help as well. Here's more of a primer on how our API is built and works anywhere (https://docs.scaphold.io/coredata/schema/).

Feel free to reach out if you have any questions on our Slack (http://slack.scaphold.io)!

Very excited as well for the release of Relay Modern! I think overall a huge boon for the Relay developer experience.

I'm with you here on the static queries. We've used Relay a couple of times as well for various smaller applications here and there, but honestly felt the "magic" was too strong. I'm looking forward to building my future apps and try out Relay Modern.

In addition, I want to be able to encourage more applications that build on our GraphQL platform called Scaphold.io (https://scaphold.io) to try out Relay Modern as well since our API is built to the Relay spec. With that in mind, I'm hoping that the spec will be less restrictive in the future, so there's a smaller learning curve for folks trying it out.

As for the concern with focusing on the internal needs of Facebook, I think the experience that they have working with one of the largest distributed systems in the world helps (rather than limits) their vision on what Relay can be. I trust that this is the case, though it would be really great to see some of the tooling for native support (i.e. iOS, Android, etc). I'm sure they've got that somewhere waiting to be released as I can imagine they have plenty of mobile teams at Facebook who aren't using React Native yet.

Completely agree here. I think many people realize this and have built awesome tooling to be able to manage different ecosystems and environments.

One that I've been particularly keen on over the last year is GraphQL. If you're interested in simplifying frontend development while giving it more power and control to dictate the data that it needs for each component / view, you should check out GraphQL. I know what you're thinking... "Ugh, another dev tool to learn etc etc". But it's definitely one that's here the stay and a bigger idea than even REST itself. The OPEN STANDARD of it is KEY.

The idea is that you have a type system on the API level and one endpoint. And querying works using a standard GraphQL language, so it's cross-API compatible and you don't need to go learn a whole new API convention at each new place or project you're working on since with REST, they're probably all built in different ways. And GraphQL works across all platforms (i.e. no more proprietary SDKs). All you need are things like Relay and Apollo and that's it.

I've actually been working on a platform called Scaphold.io (https://scaphold.io) to help people learn more about GraphQL and give them a cleanly packaged server and help you manage your data so you don't have to in order to feel the benefits of GraphQL right off the bat. Because of the use of GraphQL, it comes with the best of both worlds of Parse and Firebase with awesome data modeling tools, real-time capabilities, and of course it's built on an open standard.

Truly is the future of APIs that works perfectly with React, and any other framework that comes out down the road for that matter. Facebook's tooling is really neat cause it's built from first principles as well as from their experience running one of the largest distributed systems in the world. So they definitely know a thing or two about building developer tools that are cross-platform compatible and developer-friendly.

Awesome project! Our customers building GraphQL apps on https://scaphold.io would really appreciate something like this.

We currently have a Schema Designer that's fairly intuitive for the most part, and by "most part" I mean developers. Incorporating this tool to graphically show how your data relates would help the less tech-savvy domain experts on Scaphold.io tremendously. Thanks for your awesome work with this and GraphQL APIs (https://github.com/APIs-guru/graphql-apis).

I'd love to help contribute in any way!

Great point. It is an inevitable concern with any hosted data platform. Though we do try our best to make your data as transparent as possible and are coming up with more and more ways so you can have tons of control over your data.

That's a very valid concern, and I appreciate you asking. One of the (many) benefits of using GraphQL is that it's an open standard.

And in the event of a Parse-like shutdown, migrating off of a hosted platform like Scaphold is much less painful since you could quickly spin up a GraphQL server on your own with the same GraphQL schema that you can easily export from Scaphold. Regarding the data you have stored in the system, we work hard to let you use as much of your own data as possible from various services across the web, so even if we shut down, your data still lives across those other service providers that you use. In addition, we'd be happy to give you a full export of your data in any format you wish. We use an underlying MySQL database behind the scenes, and migrating your data from one SQL database to another is much more structured than moving off of a Mongo database (Parse's data layer).

We're also pushing out more and more support for tying in your existing data hosted elsewhere on the web with advanced custom logic hooks that can tie into your other APIs and data layers as well.

I loved Parse from the time I first started using it in college. It started out as a really handy way to spin up small apps quickly so I could start beta testing my app quickly with real users.

One of the main problems though was that it really felt like just a prototyping tool to me, and I never really used it for real apps in production.

Thus, for my latest project that I've been working on for several months now, I've decided to try in every way to address that problem. I started a company called Scaphold.io (https://scaphold.io) and it's a GraphQL backend as a service platform. It serves to address many of the same needs of Parse and more. It combines all the best data modeling tools from Parse and real-time capabilities from Firebase to provide a high-fidelity app development experience that you can actually build real production apps on, with as much transparency to your data as possible. That's the mission that we have at Scaphold, and I'm excited to be helping all the stranded app developers out there that were burned by Parse shutting down.

Excited to see what comes next for the app development world!