[erlang-questions] [ANN] GraphQL Erlang 0.8.0

[Jesper Louis Andersen]

Son,

This is a good reason to keep the current state as it is. It has to be
taken into consideration at least and weighed. If a user of GraphQL creates
new atoms, I'm less concerned than if a random client does. But the dynamic
nature is something to think about if we change this to some other
representation. The current one, binaries, has served us pretty well at
ShopGun, so a priori there is no reason to change this unless the atom
solution gives us some kind of advantage down the road.


On Thu, May 25, 2017 at 9:27 PM Son Tran-Nguyen <son@REDACTED> wrote:

> There are cases when the GraphQL schema is not known at compile time.
>
> SaaS services, for example, like Graphcool, ReIndex.IO, etc..., allow the
> users to
> define their own GraphQL schema during runtime.
>
> On Thu, May 25, 2017 at 8:28 AM, Michał Muskała <michal@REDACTED> wrote:
>
>> There's no unbounded atom creation. Since you have the GraphQL schema,
>> you know upfront which atoms
>> are allowed and which aren't. You only convert those that are allowed.
>>
>> Michał.
>>
>> On 25 May 2017, 15:19 +0200, duncan@REDACTED, wrote:
>>
>> I thought unbounded atom creation was to be avoided. If you switch to
>> atoms, how do prevent the original concern "using atoms is just bound to
>> fill Erlang's atom table", especially if it is driven by user data?
>> I could foresee a hacker crashing the system by just varying lots of
>> inputs. If the failure is limited by your architecture to just
>> processes of that user then you can just 'let it fail'. But if filling
>> the atom table is a wider crash than just a single user-specific server
>> process, then it's worth thinking about avoiding.
>>
>> Duncan Sparrell
>> sFractal Consulting LLC
>> iPhone, iTypo, iApologize
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re: [erlang-questions] [ANN] GraphQL Erlang 0.8.0
>> From: Jesper Louis Andersen <jesper.louis.andersen@REDACTED
>> Date: Wed, May 24, 2017 10:57 am
>> To: Son Tran-Nguyen <son@REDACTED
>> Cc: "Erlang (E-mail)" <erlang-questions@REDACTED
>>
>> On Wed, May 24, 2017 at 4:31 PM Son Tran-Nguyen <son@REDACTED> wrote:
>>
>> 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.
>>
>>
>>
>>
>>
>> If we make the switch, I'm pretty sure the developers won't be given a
>> choice. The complexity of managing this will essentially mean every
>> module in the system needs lots of small fixups. The cost/benefit
>> analysis doesn't pan out.
>>
>>
>> The impedance mismatch is when you have a field as an atom, 'created'
>> for instance. But your object stores it as <<"created">> in a map or
>> proplist. In this case, the code would change from
>>
>>
>> execute(_, Obj, Field, _) -> {ok, maps:get(Field, Obj, null)}
>>
>>
>> to
>>
>>
>> execute(_, Obj, Field, _) -> {ok, maps:get(atom_to_binary(Field, utf8),
>> Obj, null)}
>>
>>
>> which I don't think is a problem in the long run. It would help if the
>> data is a #record{} type on the other hand.
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170525/729aa1b2/attachment.htm>