What is the plan for this? #610
-
|
We are a startup about to emerge from stealth and our product is maturing very quickly and as we are trying to keep running lean as the complexity of our app increases we are looking for solutions to automate as much as possible our API. We are looking at other solutions like Hasura and Postgraphile. So far, it seems the former gives away too much control while the latter is very limited in how it handles authorization. GraphWeaver seems to hold a lot of promise, however I was unable to run the app after importing our Postgres db, and I am concerned that the documentation is rather light and there doesn't appear to be much of a community to offer support. I couldn't even find any mention of pricing. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
Hey @TroyMorvant, welcome! Happy to discuss, and if you'd like to get in touch in a more real-time kind of way we can always jump on a Slack channel or Zoom call. You're correct, it's early days for Graphweaver. We're still pre 1.0, but that'll be changing this month (work currently underway here: https://github.com/exogee-technology/graphweaver/tree/EXOGW-342). From that point we'll have release notes and will be more rigorous about breaking change releases. The major change from 0.x to 1.x will be taking charge of schema generation ourselves instead of depending on TypeGraphQL. It's making the code much more readable, maintainable, and flexible. We built Graphweaver largely because of the problems you're describing. Tools either want to be your database, forcing you to copy everything everywhere, or they force everything into the GraphQL schema, which really isn't the best place to write code. When they allow you to write actual code, they don't join the datasources well at all. With Graphweaver we can finally just think of all our various SaaS platforms and DBs that make up every modern application as one schema. We have been using less developed forms of Graphweaver in our production projects for about 3 years now, and are very confident in the approach to solve a wide variety of problems. We have two production projects now using the NPM releases from this monorepo. There can always be more tests, but we do have an end to end test suite that puts releases through their paces before we release. Our vision for Graphweaver is that it's all just code. We provide a base framework that allows you to get CRUD operations out of the box with pluggable auth, then you can override and tweak to your heart's content. In terms of the business model, we are Exogee. We make money by consulting for our clients. We plan to charge for specific more enterprise-y data providers / connections / integrations (which are not currently in the repo), and may choose to charge for add-on services in the future, but do not plan to charge for the core. We think this will give people the confidence to choose Graphweaver as a viable way to build a platform knowing they're not locked in. There's no pricing page because we do not plan to charge for anything that's public today. When we offer products / cloud platforms / add-ons / adapters / etc that we feel we should charge for, they'll show up on a pricing page. We open-sourced Graphweaver because we have seen the open source model make better products our whole lives. The better Graphweaver is, the better value the work Exogee produces for clients is. We've already proven this business model, as Exogee was founded 7 years ago and is still going strong. On Graphweaver specifically, we benefit from bug fixes and features contributed by the community, and the community benefits from any improvements we make to build things we need for our projects. We think this is a sustainable exchange which is mutually beneficial to everyone involved. In terms of having trouble getting started, I'm sorry to hear that. We do have some gotchas and limitations at the moment. If you've got time it'd be great to be able to work through a reproduction case with you to see if we can get you up and running. Also you mentioned that the docs were light on. Are there any specific areas that you felt we could flesh out more or that left you wanting? It's hard for us to look at it with fresh eyes after this long staring at it, so we're definitely open to hearing any feedback you're willing to share. |
Beta Was this translation helpful? Give feedback.
-
|
That all makes sense, and yes a slack channel would be nice. Regarding documentation, it would be nice to see some examples showing how GraphWeaver can be integrated into an existing backend rather than as a standalone application, or examples for integrating 3rd party authorization solutions like Auth0. The other bit of frustration with the documentation was due to me misunderstanding the error that I was seeing. |
Beta Was this translation helpful? Give feedback.
-
|
The slack channel is now available, and we've updated graphweaver.com to advertise this. Keen to see how you're going with your proof of concept if you've got time! |
Beta Was this translation helpful? Give feedback.
-
|
Yup, completely understand on the gaps there. We've used Graphweaver in production with Auth0, Okta, Stytch and Cognito before, so are quite confident you can set up with any provider. Happy to provide an example, we'll get started on that. |
Beta Was this translation helpful? Give feedback.
-
|
The Auth0 example is now available here: https://github.com/exogee-technology/graphweaver/tree/main/src/examples/auth-zero |
Beta Was this translation helpful? Give feedback.
Hey @TroyMorvant, welcome!
Happy to discuss, and if you'd like to get in touch in a more real-time kind of way we can always jump on a Slack channel or Zoom call.
You're correct, it's early days for Graphweaver. We're still pre 1.0, but that'll be changing this month (work currently underway here: https://github.com/exogee-technology/graphweaver/tree/EXOGW-342). From that point we'll have release notes and will be more rigorous about breaking change releases. The major change from 0.x to 1.x will be taking charge of schema generation ourselves instead of depending on TypeGraphQL. It's making the code much more readable, maintainable, and flexible.
We built Graphweaver largely because of t…