[erlang-questions] [ANN] GraphQL Erlang 0.8.0

Thu May 25 15:18:46 CEST 2017

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)}


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

More information about the erlang-questions mailing list