Show HN: 8base – Generate working React app with GraphQL back end in minutes(8base.com)
8base.com
Show HN: 8base – Generate working React app with GraphQL back end in minutes
https://www.8base.com/generate
4 comments
Thanks for the interest! The questions you are asking are very valid. Let me address them one by one:
1. We are evaluating an open source strategy, but currently don't have plans to open source it. There are couple ways we're addressing this. First, in an event of a closure of the platform we commit to open sourcing it, just like Parse did. Second, which is a more immediate one, is that we will be adding features that make 8base fit well into developer workflows as a tool rather than a platform. That way developers don't have to commit to building on 8base right away and can use it as an integration layer that accelerates access to business data and workflows. By focusing on enterprise use cases we believe we can achieve a good value proposition without forcing people to build entire application on 8base. Also, as serverless architecture becomes more pervasive porting business logic comprised of cloud functions should become easier than before (this is a somewhat weaker point).
2. We're still working on the pricing and gathering feedback. If you don't mind, could you share which aspects of pricing concern you specifically? Indeed a SaaS, especially one in the enterprise space, is definitely our target. As a matter of fact, we already have an enterprise SaaS built on 8base that's launching in a few months.
1. We are evaluating an open source strategy, but currently don't have plans to open source it. There are couple ways we're addressing this. First, in an event of a closure of the platform we commit to open sourcing it, just like Parse did. Second, which is a more immediate one, is that we will be adding features that make 8base fit well into developer workflows as a tool rather than a platform. That way developers don't have to commit to building on 8base right away and can use it as an integration layer that accelerates access to business data and workflows. By focusing on enterprise use cases we believe we can achieve a good value proposition without forcing people to build entire application on 8base. Also, as serverless architecture becomes more pervasive porting business logic comprised of cloud functions should become easier than before (this is a somewhat weaker point).
2. We're still working on the pricing and gathering feedback. If you don't mind, could you share which aspects of pricing concern you specifically? Indeed a SaaS, especially one in the enterprise space, is definitely our target. As a matter of fact, we already have an enterprise SaaS built on 8base that's launching in a few months.
Thanks for answering!
As far as pricing if I'm comparing against, say, Firebase your pricing seems higher for less infrastructure but I understand that Firebase wouldn't be an apples-to-apples comparison given your enterprise-data-integrations value-adds.
I guess it's just hard to swallow the idea of building an entire app with your platform then potential having high cost of scaling- but again, I understand why some may not see it that way and be happy with that pricing.
If you had lower monthly base plans and then pay-as-you-go for each functionality like the serverless functions, no. of end-users, etc. then it'd seem more attractive.
Anyway I'm sure your guys have put a lot of thought into the pricing so this is just from a web dev's perspective!
As far as pricing if I'm comparing against, say, Firebase your pricing seems higher for less infrastructure but I understand that Firebase wouldn't be an apples-to-apples comparison given your enterprise-data-integrations value-adds.
I guess it's just hard to swallow the idea of building an entire app with your platform then potential having high cost of scaling- but again, I understand why some may not see it that way and be happy with that pricing.
If you had lower monthly base plans and then pay-as-you-go for each functionality like the serverless functions, no. of end-users, etc. then it'd seem more attractive.
Anyway I'm sure your guys have put a lot of thought into the pricing so this is just from a web dev's perspective!
Thanks so much for your comments. As Andrei mentioned, open source is something we are constantly considering but it's one of those decisions that is irreversible and must, therefore, be very carefully considered. Our belief is we must focus on a sustainable business model given the history with products like Parse, Graph.cool and Scaphold.
8base was founded after having spent decades in enterprise software and feeling the tremendous pain associated with designing, hosting and supporting multi-tenant SaaS. Our product is significantly differentiated from Firebase today but we expect that over the rest of 2019 we will diverge further and address some of the major pain points that exist in the market.
We will be coming out Beta in the next few months but we already have some great logos building on the product and paying us real revenues. We are also well funded.
8base was founded after having spent decades in enterprise software and feeling the tremendous pain associated with designing, hosting and supporting multi-tenant SaaS. Our product is significantly differentiated from Firebase today but we expect that over the rest of 2019 we will diverge further and address some of the major pain points that exist in the market.
We will be coming out Beta in the next few months but we already have some great logos building on the product and paying us real revenues. We are also well funded.
We're definitely still iterating on the pricing. Currently the platform is completely free (while in Beta). We are yet to implement billing and welcome all feedback that can help make our pricing more attractive for target use cases.
A new experimental feature in 8base CLI generates a working React app from your data model. This is great for getting started with GraphQL and React or for quickly generating an admin UI for your app. Similar to scaffolding in Ruby on Rails.
So it's a DBaaS with a neat UI and GraphQL? https://www.prisma.io (formerly GraphCool) is similar.
I'd say at the current stage 8base is closer to Graph.cool than Prisma. But that's more of a function of our development timeline rather than the ultimate goal. Our ultimate goal is to become a tool for businesses to build externally-facing applications on top of data in business systems, such as Salesforce, SAP and other, as well as data in 8base. We'll be releasing Salesforce integration in the next month or so.
With 8base front-end developers will be able to access data across legacy business systems through a unified GraphQL API. They can build business apps quicker and without developing custom server-side middlewares. Unlike a traditional BaaS, we have heavier focus on front-end tools (e.g. we have a UI kit for React) and enterprise features (identity, role-based permissions, document management, etc). We're not trying to be a BaaS for everything like Firebase or AppSync.
If you're interested in seeing more on Salesforce integration, there's video on our ProductHunt upcoming page: https://www.producthunt.com/upcoming/8base-bolt .
With 8base front-end developers will be able to access data across legacy business systems through a unified GraphQL API. They can build business apps quicker and without developing custom server-side middlewares. Unlike a traditional BaaS, we have heavier focus on front-end tools (e.g. we have a UI kit for React) and enterprise features (identity, role-based permissions, document management, etc). We're not trying to be a BaaS for everything like Firebase or AppSync.
If you're interested in seeing more on Salesforce integration, there's video on our ProductHunt upcoming page: https://www.producthunt.com/upcoming/8base-bolt .
[deleted]
One question, is your underlying platform currently (or to be) open source? I ask because it was reassuring when graph.cool put their entire graph.cool backend framework open source so that it felt even less like potential lock-in.
I know the fact that it's standard graphql means there's already a certain level of portability but if you build-up all this functionality in your BaaS there's potentially a lot of lock-in there.
Lastly, your pricing seems high for, say, a dev who's want to build a SaaS that'd sell to potentially many enterprise users. Maybe you do not want to target that demographic?