[erlang-questions] [ANN] GraphQL Erlang 0.8.0

[Son Tran-Nguyen]

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/a6a17789/attachment.htm>