<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">Hi Jesper,</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">I always prefer binary use over atom. That's what I like about your library. Like you said, in my use case of handling client-side data, I definitely don't want to convert them to atoms.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">If any, please consider letting the develop to choose whether they want to convert the binary to atom. If the library switch itself to using atoms, then the developer cannot really do anything about it.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 24, 2017 at 8:08 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><div>Hi Son,<br><br></div>You can create a safe hybrid solution in GraphQL which uses atoms, and it is one of the changes we are considering. The parser will produce binary/string data since it is in the control of the client and we can't trust the client. But in the elaboration step, we can run list_to_existing_atom/1 and binary_to_existing_atom/1. If we don't happen to have that atom we know the query is structurally invalid and we can just reject it. If it is structurally valid, we can safely convert into atoms and use them. GraphQL is a statically typed system and we can use this fact to handle it safely.<br><br></div><div>The reason we are considering the change is that it would be more idiomatic than the current solution. One particular strong point is that the dialyzer is able to describe maps in which the domain is given by atoms. But it can't describe maps in which the domain are binaries.<br><br></div><div>The reason we use binaries right now is that it was the easy solution. The system does allow atom-use in the 'enum' types for now, but we plan on folding enum handling into a solution which is more akin to scalar handling. This moves the flexibility onto the developer and we don't have to add code to the graphql system whenever people want a new encoding of enums. GraphQL is a fairly big system and mapping it onto the Erlang world took some trial and error. Some of the trials turned out to be less optimal. But one also has to put a foot down at some point and get something out rather than keeping to optimize for elegance.<br></div><div><br></div><div>Now, having said all that: if you just blindly convert client-side-data into atoms, you can easily get into trouble with clients: either maliciously or innocently, and this is a choice that should be rejected IMO.<br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, May 24, 2017 at 4:23 AM Son Tran-Nguyen <<a href="mailto:son@sntran.com" target="_blank">son@sntran.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"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">Hi Jesper,</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">I just want to say thank you for open source this. You can't imagine how grateful I am to read that the library use binary for keys. Other implementations in Elixir use atoms everywhere. With server that can take a dynamic schema from users, using atoms is just bound to fill Erlang's atom table.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">Again, thank you. I'm looking forward to using this.</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, May 22, 2017 at 9:26 AM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.<wbr>com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>I'm happy to announce that ShopGun's GraphQL code is now open source:<br><br><a href="https://github.com/shopgun/graphql-erlang" target="_blank">https://github.com/shopgun/<wbr>graphql-erlang</a><br><br></div>GraphQL (<a href="http://graphql.org" target="_blank">http://graphql.org</a>) is a query language for the web which is an alternative to RESTful web services. There are some similarity to Joe's UBF stack as well, though it is a completely different take. Originally from Facebook, we implement a GraphQL engine which is almost fully featured in Erlang.<br><br></div>I have a talk at the Erlang Users Conference 2017 on this project, but we are releasing the system early since we are far enough in its lifetime to do so, and there is little reason to keep it closed anymore. If you are interested in this project, please come see the talk :)<br><br></div>Because GraphQL is a fairly large system, there is an accompanying tutorial to the project, which uses the graphql backend:<br><br><a href="https://github.com/shopgun/graphql-erlang-tutorial" target="_blank">https://github.com/shopgun/<wbr>graphql-erlang-tutorial</a><br><br></div>and it has a quite complete tutorial book written as well (pending some sections which is still being written)<br><br><a href="https://shopgun.github.io/graphql-erlang-tutorial/" target="_blank">https://shopgun.github.io/<wbr>graphql-erlang-tutorial/</a><br><br></div>It is our hope that the tutorial will help people use the repository and build some great software on top of it.<br><br></div>As always, comments are welcome. Either in this thread or in Issues in the projects if need be. PRs are also accepted and we want to encourage an open development strategy on the system. While the project probably still has some rough edges, we expect to grind them down over the coming months.<br><br></div>Happy Hacking on behalf of the ShopGun team :)<br><br><div><br></div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>