Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: GraPHP, a PHP graph DB web framework

github.com

Post reply on HN
Print view View original

1–10 of 18 posts

Re: Show HN: GraPHP, a PHP graph DB web framework

#6

Post by pushtheenvelope »

I’m really excited this was finally shared. A little backstory. This framework is the manifestation of ideas that Mike developed at Mixtent, a startup that produced three products in 2 years and eventually got acquired by Facebook.

The biggest advantage this framework has over other more traditional ones like RoR or Django is being able to model product ideas as a graph in code abstractions. This enables product engineers to rapidly prototype ideas (no need to interact with the DB), and jump into features built by other engineers (the node-edge API is standardized).

While the first product Mixtent built used more traditional django-style models, it resulted in features that became hard to manage over time. Each model had its own DB table and making changes was painful. The next two were built using a similar graph framework on top of CodeIgniter, and the benefits to prototyping speed and ease-of-understanding were visibly felt by all engineers (including myself).

Re: Show HN: GraPHP, a PHP graph DB web framework

#7

Post by emehrkay »

Wait, so this is a graph-like layer on top of an SQL database? I don't quite understand this claim:

"DB API is designed for fast performance. No implicit joins or other magic, but expressive enough for nice readable code."

When you have a database with a node, edge, and node_data (EAV) tables.

What am I missing? How would I get a node and its properties including edges, other nodes, etc. without joining other tables or flat-out magic?

Re: Show HN: GraPHP, a PHP graph DB web framework

#8

Post by mikeland86 »

emehrkay wrote: post #7

Wait, so this is a graph-like layer on top of an SQL database? I don't quite understand this claim: "DB API is designed for fast performance. No implicit joins or other magic, but expressive enough for nice readable code." When you have a database with a node, edge, and node_data (EAV) tables. What am I missing? How would I get a node and its properties including edges, other nodes, etc. without joining other tables…

What I meant by that is the joins happen explicitly in code (as opposed to implicitly in queries). I got burned using another framework where my lack of knowledge of how the ORM managed DB queries would lead to really inefficient stuff - basically really bad joins that I could have avoided if I knew what the framework would do.

When I say no magic, what I mean is how you can understand what data is being loaded every step of the way so the mistake I mentioned previously is harder to make.

Also, I wanted to avoid query joins for easy sharding (if needed), but that adds an extra round trip so if needed the developer can write their own joins (giving up a bit of flexibility in the process).

Re: Show HN: GraPHP, a PHP graph DB web framework

#9

Post by vog »

Recently I had some related ideas, although from a completely different background. Here is what I would have done differently:

1) Implement other storages. Although databases are a natural part of web applications, a direct storage in files and/or directories may be justified. Also, for most applications the full dataset fits easily in the RAM on modern systems.

2) Keep full history. Or provide for this possibility at least. Adding history features to classic database models becomes cumbersome quickly, but for a simple schema it may be provided directly by the framework. This provides for a great audit log if something went wrong. Probably to be disabled if really unwanted and/or storage size is an issue.

Regarding the different background: Although most people want graph databases if they don't want to enforce a certain schema, my desire is the exact opposite. I want more constraints, data integrity as much as possible. I want more than can be easily reached even in PostgreSQL with user-defined functions, such as constraints across foreign keys. So a separate checker is needed, and I believe graph structure with plain links provide a good, simple base to define a constraints framework upon it.

Re: Show HN: GraPHP, a PHP graph DB web framework

#10

Post by emehrkay »

mikeland86 wrote: post #8
emehrkay wrote: post #7

Wait, so this is a graph-like layer on top of an SQL database? I don't quite understand this claim: "DB API is designed for fast performance. No implicit joins or other magic, but expressive enough for nice readable code." When you have a database with a node, edge, and node_data (EAV) tables. What am I missing? How would I get a node and its properties including edges, other nodes, etc. without joining other tables…

What I meant by that is the joins happen explicitly in code (as opposed to implicitly in queries). I got burned using another framework where my lack of knowledge of how the ORM managed DB queries would lead to really inefficient stuff - basically really bad joins that I could have avoided if I knew what the framework would do. When I say no magic, what I mean is how you can understand what data is being loaded every…

Thanks for replying. Have you tried this at scale? What is the performance like when you have thousands of records? Have you looked into traversals? I ask these things because I tried to build a product using MySQL that should had used a proper graph db and I ran into a lot of issues. I think now that I'm a bit wiser, sql may be able to do similar things, but I haven't tried.

edit: the model layer is the most impressive part about this. You should consider making it a stand-alone package.

Post reply on HN