Unclaimed: Are you working at Hygraph?
Hygraph Reviews: 4.6/5 — Highly Rated
Hygraph is a highly intuitive and user-friendly data visualization tool that helps businesses of all sizes visualize and analyze their data in real time. Unlike other tools, Hygraph features a drag-and-drop interface that eliminates the need for coding, making it accessible to users of all skill levels. With its advanced analytics, customizable dashboards, and interactive graphs and charts, Hygraph is a powerful tool that can help businesses make data-driven decisions and gain critical insight into their business performance.
| Capabilities |
API
CLI
|
|---|---|
| Segment |
Small Business
Mid Market
Enterprise
|
| Deployment | Cloud / SaaS / Web-Based |
| Support | 24/7 (Live rep), Chat, Email/Help Desk, FAQs/Forum, Knowledge Base, Phone Support |
| Training | Documentation |
| Languages | English |
Compare Hygraph with other popular tools in the same category.
It is a very flexible platform that allows you to do a variety of things with the right internal resources.
As our site scaled the support and speed of things from Hygraph suffered.
We have a hyper-local business that Hygraph allows us to scale our website with custom pages at a rapid pace.
Easy to use with interesting features and dev-friendly documentation.
Lack of specific features for content, like allowing to localize stuff like References to other objects.
Generating website pages without needing to create new code.
I really enjoy the convenient GraphQL interface. There is very little restriction on what you are able to store and I have experienced very minimal latency with the API. The API playground is also quite useful for visualizing queries.
The documentation is useful for day 1 and 2 of usage. More detailed documentation seems to lacking for more complicated queries. There doesn't seem to be a forum managed by GraphCMS to get answers from, nor is GraphCMS pervasive enough to have questions and answers on external sites like StackOverflow. For complex data, the relationship links between schema get quite nasty as well. Maybe the type system can be improved.
GraphCMS provides an easy non-technical interface for content people to curate and control information. It offloads the maintenance of such a database from the engineering team, opening up time for more important work.
Building content using models, fetching data using API. Robust and flexible. Easy asset management for content managers.
For en users like content managers a little technical system.
Supports our new online shop using headless development.
Most of the functionality is fairly clear.
Pushing changes to our website does take some time. It also lacks some functionality that we needed for our website, like contract creation.
We've automated many of our booking processes as well as set up accounts for our team.
The foremost noteworthy benefits are how quick ready to presently construct substance CMS. The improvement and introductory model or prototype and production version take less time, and things get prepared quickly. Easy to understand and use, especially for a non-technical person is the thing I love.
We don't have much freedom for customization in design and data modeling. We must have to restrict available tools, design and data modeling. its very expensive
We are a team of software developers, we use GraphCMS for our client's needs and requirements in data management. It makes things ready rapidly this is what we love the most.
The most important thing That I love about graphCMS is very fasttt and easy to use.
Hopefully you could add more things to it, To not be limited in this time
I wish you could add more language to it
Simplicity and ease of use. Compatability with other tech.
Community support and documentation could be improved.
Allows us to publish our company blog seamlessly and effectively.
It's the most user friendly cms platform i have experienced. visually less confusing than other similar platforms in a content implementation perspective.
Nested navigation is very confusing and annoying in general. Publishing vs Save logic gets confusing. Also has a few detectable bugs that influence the work flow.
easier to find existent components, and therefore to edit them. Assets library is also very intuitive and easy to use. Setting up components in BE is easier to understand and to brief to editors compared to other competitors.
Pre-built UI for building a GraphQL-enabled schema. Content editor for those who will input data. We don't need to create a backend.
Very limited if your project is growing. Pricing is abhorrent. You pay 300 for 50 models, then 500 more for another 25. And it's the same number of components.
It's a good concept, but they're super stingy with resources.
The UI is really nice and professional looking. I like that you can customise and organise the sidebar. Their API SDK uses TypeScript so it's essentially self documenting. Performance is pretty good once things are cached but awful when not. The SWR Cache customisation is nice. The ACL system is really thorough and very extensible. Localisation is good and the UI for it is good.
Pagination is limited to 100 when every other competitor has 250 to 1,000 and it's a little frustrating because it cannot be updated. The rate limits are also harsh (even when you're using your own private cluster they insist on some limits). I hit rate-limits when testing locally, by myself and hadn't even sent any traffic yet. They don't support proper image optimisation with a provide like Imgix or even Cloudflare image resizing. The free tier is very limiting which makes it hard for you to evaluate the product and they won't let you evaluate it properly without signing you up in a yearly contract if you need more models to evaluate it properly. Other Headless CMS's allow you to have more models and you only need Enterprise after you're sending enterprise level traffic. The sales team will essentially tell you that everything is possible, everything is fast, the dedicated cluster can handle unlimited traffic, the rate limits are non-existent - until you sign for a 1 year contract of 2,000/mo and suddenly reality hits after you send real traffic. If you want to extend it by adding users or locales you first have to speak to the sales team and wait for a contract amendment just to increase a number that most systems allow you to do in an admin panel. They'll try to upsell those users and locales to save money when it's $60/user instead of $10/user. When you have pay-as-you-go pricing models like AWS where you pay for exactly what you use, I hate when companies push you into large contracts up-front and make you pay before you can properly evaluate it. It's like going to a club, asking if it's busy inside and only after paying, realising that it's actually empty. In systems like Builder.io I'm able to make my project grow in small increments by increasing the required page views, bandwidth and users without having to sign a contract for a year before I need it. It makes the relationship feel sour and predatory. Unfortunately our previous CTO signed for it and then they wouldn't let us cancel the contract so we're paying for it and have since moved on.
Headless CMS with multi-tenancy and localisation for serving millions of users. The ACL system is great for allowing lots of users and picking exactly what they're able to see and edit.
I do like that it has a clean looking UI with the ability to control a significant amount of the customer experience
Hard to navigate UI, RTE needs a lot of work
Problem: provide a quality digital experience for government clients
The live graphql editing was a useful feature.
Our experience with graphcms has been uniformly negative. When we deployed on the platform our production site would regularly be broken due to how what is now called 'legacy graphcms' worked internally. Specifically any edits to our content would cause some kind of cache invalidation in graphcms and our entire site would go down due to being unable to access content. Further, the way content editing works on the legacy platform was unusable by our marketing team. Specifically the way drafts worked caused content to disappear from our site b/c once an object was set to draft it would disappear from the published site. We are extremely dissatisfied with our experience and are now faced with graphcms forcing us to do more work to migrate off of your legacy platform onto your new platform. We have 0 confidence that this work is useful or warranted based on our experience with the legacy system.
We intended to solve the classic content management problem but instead where faced with a terrible experience of a broken site we couldn't edit.