<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">There are cases when the GraphQL schema is not known at compile time.</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">SaaS services, for example, like Graphcool, ReIndex.IO, etc..., allow the users to </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">define their own GraphQL schema during runtime.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 8:28 AM, Michał Muskała <span dir="ltr"><<a href="mailto:michal@muskala.eu" target="_blank">michal@muskala.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">There's no unbounded atom creation. Since you have the GraphQL schema, you know upfront which atoms
<div>are allowed and which aren't. You only convert those that are allowed.</div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><br>
Michał.</div></font></span><div><div class="h5">
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><br>
On 25 May 2017, 15:19 +0200, <a href="mailto:duncan@sfractal.com" target="_blank">duncan@sfractal.com</a>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #1abc9c">I thought unbounded atom creation was to be avoided. If you switch to<br>
atoms, how do prevent the original concern "using atoms is just bound to<br>
fill Erlang's atom table", especially if it is driven by user data?<br>
I could foresee a hacker crashing the system by just varying lots of<br>
inputs. If the failure is limited by your architecture to just<br>
processes of that user then you can just 'let it fail'. But if filling<br>
the atom table is a wider crash than just a single user-specific server<br>
process, then it's worth thinking about avoiding.<br>
<br>
Duncan Sparrell<br>
sFractal Consulting LLC<br>
iPhone, iTypo, iApologize<br>
<br>
<br>
<br>
-------- Original Message --------<br>
Subject: Re: [erlang-questions] [ANN] GraphQL Erlang 0.8.0<br>
From: Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.<wbr>com</a><br>
Date: Wed, May 24, 2017 10:57 am<br>
To: Son Tran-Nguyen <<a href="mailto:son@sntran.com" target="_blank">son@sntran.com</a><br>
Cc: "Erlang (E-mail)" <<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<br>
On Wed, May 24, 2017 at 4:31 PM Son Tran-Nguyen <<a href="mailto:son@sntran.com" target="_blank">son@sntran.com</a>> wrote:<br>
<br>
If any, please consider letting the develop to choose whether they want<br>
to convert the binary to atom. If the library switch itself to using<br>
atoms, then the developer cannot really do anything about it.<br>
<br>
<br>
<br>
<br>
<br>
If we make the switch, I'm pretty sure the developers won't be given a<br>
choice. The complexity of managing this will essentially mean every<br>
module in the system needs lots of small fixups. The cost/benefit<br>
analysis doesn't pan out.<br>
<br>
<br>
The impedance mismatch is when you have a field as an atom, 'created'<br>
for instance. But your object stores it as <<"created">> in a map or<br>
proplist. In this case, the code would change from<br>
<br>
<br>
execute(_, Obj, Field, _) -> {ok, maps:get(Field, Obj, null)}<br>
<br>
<br>
to<br>
<br>
<br>
execute(_, Obj, Field, _) -> {ok, maps:get(atom_to_binary(Field, utf8),<br>
Obj, null)}<br>
<br>
<br>
which I don't think is a problem in the long run. It would help if the<br>
data is a #record{} type on the other hand.<br>
<br>
<br>
<br>
______________________________<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" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
______________________________<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" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br></blockquote>
</div>
</div></div></div>
</blockquote></div><br></div>