4 ms·

Graphik: An identity-aware document and graph database

ito 6y ago
Graphik is also the name of a well-known font (https://commercialtype.com/catalog/graphik/graphik https://commercialtype.com/catalog/graphik/graphik).
WalterGR 6y ago
What's the value proposition, or: Why would someone use this and not another graph database?
- systemvoltage 6y ago
  The lengths people go to so they don't have to write SQL or build a REST API.
  - emteycz 6y ago
    Would this really be better as a REST API with SQL backend? I don't think so, it would be the same at best.
- m1sta_ 6y ago
  I'm guessing here, but it may allow all logic to sit on the front-end. Useful for some situations.
GauntletWizard 6y ago
The segment "GraphQL vs gRPC API"[1] touches on something near and dear to my heart: You should write API-first services, and wrap them in templates. The ideal way you write server-side rendered page on your website is to write some code that gathers all the data you'll need, then when you have a big struct that contains everything you need to render the page, execute a template over it. As a side effect, you can set this up as a RPC call - You can do all of the data gathering in a function that matches a GRPC protobuf, and then wrap that with a function that matches http.HandlerFunc. Then you've got a well-structured RPC should ever you need to expose "a page" as "a call" I used to wish for more languages to handle PHP like inlining of code - Most of your website is usually in the template. I still think that's true, but separating out the data-gathering is valuable, because that data gathering can fail. You can have a SQL Timeout or a retry failure or simply need to 403 for authorization purposes: any number of backend problems, and you want to serve a different template for those. Golang's html/template (and text/template) are just the right mix of inline code, extensibility from external code, and not focusing too much on error conditions. They're not useful if one of your functions will error in the middle, but they give you the flexibility to do things like conditional-formatting. [1]https://github.com/graphikDB/graphik#graphql-vs-grpc-api https://github.com/graphikDB/graphik#graphql-vs-grpc-api

ito 6y ago

Graphik is also the name of a well-known font (https://commercialtype.com/catalog/graphik/graphik https://commercialtype.com/catalog/graphik/graphik).

WalterGR 6y ago

What's the value proposition, or: Why would someone use this and not another graph database?

systemvoltage 6y ago
The lengths people go to so they don't have to write SQL or build a REST API.
- emteycz 6y ago
  Would this really be better as a REST API with SQL backend? I don't think so, it would be the same at best.
m1sta_ 6y ago
I'm guessing here, but it may allow all logic to sit on the front-end. Useful for some situations.

GauntletWizard 6y ago

The segment "GraphQL vs gRPC API"[1] touches on something near and dear to my heart: You should write API-first services, and wrap them in templates. The ideal way you write server-side rendered page on your website is to write some code that gathers all the data you'll need, then when you have a big struct that contains everything you need to render the page, execute a template over it. As a side effect, you can set this up as a RPC call - You can do all of the data gathering in a function that matches a GRPC protobuf, and then wrap that with a function that matches http.HandlerFunc. Then you've got a well-structured RPC should ever you need to expose "a page" as "a call" I used to wish for more languages to handle PHP like inlining of code - Most of your website is usually in the template. I still think that's true, but separating out the data-gathering is valuable, because that data gathering can fail. You can have a SQL Timeout or a retry failure or simply need to 403 for authorization purposes: any number of backend problems, and you want to serve a different template for those. Golang's html/template (and text/template) are just the right mix of inline code, extensibility from external code, and not focusing too much on error conditions. They're not useful if one of your functions will error in the middle, but they give you the flexibility to do things like conditional-formatting. [1]https://github.com/graphikDB/graphik#graphql-vs-grpc-api https://github.com/graphikDB/graphik#graphql-vs-grpc-api