<div dir="ltr">Thanks Jesper! The TAO-paper is very helpful. One of the data structures I'm looking to work with are RDF triples. Right now, the end goal is rapid prototyping with no overhead on db administration and normalization. So as much as possible, I would want to keep almost a 1-1 mapping from Erlang maps to GraphQL data in the frontend.<div><br></div><div>And it sounds like you built your own graphQL layer as well. What did you think about <a href="https://github.com/graphql-erlang/graphql">https://github.com/graphql-erlang/graphql</a> ?</div><div><br></div><div>Thanks!</div><div>Danniel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 24, 2017 at 8:01 AM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Mar 23, 2017 at 10:51 PM Danniel Condez <<a href="mailto:ducondez@gmail.com" target="_blank">ducondez@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-1602322105044456590gmail_msg"><div class="m_-1602322105044456590gmail_msg">Hi,</div><div class="m_-1602322105044456590gmail_msg"><br class="m_-1602322105044456590gmail_msg"></div><div class="m_-1602322105044456590gmail_msg">Any recommendation for persisting a Map into an unstructured db/filesystem. The goal is to store and fetch it as is, so that both erlang backend and FrontEnd (GraphQL) can easily fetch it.<br class="m_-1602322105044456590gmail_msg"></div><br class="m_-1602322105044456590gmail_msg"></div></blockquote><div><br></div></span><div>Our GraphQL system uses Postgres as a database and utilizes jsonb columns to store map data inside the database. The tradeoff is that your map keys are binary(), but the advantage is that you have the ability to add indexes over your jsonb columsn for quicker access to report-style queries in your data set.<br><br></div><div>We essentially took Facebook's TAO-paper (Types, Associations & Objects) and implemented it on top of Postgres rather than MySQL. We can then use the TAO-API in order to satisfy queries in the GraphQL system. Preliminary analysis and benchmarking shows that this works exceptionally well. Most queries are satisfied by index lookups from memory and is in the sub 3ms range, even for larger blobs of data.<br><br></div><div>Our current primary gotcha is that you can't define<br><br></div><div>-spec m() :: #{ <<"foo">> := integer(), <<"bar">> := integer() }.<br><br></div><div>for the dialyzer. So we can't make the dialyzer efficient at debugging right now. However, the keys are static keys, so we could probably convert them into atom()'s without too much hassle. They are limited in what they can be. This requires some future rework of our GraphQL layer as well though.<br><br></div><div>(For those interested in the GraphQL stuff: talk and release is currently slated for EUC 2017). <br></div></div></div>
</blockquote></div><br></div>